1. Cooper Part II Making Well-Behaved Products Data Entry
Jeff Offutt
SWE 632
User Interface Design and Development
Cooper Ed4, Ch 14

2. Data Integrity versus Data Immunity
“garbage in, garbage out” means if the users enter incorrect data then the program will behave incorrectly
Many developers design the user interface to block invalid data
Data Integrity : The state of the program is based on correct, valid input data
Input data validation means checking the data before sending it to the software and rejecting it if does not conform
4-Dec-18
© Jeff Offutt

3. Data Validation is Anti-Usable
Input data validation is like a rude guard at a security check who won’t let you through if you have a 4 ounce bottle of eyedrops !
It puts the database needs before the users’ needs
It makes users feel like suspects
It treats typos like malicious behavior
Sometimes invalid data is reasonable
We don’t have the complete data
We mistyped something
It really doesn’t matter — the rules are overly restrictive
Data validation makes users feel they are not in control
4-Dec-18
© Jeff Offutt

4. Most invalid data can be modified to be valid
Data Immunity
Instead of using data validation to ensure integrity …
Make the software immune from invalid data
Most invalid data can be modified to be valid
by the software !
Four types of immunization
Repairing automatically
Masking out invalid data
Flexible rule enforcement
Auditing instead of editing
4-Dec-18
© Jeff Offutt

5. (1) Repair Data
Think about google … if you search on “gorge mson”, google will respond : “Showing results for george mason”
Plus a link to a page that matches the original string
Examples of automatically fixing data:
Words can be converted to numbers (“five” to “5”)
Look for relationships in data (“Fairfax, BA” to “Fairfax, VA”)
Let the programmers be creative !
Ultimately, it saves money to have programmers work harder than requiring users to work harder
4-Dec-18
© Jeff Offutt

6. (2) Mask Out Invalid Data
For many types of data, the UI can prevent invalid data from being entered
Why allow “five” for a number — use masking to ignore all non-numeric characters
Fill in dashes automatically, so it doesn’t matter if the users entered “ ” or “ ”
Use radio buttons or dropdowns when possible
An error may not be your program’s fault, but it is your program’s responsibility
4-Dec-18
© Jeff Offutt

7. (3) Enforce Rules Flexibly
Defining good rules is hard — defining perfect rules is impossible !
Humans are not good at being exact
Three levels of rules :
The restrictions we really want (intent)
The restrictions we describe (specifications)
The restrictions we implement (law)
The three never match perfectly, and a considerate person will consider the intent instead of the law
Allow some rules to be bent
Always keep a log to check later
4-Dec-18
© Jeff Offutt

8. Do we have to alert the users right now ?
(4) Audit, Don’t Edit
If it can’t be fixed …
Do we have to alert the users right now ?
Missing data is often flagged as a data integrity error
Let missing data be entered later
Tell the users the data is missing with modeless feedback
Modeless : feedback that they do not have to respond to
Missing data can often be inferred from existing data
TurboTax has a post-entry “tax audit” phase
Real-time spell checking unobtrusively tells you when a word is mispelled
4-Dec-18
© Jeff Offutt

9. Protect users from mistakes Don’t prevent them from doing their jobs
Data Entry Summary
Protect users from mistakes
Don’t prevent them from doing their jobs
Users are not the enemy
4-Dec-18
© Jeff Offutt

10. Rethinking Data Storage
The concept of saving files is based on a strange artifact of computer hardware — the disk
Clearly implementation-model thinking
Microsoft Powerpoint X
Do you want to save the changes you made to “CooperCh13.ppt”?
Yes
Cancel No
The choices are NOT equally likely
“Yes” is chosen almost all the time
Why does printing a document change it?
What is the difference between “no” and “cancel”?
“no” responds to the question, “cancel” does not
A major undo—based on the implementation model
4-Dec-18
© Jeff Offutt

11. Outside-in design rather than inside-out
Mental Model
Users think there is only one document, and they own it
Implementation model:
Two documents, one on disk and one in memory
The computer program owns it
Users should not need to understand the file system!
This leads to a user-centric view …
Outside-in design rather than inside-out
4-Dec-18
© Jeff Offutt

12. Cooper’s Unified File Model
User’s view: One copy of the file
Users should be able to
Save documents automatically
Copy
Milestone copy (revision control)
Rename
Move
Change the format (Visio – vsd, jpg, eps, …)
Reverse changes
Abandon all changes
We don’t need a “File” menu anymore …
4-Dec-18
© Jeff Offutt

13. Rethinking Data Retrieval
As search engines get more powerful, users find more ways to use them
In the 1990s I brought paper to class for the syllabus and schedule
Changes would require more paper …
A few years ago we would all bookmark the course website
Now we use our browsers to search for “swe 632”
Searching is a new way to retrieve information
4-Dec-18
© Jeff Offutt

14. Storage and Retrieval Generally, we need places to put our things
And ways to find them when we need them
Indexed retrieval works by creating an index of each thing we store
To get to a file on our disk, we have to remember where it is !
Directory (folder) and file name
4-Dec-18
© Jeff Offutt

15. Finding Digital Documents
Three ways to find digital documents
Positional retrieval – remember where it is
Identity retrieval – remember its name
Associative (attribute-based) retrieval – remember something about the file
Positional and identity retrievals impose a memory burden on the user – hard with tens of thousands of files!
Unix find and grep can be used as a primitive associative retrieval
Associative file retrieval is badly needed
4-Dec-18
© Jeff Offutt