CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0
Sender:
"ACM SIGCHI WWW Human Factors (Open Discussion)" <[log in to unmask]>
Subject:
From:
Marc Crawford <[log in to unmask]>
Date:
Thu, 28 Oct 1999 18:34:52 EDT
Content-Type:
text/plain; format=flowed
X-cc:
Reply-To:
Marc Crawford <[log in to unmask]>
Parts/Attachments:
text/plain (89 lines)
>
>Dianne Starzyk <[log in to unmask]> asked:
> > > Is [displaying a reset button with a submit button on a web form]
>something that should be standard on any form?
>
>Marc Crawford <[log in to unmask]> wrote:
> > One of Jakob Nielson's often recited "10 Usability Heuristics" is:
>"User control and freedom - Users often choose system functions by
>mistake and will need a clearly marked "emergency exit" to leave the
>unwanted state without having to go through an extended dialogue.
>Support undo and redo." This obviously speaks in favor of the reset
>button on forms (whether on Web interfaces on other UIs
>
>Susan Paulsen <[log in to unmask]> wrote:
> > ...Another [heuristic] states that an interface should allow users the
>ability to recover from errors.  If a form is particularly lengthy, a user
>may accidently hit the "Reset" button and render the info unretrievable...I
>do not supply the Reset function.  The user is able to (and explicity
>instructed to) edit information at any time, which includes clearing out of
>individual field.

Not that Nielson's 10 are the only way to discuss this, but since we started
we might as well cite the complete definitions. The one Susan refers to is
"Help users recognize, diagnose, and recover from errors. Error messages
should be expressed in plain language (no codes), precicely indicate the
problem, and constructively suggest a solution". It talks about error
messages and how to write them - after they have been made.
>
>In fact, I think the cited heuristic [User control and freedom] has been
>misapplied here. It seems
>to me that users already have the "control and freedom" that some
>believe a 'reset' button affords. The heuristic, if I read it correctly,
>is actually directed at *"unwanted states"* and situations that users
>*cannot escape or control*.

I would say that is stretching the original definition a bit. There is a
difference between the former and the latter.

But users *can* control and undo just about
>everything they do with a Web form--with the exception of poorly
>implemented radio buttons, users can modify their input ad infinitum.

The keywords here are "...without going through an extended dialogue" If the
form is long, I have already filled out 10 fields and realize that I would
like to start over again, I would rather hit one "reset" button than edit
those 10 fields. In fact, if I only had the chance to go through them one by
one, I might try to reload the page, or come back some time else.

>
>Furthermore, users aren't committed to *anything* they input until they
>actually hit either the 'submit' or 'reset' button.  And once that's
>done, the 'reset' button is irrelevant--the data's either been sent or
>deleted.
>
>If we're going to cite Nielsen's 10, I suggest we focus on #5--error
>prevention.

Error prevention is always a great design goal. And, as often in the real
world, it is most likely a combination of several of the heuristics (which,
BTW, are already combinations of about 200 heuristics that went into the
factor analysis). E.g., you might even want to mention "flexibility and
efficiency of use"...

The idea of supporting undo and redo, as stated in "User control and
freedom", is closely related to the filling out of forms (or am I totally
off track?). And the easier you make it for users to do things over again,
the better. Just because undo might not be needed *often*, does not mean it
should be omitted.

A little example about what functionality to include (or not to include)
from car design: I never used the air-bag and never want to. Nevertheless,
I'm sure the designers will keep on including it - and it's probably a good
idea. (Please note that I'm not trying to compare filling out a form with a
car accident. What I'm getting at is that some features are important,
although not often needed.)

Do you design your user interfaces according to the frequency in which users
click (or don't click) on things?

And do we take things off of interfaces because they bother some of us (the
experts)?

Marc Crawford

Information Architect & Web Usability Consultant

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

ATOM RSS1 RSS2