COS 368 Graphical User Interface Design

Dealing with Errors

Computer (programmer) not doing its (his/her) job

Example:
•GUI asked for my telephone number. 
•I just type it in as ddd.ddd.dddd. 
•It gave me an error and then told me (not as part of the textbox label) that it wanted
it as (ddd) ddd-dddd. 

Why?  Couldn't the programmer just have pulled the digits out of the number and
ignore any other characters?  Why make the user first guess what form to use and
then have to use a specific form?

This is an example of the programmer putting a burden on the user that actually can
easily be dealt with by the programmer.

1
Errors
Keep error messages in the realm of the metaphor/model/abstraction/illusion
being used.

e.g.  OK    Too many furniture items in the order, maximum is 100.
        Poor    Stack overflow. (Geek speak)

Schneiderman:
•Errors cause anxiety, confusion, and lack of confidence either in the user or in
the user's perception of the software. 
•Novice users may give up if the error is baffling. 
•Lots of systems have been dumped by companies because of the difficulties
found in using them.
•Some users of systems have error rates as high as 46%.  Do we correct the
user or the software?
•Errors can be quite normal.  (E.g. We all expect to make typing errors and
expect them to be easily correctable.)

2
Guidelines (Schneiderman)

•Specificity
o Vague: Syntax Error
o Specific: Unmatched left parenthesis
o Specific but useless: Error #5406
o Useful: Missing ";" along with the surrounding text.
•User should only have to change the error part; not redo the whole thing.
•Constructive guidance and positive tone. Avoid words like "Illegal", "Error",
"Invalid", and "Bad“
•Error Correction: Often is possible but correction often corrects the error the
machine finds, not the one that the user made.
•User-centered phrasing: User controls the system, not the reverse.
"Enter Data:" Vs "Ready for Data:" The first phrase implies that the
system is commanding the user and the second phrase implies that the
system is working for the user.
•Offer help with the error message.  Tell the user that something is
wrong and give an idea of how to correct it.
3
Guidelines (Schneiderman) (continued)

System should take the blame. Even neutral statements can be

interpreted as negative. 
"The machine performed an illegal operation" is saying that the
machine made an error, but a sensitive user might think they did
something illegal.

4
Error Format
•Uppercase letters only used for extreme errors. (NO SHOUTING)
•Sounds should be disable-able. Sometimes they are embarrassing.
•No code numbers. If you feel it is necessary to have code numbers
include them at the end of the message.
•Placement: Try not to cover up the place where the error occurred.
•Don't be cute; It's tiresome.

Error Studies
•(Schneiderman, 1982) COBOL error messages with increased
specificity generated 28% higher repair scores.
•In a text editor error message study, 4.1 out of 10 errors were
corrected initially and 7.5 out of 10 errors were corrected with more
specific messages.
•Generally better error messages reduce the number of errors.
•Users have a strong, negative reaction to errors.

5
 Example:

404 Not Found

The requested URL /~welty/...  was not found on this server.

Why have the meaningless information first in big letters?  Why not
have the following?

The requested URL /~welty/... was not found on this server.  (code:
404 not found)

The 404 is probably not really needed.

Do not use hostile messages.  These are upsetting to everyone.

    FATAL ERROR, RUN ABORTED
    CATASTROPHIC ERROR: LOGGED WITH OPERATOR

Morals:   Think about errors.

              Try to eliminate the possibility of errors.
              Be informative. 6
The end of errors  (from About Face by Alan Cooper)
Basic ideas
•Replace basic software with more robust systems.
•Users do not like error messages

In the real world if we use a building tool incorrectly, we get a poorly built
structure.  If we use software poorly, perhaps we should get poor results.  The
hammer does not stop pounding because a nail bends.  When done we have a
structure with lots of bent nails.  This may be sufficient.  Perhaps software
should continue even if things do not seem perfectly built.  (This is difficult to
do.  Cooper makes no bones about the difficulty for the programmer in
implementing his ideas.  He believes that complexity is the arena for the
programmer, not the user.)

