[Sigia-l] Form Usability - Search & Cancel location

[Christopher Fahey [askrom]]

> On 25 Jun 2002 at 19:29, Christopher Fahey [askrom] wrote:
> > 
> > To me having Cancel on the left is plainly obvious, particularly in
a
> > multi-step process. The dialog-box analogy several people have made
is
> > sort of inappropriate: First, most dialog boxes are atrocious in
terms
> > of usability, and secondly a multi-step web form is not really a
> > dialog box at all.
> 
> I don't understand why you would think a multi-step web form isn't  
> like a dialog box.  I've seen plenty of non-web based forms that look 
> similar to web forms.  You fill in stuff, you look at it, you press 
> some type of button to send it somewhere.  Why does it matter if it 
> is web/dialog.


There's a simple semantic difference I'm making between a "form" and a
"dialog" box. Traditionally (AFAIK) a "dialog box" is an interface
element with these basic qualities:
  1) The user can't do anything until they address the dialog box (i.e.,
they are 'modal')
  2) The dialog box's interactive possibilities are quite small,
typically with only one or two options.
  3) The dialog box's interaction is relatively quick compared to the
core tasks of the host application. 

The "Save as" dialog and the multi-tabbed "Options" or "Preferences"
dialog box you see in many applications push the envelope of what a
dialog box is in that they do a lot more than just ask you to pick "OK"
or "Cancel". In face, such boxes can have pretty robust interfaces of
their own, almost like stand-alone applications. Such practice is an
established convention, but you'll often see designers cram
functionality into dialog boxes that would be better served in some
other kind of interface element. A product registration form with a
dozen user-entry fields is typically designed using dialog box interface
conventions, but to think that such an interactive element should follow
the same conventions as an "OK/Cancel" alert box is pretty limiting
thinking. Thinking of such interfaces as simple dialog boxes discourages
interaction designers from using more appropriate interface elements in
the application design.

The term "Wizard" was invented to describe a particular kind of
multi-step dialog boxes, to distinguish the design conventions of
Wizards from the design conventions of standard dialog boxes. On the one
hand you can call a Wizard a kind of dialog box I suppose, but I just
call them Wizards. Wizards are to dialog boxes as Homo Sapiens is to
Australopithicus - same basic physical format, but Homo Sapiens is more
evolved to better accomplish more complex tasks. 

> You fill in stuff, you look at it, you press some type of button 
> to send it somewhere.  Why does it matter if it is web/dialog.

"Fill in stuff, look at it, and press a button" does not (to me)
automatically mean that the interface should follow the conventions of
an application dialog box. The fact that application dialog boxes now
contain forms that look like web sites says more about how the web has
improved on some bad application interface design conventions than it
says about how application design conventions are applicable to web
sites. The conventional web-based "form" has come a long way in the past
few years, becoming quite elegant and flexible and far outgrowing its
roots in the world of application dialog boxes overcrammed with
interface elements.

Dialog boxes are one of the most overused interface elements in desktop
applications, and it pains me every time I see dialog boxes translated
into web pages - ugh! They are unnecessarily modal (why should I be
forbidden from doing other things in an application while I fill out a
product registration form?). They have a purpose, but 75% of the time
they are used when another paradigm should be used instead.

-Cf

[christopher eli fahey]
art: http://www.graphpaper.com
sci: http://www.askrom.com
biz: http://www.behaviordesign.com