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

[Christian Rose <menthos menthos com>]

ons 2002-01-02 klockan 14.24 skrev Matthew Thomas:
> > > > I think there is some confusion here, I was saying that property
> > > > dialogs (instant apply) without a close button confuse me.
> > >
> > > They do have a close button. Provided by the window manager.
> > 
> > This has been discussed many times before. The window manager doesn't
> > have to provide a close button; it doesn't have to provide any buttons
> > at all. Even if it has one it doesn't have to be easily recognizable
> > as a close button.
> >...
> 
> Oh, please. GNOME apps will never be more usable than those on Windows
> and Mac OS (and CDE, and OS/2, and whatever else) if those designing
> them can't make even the most basic assumptions about whether or not
> window title bars have close buttons on them.

We can't, actually. Contrary to Windows, Mac OS, KDE and many other
environments, GNOME is pretty much window manager agnostic and allows
use of several window managers. This has always been one of the goals
with GNOME. GNOME ships a default window manager, but as with any choice
the default is just one among many valid choices. Allowing the use of
several window managers is one of GNOME:s key features, and users are
expected to be able to use a different window manager. Like it or not,
GNOME being agnostic to window managers is something that has to be
taken into account in decisions affecting overall GNOME usability.


> If any window manager (or wm theme) is broken, fix it. If you're going
> to take the tyres off the wheels before running GNOME, you deserve what
> you get.

I'll leave it to you make all themes and window managers equally usable,
and to standardize number of buttons, functions of buttons, positions of
buttons, ordering of buttons, symbols on the buttons across all themes,
and window manager shortcuts in all window managers, and to make the
close button stand out from the rest and be labeled "Close" on
instant-apply windows, so that people who never use these buttons
otherwise are notified that you expect them to use this button to close
the window in this case.
Until that happens, we have to make instant-apply dialogs not more
unusable than they have to be. A good start is by not starting to assume
things about the window manager.


> > > The confusion is there, but the main problem is that providing more
> > > than one obvious way to perform a function, with a given input
> > > device, slows people down.
> > >
> > > I know, I've watched them. Hundreds of them. I've watched people
> > > closing unsaved CVs in Microsoft Word (why save it when they've
> > > already printed it, and when they're not going to be using our
> > > computers again?), repeatedly bouncing between the close button in
> > > the title bar of the document window and the close button of the
> > > `Save changes to Document1?' alert, wondering why the damn document
> > > isn't going away. Microsoft forgot to remove the close button from
> > > the title bar of the alert, and users think that close button means
> > > `Don't Save' when actually it means `Cancel'. There's already a
> > > button called `Cancel', so (as Gregory said) the close button in the
> > > title bar shouldn't be there.
> > 
> > Your example is interesting, but irrelevant.
> 
> No, it's the logical counterpart to my second example of a `Close'
> button in an instant-apply window. In both cases, users are slowed down
> by having two similarly accessible means of performing the same action.

Not all users use both ways (some people always use the wm buttons to
exit a window, some always use a button or a menu entry), and not all of
those who use both ways of exiting a window are confused about there
being two ways of exiting the window.


> >                                              In your example, the
> > confusion is because it is not always clear what the window manager
> > close button means in that case ("is it cancel or don't save?").
> > There is no such controversy here. The window manager close button as
> > always means "close this window", and the button on the window labeled
> > "Close" is pretty straight-forward.
> 
> Except when it's not, as Liam Quinn pointed out when talking about kppp.

Quoting Liam Quin:
"KDE's ppp dialer has a 'details' button that brings up a new window,
"but that window hasa 'close' button, worrying becuse you are not sure
"if it means close the window or close the connection!"

If it is confusing in kppp then it's only because they are probably not
too careful with terminology. "Disconnect" or "Close connection" is
better and less ambigous.


> >...
> > > Conversely, I've watched experienced users uninstalling a program in
> > > Windows 2000, and then wasting several seconds wobbling between the
> > > `Close' button at the bottom of the Add/Remove Programs window and
> > > the close button in the window's title bar, wondering which one they
> > > should click. The window manager already provides a close button in
> > > the title bar for non-modal windows, so the `Close' button at the
> > > bottom shouldn't be there.
> > 
> > Again, an interesting example. What you're forgetting though is that
> > not all users use the title bar buttons.
> 
> Only because you're going out of your way to make sure they might not
> want to.

People were using GUI:s without using the title bar buttons before I
ever got started with computers. It's not something I invented.

Aside of the issues of forcing relearning a lot of users, application
widgets are usually both more descriptive (since they can include also
text labels) and accessible than their window manager counterparts. This
is why some people prefer them, and why there are users that *only* use
those widgets and not the window manager ones.


> >                                          Why should they?
> 
> To close the window!