Q.  Why are there so many error messages?

A. Programmers want the users to be perfect, computer-like.  Also writing
error messages is easier than preventing errors.

7
Major points
•Programmers have to remember the human is more important than the
system.
•Software should work to understand confusing input
.
Positive Feedback
•Make the system responses positive. This helps people learn more
than negative comments.
•Treat error messages like Go To statements.   They are only to be used
in extreme circumstances, and probably not even then.
•Remember, humans have feelings, software does not.  Humans will
stop working with a product if it is painful.

Do error messages work?

•They do not prevent the user from making errors.

8
What should error boxes be like?  (If they exist at all.)

•Polite.  Remember your mother's words, "If you can't say something
nice, don't say anything at all."
•Illuminating
•Helpful
•The software is reporting an error. It should never blame the user. The
customer is always right.

Bottom line.  Errors are failures of the designers and implementers, not
the users.

9
Types of Errors  (More standard analysis, not based on About Face.)
Mistakes and slips.
Mistakes - Person thinks about the problem and its solution, but
incorrectly solves it.A

Slips –
•Doing what you usually do, but it is not appropriate in the present
context.
•Often occur when actions (or sequences of actions) are similar.
Due to inattention in familiar circumstances.

Capture slips - You start doing something, then continue in the usual
but, in this case, incorrect way.
e.g. On Saturday you start out going to the mall but end up at work.
e.g. Click "Yes" when asked if you want to overwrite a file.  It may be
that you commonly update files, but this time you are trying to create
a new one and have accidentally given it the name of another file. 
You should have Selected "No".
10
Description slips - Intended action is much like another one.
e.g.  Peel wrapper off candy bar, throw away candy bar, start eating
wrapper.
e.g.  Meant to save a document, print it because icons look similar.  
(Cut instead of spell check in Word.  The angle of the check looks like
the angle of the scissors on a quick glance.))

Loss of activation - Forget what the goal is after performing a sequence

of actions.
e.g.  Stare into refrigerator, what was it you wanted?
e.g.  Doing a complex sequence of operations, get email, lose focus
and forget what the point of your activity was.

Mode errors - Think you are in one mode when you are really in
another.
e.g.  Changing out of grubby Saturday clothes to put on bathing suit
and go to the beach, end up dressed for work.
e.g.  In BeigeBag, try to draw wires when in component moving
mode. 11
Designing for slips.  (Can not design for mistakes because that goes to intent,
which the computer does not know.)
•Capture slips - allow easy reversal of actions ("Undo").
•Description slips - Make icons definitely unique (not similar).
•Loss of activation - Allow the user to see path taken.
•Mode slips - Have only a few modes.  Make modes highly visible.

12
It is unusual to have labels inside text boxes. Usually they are labeled outside.

The following does prompt the user to enter the appropriate items. It reinforces the
label.

Since the point of the exercise was to tell the user what they were
required to do before proceeding, don't let the operation proceed
until they've done it! As long as the prompt is still sitting untouched
in the control, disable the button (or whatever) that lets the user
finish this part of the operation. That way, you won't have to throw
an error message at the user.
In The Design of Sites, van Duyne et. al. refer to this technique in
their more general pattern "Preventing Errors." 13
Example: From PowerPoint
Input Prompt has been unusual in desktop applications, but it's as good an idea in
this context as it is on the Web.
Note its use on a WYSIWYG editor's canvas here -- it doesn't indicate a "required
field" as such, but the application clearly communicates its intent to the user, who
doesn't have to think hard about how to do what they most likely want to do.

14
The following are from the error messages section of the Interface Hall of Shame

We are unfortunately all too familiar with the use of terms

such as "Fatal Error", "Critical Error", and "Severe Error", but
Ben Speakmon discovered an entirely new type of error in
FreeJava: 
The message resulted when Ben invoked the Build command
after editing a project. Apparently, FreeJava's developers
consider the fact than an error occurred as being far more
important than identifying the source of the error. 

