Norman 7
User-Centered Design
Data Entry
Jeff Offutt
http://www.cs.gmu.edu/~offutt/
SWE 205
Software Usability and Design
Today’s Topics
1. Designing Everyday Things (Norman, Ch 7)
2. Improving Data Entry
3. Selecting Events
1-Jul-16
© Jeff Offutt, 2010
2
Seven Principles for Making Hard
Things Easy
1. Use knowledge in the world and knowledge in
the head
2. Simplify task structure
3. Make things visible
4. Get the mappings right
5. Exploit the power of constraints
6. Design for error
7. When all else fails, standardize
1-Jul-16
© Jeff Offutt, 2010
3
1. Use Knowledge in the World
• New users do better if everything they need to
know is in the UI
• Experienced users can be faster by having
knowledge in their heads
• All users are more effective if the implementation
model matches their mental model
• Avoid depending on user manuals
– A very inconvenient part of the world
1-Jul-16
© Jeff Offutt, 2010
4
2. Simplify Task Structure
• Simplify tasks by considering the users’ :
–
–
–
–
Psychology
Short term memory
Long term memory
Concentration
• New technology should make tasks simpler
–
–
–
–
1-Jul-16
Same task with mental aids
Increase visibility
Same task with simple steps automated
Change the nature or structure of the task
© Jeff Offutt, 2010
5
3. Make Things Visible
• Users should quickly see
– What they can do
– How they can do it
– What will happen
• The possible actions should satisfy user’s goal
– Revenue, not excise
• System state should always be obvious
• Examples
– Patriot web needs to show state : semester and CRN
– PPT needs to make it easier to find slide animation
controls (Animations  Custom Animation)
1-Jul-16
© Jeff Offutt, 2010
6
4. Get the Mappings Right
• Intentions (what users want) to actions (what they
can do)
• Actions and effects on the software
• System state and what is visible
• Perceived system state and the users needs
• Graphics, icons and pictures are easier to
understand
– But designing graphics is hard !
– Not a common skill among programmers
1-Jul-16
© Jeff Offutt, 2010
7
5. Exploit Power of Constraints
• Constraints stop users from entering wrong data
– Ignore dashes in phone & credit card numbers
– Advanced controls like the dates in travel web sites
– Selections, as in radio boxes and dropdown lists
• My 1980s stereo system had 5 or 6 components
and dozens of wires … all alike!
– Modern stereo systems have different wires with
different connections for each component
• Think of this as strong typing for UIs …
1-Jul-16
© Jeff Offutt, 2010
8
6. Design for Error
• Users are not perfect and will enter invalid data
• Design for invalid inputs !
– Use constraints to avoid invalid inputs
– Correct invalid inputs automatically
– Make it simple and convenient for users to correct
invalid inputs
– Allow users to postpone invalid input corrections
– Make it easy to undo
More later …
1-Jul-16
© Jeff Offutt, 2010
9
7. Standardize
• The controls are all the same—consistent
• A last resort approach because it forces
knowledge to be in the head
• Notice anything funny … ?
• Standardize early or it will be too late
• Standardization only has to be learned once
1-Jul-16
© Jeff Offutt, 2010
10
Designing Everyday Things
• Make it easy to decide what actions are possible
• Make things visible
– Controls, choices, and the conceptual model
• Make it easy to see the state
• Use natural mappings
– Intentions  actions
– Actions  effect
– Visible information  actual state
1-Jul-16
© Jeff Offutt, 2010
11
My Favorite
1-Jul-16
© Jeff Offutt, 2010
12
Home of the Future
House of Knowledge
• Norman’s book was published just before the
Web was first proposed
• “Information of the world is available to all”
– Berners-Lee invented the web to make “all information
available to all users all the time”
• Cost of production versus cost of development
– That is, copying a file vs writing a book
• The biggest problem Norman expected ?
Finding what we want !!
1-Jul-16
© Jeff Offutt, 2010
13
Today’s Topics
1. Designing Everyday Things (Norman, Ch 7)
2. Improving Data Entry
3. Selecting Events
1-Jul-16
© Jeff Offutt, 2010
14
Improving Data Entry
• Be considerate when users enter data
• Implementation-model thinking makes it hard to
design usable data entry screens
• Two major issues :
– Data integrity and data immunity
– Auditing and editing data
1-Jul-16
© Jeff Offutt, 2010
15
Data Integrity vs Data Immunity
• I’ve heard the phrase “garbage in, garbage out”
since I was in college
– If the users enter incorrect data then the program will
behave incorrectly
• Experienced developers design the user interface
to block invalid data
Data Integrity : The state of the program
depends on correct, valid input data
• Input data validation means
• Checking before sending to software
• Rejecting it if does not conform
1-Jul-16
© Jeff Offutt, 2010
16
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
(gasp) have a 4 ounce bottle of eyedrops !
• Puts the needs of the database before the needs of
the users (excise!)
• Makes users feel like suspects and treats typos like
malicious behavior
• Sometimes invalid data is reasonable
– We don’t have the complete data
– We mis-typed something
– It doesn’t matter – the rules are overly restrictive
1-Jul-16
© Jeff Offutt, 2010
17
Data Immunity
• Instead of using data validation to ensure integrity
• Make the software immune from invalid data
Most invalid data can be made valid
by the software !
•
Four types of immunization
1.
2.
3.
4.
1-Jul-16
Repairing automatically
Masking out invalid data
Flexible rule enforcement
Auditing instead of editing
© Jeff Offutt, 2010
18
Data Immunity – Auto-Repair
• Think about google … if you search on “gorge
mson”, google will respond : “Showing results
for george mason”
– Plus a link that match the original string
• Examples of automatically fixing data:
– Convert word to numbers (“five” to “5”)
– Look for relationships (“Fairfax, BA” to “Fairfax, VA”)
• Let the programmers be creative !
It saves money to have
programmers work more and
users work less
1-Jul-16
© Jeff Offutt, 2010
19
Data Immunity – Masking Invalid
Data
• The UI can often prevent invalid data from being
entered
– Do not 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 “123-45-6789” or “123456789”
– Use radio buttons or dropdowns when possible
1-Jul-16
© Jeff Offutt, 2010
20
Data Immunity – Flexible Rule
Enforcement
• Defining good rules is hard – defining perfect
rules is impossible !
• Three levels of rules :
1. The restrictions we really want (intent)
2. The restrictions we describe (specifications)
3. 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
1-Jul-16
© Jeff Offutt, 2010
21
Data Immunity – Audit Don’t Edit
If it can’t be fixed …
Do we have to bother the users right now ?
• Missing data is often flagged as a data integrity
error
• The missing data can sometimes be entered later
• Tell the users the data is missing with modeless
feedback
– Modeless : feedback they do not have to respond to
• Missing data can often be inferred from existing
data – but the programmers have to work instead
of the users
1-Jul-16
© Jeff Offutt, 2010
22
Data Immunity – Postponing
Notification
• TurboTax has a separate “tax audit” phase where
it looks for data errors after all the data entry
– This does not interfere with the user’s flow
• Real-time spell checking unobtrusively tells you
when a word is mispelled
– Users can go back and check it later – if they want !
– Some “misspelled” words are okay … no dictionary is
complete and perfect (they usually don’t include
“Offutt”)
1-Jul-16
© Jeff Offutt, 2010
23
Data Entry Summary
Protect the users from mistakes
Don’t prevent them from doing their
jobs
1-Jul-16
© Jeff Offutt, 2010
24
Today’s Topics
1. Designing Everyday Things (Norman, Ch 7)
2. Improving Data Entry
3. Selecting Events
1-Jul-16
© Jeff Offutt, 2010
25
Selecting Events
Keep events close
together
Stupid
1-Jul-16
Better
© Jeff Offutt, 2010
Good
26
Selection
• GUI operations have two parts:
– Operation (verb)
– Operands (objects)
• CLs often use natural speaking style : verb-object
• GUIs should usually let the user select an object,
then apply an operation : object-verb
• This makes selection very important
1-Jul-16
© Jeff Offutt, 2010
27
Discrete and Contiguous Selection
• Discrete data : Objects are independent and need
to be selected independently
– Picture elements in a drawing tool
• Contiguous data : Objects are ordered in lists or
matrices
– Spreadsheet cells and words in word processors
• Whether data is discrete or contiguous
sometimes depends on user needs
– Files can often be selected in both ways
– Shift-left mouse for contiguous selection
– Ctrl-left mouse for discrete selection
1-Jul-16
© Jeff Offutt, 2010
28
Selection Summary
The user must always know what was
selected before choosing an operation
1-Jul-16
© Jeff Offutt, 2010
29
Summary of Today’s Topics
1. Designing Everyday Things (Norman, Ch 7)
2. Improving Data Entry
3. Selecting Events
1-Jul-16
© Jeff Offutt, 2010
30