Re: Apply, Close... (Re: gnome-stock pixmaps)

["Ben 'The Con Man' Kahn" <xkahn cybersites com>]

	We don't we look at the dialog issue from the user's point of
view?  This isn't that hard.  The user wants only a few things:  

	(1) An interface which is obvious to use.
	(2) An interface which can do all the things they can think of.
	(3) An interface which doesn't require lots of work.

	The usually translates into a minimum number of buttons.  
	
	So!  With that in mind, lets look at dialog boxes.  For my
purposes, a dialog box is a window which is opened at the request of an
application and requires input from the user.  I'm not sure if that is the
"official" description.

	There are a few different types of dialog boxes.  

	There are informational dialog boxes.  [For an example, load
Netscape 3.0 and press Ctrl-Right arrow.  (Before loading any pages.)]
Informational dialog boxes have only ONE button.  I propose that the
button be labeled: [ OK ] (This is standard.  See xmessage for example.)
These dialogs should NOT be modal -- they display information only.  In
fact, they should usually be avoided.  (To see why, try pressing
Ctrl-Right-Arrow repeatedly in the above netscape example.  You'll notice 
that Netscape 4.0 no longer gives this dialog.)

	There are direct manipulation dialog.  Any changes to this dialog
are made immediately.  I can't find a good example right now, but a good
use of this would be for file permissions.  These dialogs ALSO only need
one button.  The label of this button is usually [ OK ] for modal
versions.  

	A direct manipulation dialog box which is modal should have a 
[ Close ] button.  These dialog boxes are useful for displaying and
changing STATUS of a rangle of items.  (Suppose a spreadsheet application
has a cell propoerty dialog.  We'll assume the dialog has only options to
change cell data type.  Clicking on a NEW cell should make the dialog
update itself with that cell's data.  Change it, click to the new cell.)

	A verification dialog box is another type.  This has been
discussed here before, but the buttons should USUALLY be [ OK ] and
[ Cancel ] instead of yes and no.  However, it is often apropriate to have
other responses as well.  A maximum of 4 responses should be allowed.  Any
more, and this dialog should be replaced by another type.  ([ Yes to all ]
[ Yes ] [ No ] [ No to All ] [ Cancel ] is bad form.  This should instead
be:  [X] For all  [ Yes ] [ No ] [ Cancel ].)

	A preview dialog box is very common.  This is how the GIMP works. 
The dialog box displays the results of the operation in question, but does
it in a thread.  Nothing is final until it is Applied.  This is where
things become tricky.  It seems to make sense to use: [ OK ] [ Apply ] [
Close|Cancel ].  However, this is not the case.  The INTENT of the dialog
box must be taken into account.  If the dialog is meant to stay on the
screen, can be used by a different object in the program, then [ Apply ]
is justified.  (See LyX's font dialog box for a badly done example of
this.)  If the dialog can only be used for this object, then [ OK ] 
[ Cancel ] is needed. 

	A non-preview property dialog box.  This can be seen ALL over
Windows 95.  These dialog boxes usually have tabs.  If these dialog boxes
can NOT be made into direct manipulation dialog boxes, then their buttons
change on use.  For most of these dialog boxes, I would like to see an
attempt at direct manipulation.  Let's try with the desktop dialog box.  
[ OK ] [ Test|Preview ] [ Cancel ]  The user changes the desktop
background, presses [ Test ] and sees the result -- doesn't like it.
Presses [ Cancel ].  Tada!  The dialog closes, and the original state is
restored.  Or the user can try somethign else, and press [ Test ] again.
If they like that, they press [ OK ].  This seems to be appropriate to
every type of dialog I can think of.  For tabbed dialog boxes, all the
tabs should be applied globally.  Makes changes, change tab.  Make more
changes.  Press [ Test ].  See the result for ALL the tabs.  

	Did I miss any?

						-Ben

------------------------------------ |\      _,,,--,,_  ,) ----------
Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
(212) 924 - 2220                    |,4-  ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
 If you love something, write it in C; if it compiles, it is yours; 
                     if it doesn't, it never was.