Re: [Usability] Close buttons on instant-apply dialogs

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Jan 02, 2002 at 04:43:21PM -0800, George wrote:
<snip>
> Just because we can't make this simple assumption doesn't mean we can't build
> a usable environment.  In fact I would take robustness as a part of
> usability.  If it is quite simple for the user to remove the close button
> (and it is) then we shouldn't rely on it.

It's also quite simple to run without a window manager. See my other reply.


> If someone could show that leaving the app close button IS a SERIOUS
> hinderence to usability, then I may be convinced that it is worth reducing
> some robustness.  However, I have not seen any such evidence except some
> people claiming that they are sure that it is.  Is there a usability study
> claiming that? . . .


>          . . . I'd say there is substantial empiric evidence claiming
> otherwise.  Nautilus has had an instant apply settings window (if you don't
> want to call it a dialog) with an explicit close (OK in it's case) button,
> and I have not seen anybody get confused by it.  In fact since this design
> actually came from people who also worked on the original mac design, then 
> I'd say even mac people aren't completely convinced either way.

Delve a little more into the history.


<snip>
> I have evidence of where it can slow my work to a crawl.  I needed to use a
> gnome app remotely from a terminal which had a badly setup ctwm which
> included no way to close a window.  It would be impossible to then change
> properties/settings in this case.

   STOP

   Right here you have indicated that you've missed the point entirely.
   We are talking about windows with controls that immediately affect some
   other part of the enviroment. There is no need to close the window to
   have the settings take effect.


> Also given that I rarely use the close button.  Having to use it for a singly
> type of window WILL slow me down.  I am used to running my mouse to the
> bottom right part of the window for all dialogs (and also what you call
> utility windows).  Because mostly I will deal with dialogs.

That's a damn shame and indicates that the system is poorly designed. If
you're mostly dealing with dialogs, then you may as well be trapped on the
command line. One of the reasons to change to instant-apply is to be rid of
modality. Some years ago if you wanted to enter data into something (like a
spreadsheet or a database, but there are probably better examples) you had 
to issue some sort of Add command and the system would but you in the mode
to enter the data. When GUIs started to appear you still had the same way
of working, but you could see a little bit more at once. Then some bright
fellow had the idea that you could just enter data directly into some
representation of whatever and one more dialog disappeared from the interface.


<snip>
> In which case "OK" would be proper.  Perhaps "OK" is the right button name
> for the instant apply dialog as well.

 No.

<snip>
> > > > Because leaving the `Close' button in would slow down the interface
> > > > for *every other* user. (Not to mention wasting a whole button-row's
> > > > worth of screen space.) Sure it doesn't cost us, but it costs the'
> > > > user. Personally I think implementing an interface which is wilfully
> > > > inefficient like that is immoral, though I can understand how other
> > > > people can take it less seriously.
> > > 
> > > Now you're exaggerating.
> > 
> > No, really, I'm not.
> 
> Huh?  Where's your evidence besides that it is obvious for you?  I can say
> just the opposite with the same argument:  Removing the app close button
> slows down 2 out of every 3 users.
> 
> Am I exaggerating?
> 
> No, really, I'm not.  In fact, I've just beaten your argument by using a
> higher figure and thus I am correct.  In fact 76.5% of people think that I am
> correct.  And 86% of people think that randomly made up statistics are usable
> in an argument.

I believe the claim about exaggeration was because the question of morality
was raised. Matthew is not exaggerating in his evaluation; given his values
and their relative importance in his life, it is for him a moral issue.
(As far as I can tell. I think there was just some miscommunication here.
 I hope that clears it up. Let's try to avoid meta-moral debates please.)


<snip>
> <rant>
> I hate modal dialogs with a passion. [...]
</snip>

Don't we all? We should be trying to get rid of them, not make things
confusing by presenting very similar windows which sometimes block other
work and other times don't.


<snip>
>  . . . This
> is because I've gotten my idea of what dialogs are from using them and not
> from reading CUA.  I don't think most users will read CUA, and thus will not
> be confused.  So instant apply windows are dialogs to me, just like a save as
> dialog or a 'your app has crashed' dialog.  All your utility windows I
> mentally as a user treat as dialogs.  So I will also expect to close them
> as dialogs.  It seems to me that here consisntency is on the side of having a
> "Close" app button on the window.  Actually mentally the way I distinguish
> normal windows from dialogs is the presence of a menu.

See my other replies about why CUA is being mentioned at all.

Quite frankly I'm amazed that I ever had to explain that even once.
Programmers talk about structures, enumerations, et al.
Interface designers talk about windows, dialogs, et al.
The users do neither.

If you're even thinking of dialogs, you probably aren't the average user.


> > > Also, a dialog close button gives keyboard-only users an obvious way
> > > to close the window without having to resort to window manager
> > > shortcuts, which also have to be remembered to be useful.
> > 
> > The window manager's shortcut will always be the same. The access key
> > for a `Close' button might be Alt+C ... Or if Alt+C is taken up by a
> > `Choose File...' or `Clear' button elsewhere in the window, `Close'
> > might become Alt+E, or maybe Alt+W for `Close _Window' ... or if you
> > happen to be using an obscure utility which is only available in a
> > French localization it might be Alt+F, or if it's in German it'll be
> > Alt+S ... Or maybe ...
> 
> Or maybe ... so basically you're saying that I will have 0 clue as to what
> the shortcut is.
<snip>

If you can't deal with the ambiguity while these things are being standardized
for the platform which has been an application free-for-all, then you're at
the wrong party. Not everything is done and published and until then,
and surely even after, there will be discussions such as this. If you can't
grasp that, then do whatever you please until such time as the conclusions
are made public, but interjecting irrelevancies. Do you like to have a
"That's not ANSI C!"-critic over your shoulder while you type every single
character of every single line of code?

> > (Surely you're not going to tell me that a `File' > `Close' menu item
> > precludes a `Close' button -- such a menu item is even *more* difficult
> > to get to than the window manager's close button or keyboard shortcut.)
> 
> Actually File > Close menu item is very simple for me to access.  I can just
> do 'Alt' and then down arrow for a bit and space. . . .

Gtk+ doesn't do that, Windows does.
  http://bugzilla.gnome.org/show_bug.cgi?id=53543

>                                             . . . And I actually remember
> this.  Mostly because it works in 99% of applications, operating
> environments.  I can't say the same for the wm close button shortcut,
> which I don't know in any environment.

There are two that are standardized. On Mac it's Control+W. On the CUA-based
systems, it's Alt+F4. I suspect Mac may have slightly better share than
that remaining 1%, and I've set to find a keyboard way of opening a menu
there.  (Is there one?)

<snip>
> 
> George
> 
> -- 
> George <jirka 5z com>
>    If the facts don't fit the theory, change the facts.
>                        -- Albert Einstein

Interesting quote at this time.

Gregory Merchan