This can always be done via window/application widgets. The rare
exceptions are "palette" types of windows, but these are in general only
duplicating functionality that can be used and accessed also otherwise.
Not so with instant-apply preference windows. The whole idea of a
preference window is to gather application preferences and present them
in a usable and accessible way for all users.


> >...
> > Note that I'm not saying that title bar buttons aren't useful (they
> > certainly are), I'm just saying that some users simply don't use them,
> > and are not used to use them, even if they know that they exist, and
> > are usually terribly confused by any special dialogs that don't leave
> > them any "obvious" way to close them. I've witnessed that many times
> > during computer classes.
> 
> Sure, it's an investment. You remove the redundant `Close' buttons, and
> those coming from MS Windows will waste maybe a grand total of 30
> seconds the first day, getting used to using the window manager's close
> buttons instead. But after that, they'll be saving somewhere in the
> region of 0.5 to 2 seconds every time they use a utility window, as they
> no longer have to wonder (even subconsciously) which of the two close
> buttons they are supposed to click. Within a couple of weeks, they'll be
> better off.

Again, you assume that *all* users are confused by several ways of
closing a window, which we know isn't true.


> > In general it seems many users don't use the title bar buttons simply
> > because they find it difficult to remember what the tiny images
> > represent, in a similar way to why many users often don't use
> > icon-only toolbar buttons but prefer named menu entries or toolbar
> > buttons with text.
> 
> Again, that would be a bug in the window manager or theme. Closing a
> window is a pretty basic operation, and if the window manager theme
> doesn't make it obvious how to perform that operation, the theme is borked.

Why should that warrant that we should deliberately make the situation
worse?


> >...
> > > 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.

Please provide links to usability studies then. Are there studies where
all users (or even the majority of them) were confused and slowed down
by a Close button at the bottom when they wanted to exit an
instant-apply preference window?

Since you are so certain that this slow-down applies to *every other
user*, you surely must have some backup, do you?


> >                          It doesn't slow down the interface for "every
> > other user". On the contrary it gives a lot of users a familiar way to
> > close the dialog, because they are looking for dialog buttons.
> 
> Well yes, that's another thing wrong with the idea. Giving utility
> windows `Close' buttons makes them look like dialogs, when they are
> not.

We were talking about instant-apply preference windows, not utility
windows in general. The different size of a preference window, the
various controls and the single "Close" button at the bottom should be
fairly prominent indicators that this is preference window, not a
question type dialog.
Question type dialogs rarely include more than one control, and "Close"
is terminology used for closing windows.


> This in turn causes frustration because there's not nearly as much
> visual indication of whether a window is modal or not as there otherwise
> would be. You're muddying the UI language.

What has the close button to do with the window being modal or not?


> > 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.

Only if you assume that everyone uses the same window manager.


> 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 ...

The mnemonic characters are indeed important and do change (even if they
are still clearly marked), but it is the ability to always use Tab to
access all controls that is considered by many the most powerful thing
with keyboard navigation.
With a Close button, you can *always* use and finally close a preference
dialog with just the keys Tab and Space. Those two keys are the only
ones you have to know about, and they are standardized keyboard
navigation keys in a lot of desktop environments.


> >                                                           Clearly a
> > dialog close button is a help to accessibility.
> >...
> 
> Nice try. But if that were really true, why limit it just to utility
> windows? If it's a help to accessibility, why not have a `Close' button
> at the bottom of all windows? Web browser windows, e-mail composition
> windows, terminal windows, the lot?

Because these windows already have a standardized means to exit them
easily with just keyboard navigation. See the File/Quit and File/Close
menu entries.


> (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.)

Why would that be? Mnemonics to open menus are clearly labeled and
immediately visible.

How is using those more difficult than getting focus to the wm close
button using the keyboard (not possible at all, last time I checked), or
figuring out a wm shortcut that you have to start a seperate application
just to make visible?
If you are seriously suggesting that this is easier, you a) haven't
tried or are b) making things up about keyboard navigation. Or both.


> Here's an exercise for you. Compare these three windows:
> ,---------------------. ,--------------------. ,---------------------.
> |[X]:::: foo :::::::::| |[X][X]: foo ::::::::| |:::::::: foo ::::::::|
> |---------------------| |--------------------| |---------------------|
> |                     | |                    | |                     |
> |                     | |                    | |                     |
> |                     | |                    | |                     |
> |                     | |                    | |                     |
> |                     | |                    | |                     |
> |           ( Close ) | |                    | | ( Close ) ( Close ) |
> `---------------------' `--------------------' `---------------------'
> 
> There is exactly the same design problem in all three. You apparently
> think the first one is ok. Do you think the second and third are ok as well?

No. The second and third are just redundant because they widgets in them
can only be accessed the same way.


Christian