15
James Hewett-Hicks sent us this image of a message he
received from Banyan Vines' BeyondMail®. According to
James, the message appeared "out of the blue" while the
program was minimized. As to the practice of placing the
error code in the title of the message box, well that is simply
BeyondBelief®. 

16
As stated elsewhere on the site, Paint Shop Pro is an excellent graphics application,
but at least through version 4.12, it has one extremely annoying interface
inefficiency. When exiting the application, the user is prompted to save each
unsaved image. The fact that it prompts the user is quite nice; unfortunately, since
the prompt dialog does not provide a No to All button, the user is forced to respond
to the prompt for each unwanted image. As is often the case when preparing images
for the Interface Hall of Shame, a Paint Shop Pro session might involve many images,
only one of which will ultimately be saved for use. Unfortunately, without the No to
All option, the user is forced to specifically tell Paint Shop Pro, "No", "No", "Nope",
"Not that one", "Not that one either", (sigh), "No", "Uh-uh", "If I wanted that one, I
would have saved it", "nope", "no", ... 
It would appear that the reason for the omission is that PSP is relying on the
Windows built-in message box functions, which do not support a No to All button.
While reliance on the built-in functions relieved PSP's developers from the negligible
burden of creating their own dialog, it often requires the user to respond to a
17
plethora of useless messages. 
Christian Kanja sent us this useless error message he came
across in Microsoft's Data Link application. We are reminded of
the following refrain from Bob Dylan's Ballad of a Thin Man: 
Because something is happening here 
But you don't know what it is 
Do you, Mister Jones?

18
The message is displayed by Dr. Zeuss's ABC, an alphabet game
intended for 3 to 5 year-old children. Funny thing though, the
message is completely unnecessary, since the program works just
as well at any typical display setting. 

19
The following is from a message sent in by a programmer:

Yesterday a young secretary called our helpline saying she's following the instructions on
screen, but when she types in the word "mismatch", nothing happens! A bit puzzled, I
asked what it is she's actually trying to do, and she says she's hit File/Save and now a
message has appeared saying "Type mismatch". 

... very embarrassing for three of us: her, me and our tester (who'll be on short rations all
next week!). 

This is probably from the programmer not catching an error and letting the system display
its message.

20
Ambiguity in action. This unclear message resulted after the user
mistyped a filename, something a user should never be required to do.
Most operating systems have built-in file selection dialogs that
programmers can easily use in their programs. The file selection
dialogs make it impossible to mistype a filename. Not using them is an
indication of laziness, and an invitation to mistakes. 

21
Messages similar to this are perhaps the most common, and the
ones most easily avoided. The user has pressed the Change button
when looking at a blank record. Maybe it's a stupid mistake, but
when stupid computers allow people to make stupid mistakes,
we'll make them. What the user does not expect is a computer
with an attitude. The message might as well say: "Change?! How
stupid are you? What the heck do you want me to change?!" 

There is an obvious solution, which has become a standard of

graphic interface design: never provide a function that will only
result in an error message; disable any functions that don't apply. 
22
The following is from the Interface Stupidity section of the Interface Hall of Shame

This illustrates two aspects of interface stupidity.

The first is that the message is flawed; it is generated when the user attempts to add a record
that's missing either the last name or the phone number. The programmer apparently was not
competent enough to display a message for the specific omission, so he or she opted for a
generic incorrect message. 

The second, more serious aspect of interface stupidity is that the program has adopted arbitrary
rules based on the needs of the program rather than the needs of the user. The application
requires the user to enter a last name and a phone number for each record. The end result of
these rules is that they compromise the usefulness of the application. How does the user enter a
record for the local power company? Do I have to know the name of the receptionist at the cable
company just to store the number of the billing department? What if I want to enter the mailing
address of a company and I don't have the phone number - after all, it's an Address book! The
only way to do so is to enter a fake phone number.  23