Re: Meaning of "Close" in non-modal dialogs (was: Re: gnome-stock pixmaps)

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Tue, 05 May, 1998 at 09:44:27PM +0200, Markus Fleck set free these words:
> Toshio Kuratomi wrote:
> > Right: target audience is people who not only can, but do use a computer
> > already.  And therefore, people who already see Close as (Close+Apply) [The
> > damage is done; the word is already redefined]  If we are going to un-redefine
> > the word to mean (Close) then we are going to have to give the user visual
> > clues so they don't do something they don't expect; disable Close unless the
> > changes have been synced (either Applied or Undone).
> 
> No. In fact, using (Close) as "Apply+Close" is redefiniton of the usual
> meaning of (Close). You're probably confusing (Close) with (OK), but
> (OK)
> doesn't really make much sense in a non-modal (=persistent) dialog,
> which
> is why (Close) is used:
> 
Hmm... Maybe you're right about me confusing Close and Ok.  I think of them as
occupying the same space (the lower left) in a dialog and so they have the
same meaning.  After looking at a few apps, I find that the wording is indeed
Ok for (Close+Apply) and Close for (Close) for most of them (1 exception out
of four.)  I think we should not put "Close" into the lower left hand corner,
though -- if I have never though about the difference between "Ok" and "Close"
I bet there are plenty of others who don't either.

However, I, in turn, think you may be confusing the term "modal."  For me,
a modal dialog is one which suspends input to the rest of the app while a
non-modal dialog is one which allows input to go to the rest of the app even
while it is open.  Nothing else is specified by the term modal.

I think you are talking about tool-box type dialogs (I call them toolbox or
palettes) as opposed to Information, warning, and preferences dialogs.  Either
type of dialog can be modal or non-modal as the situation warrants
[Windows/Mac tend to make them modal too often.  UNIX tends to make them
non-modal if at all possible.]

For tool boxes, Close (Close) makes sense and Apply, Ok, etc are meaningless
(as the effects of a change in the toolbox are applied instantaneously on the
app.)  However, many dialogs, including the preferences dialog that we have
been discussing, aren't toolboxes.  They do not update the app instantaneously
when changed (This, not modality, is the defining quality.)  In this context,
Close is a bad choice of functions unless you grey it out when there are
unresolved changes in the dialog because merely closing the dialog neither
specifies Applying those changes or Canceling them.

Most dialogs solve this by specifying Ok instead of Close (See gimp's
preference's dialog), but we can specify Close if we follow Russell Nelson's
suggestion of greying it out when unresolved changes exist.

> (OK) means "Apply+Close".
> (Apply) means "Apply".
> (Undo) means "Undo last step".
> (Cancel) means "Undo all+Close".
> (Close) means "Close".
> 
I disagree with your definitions of (Undo) and (Cancel).  I place (Undo) in
opposition to (Apply) -- therefore it should undo a set of changes just as
apply commits a set of changes.  Cancel should do an (Undo+Close) where the
definition of (Undo) is the one I just specified.

-Toshio

> A modal dialog (i.e. the dominant type of dialog in MS Windows, Mac
> etc.)
> should use (OK) and (Cancel). It might also have a (Preview) button to
> show a preview of the effect of the operation, but the operation would
> not "really" take effect until the user hits (OK).
> 
> A non-modal (=persistens) dialog (which seems to be more common in UNIX
> and
> Motif, and is used in MS Windows et al mainly for "tool options"
> dialogs)
> should instead use (Apply), (Undo) and (Close). All of these buttons
> should do *only* what they say and *not* have any side effects.
> 
> GIMP has a tendency towards non-modal dialogs, because these are often
> more powerful and convenient for the user, provided that their screen
> is large enough to hold all the dialogs. But there are still times
> when modal dialogs are needed, e.g. for things that cannot be undone
> and would seem out-of-context as non-modal dialogs (e.g. a "delete file"
> confirmation dialog box in a file manager application).
> 
> Yours,
> Markus.
> 
> -- 
> ////////////////////////////////////////////////////////////////////////////
>    Markus B Fleck - University of Bonn - CS Department IV -
> fleck@isoc.de
>          UNIX Administrator - comp.lang.python.announce Moderator
> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
> 
> 
> -- 
>          To unsubscribe: mail gnome-gui-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.

-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~