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

[Matthew Thomas <mpt mailandnews com>]

Christian Rose wrote:
> 
> sön 2001-12-30 klockan 18.41 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. That's like trying to
design high-performance cars without being able to assume that the
wheels will have tyres on them.

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.

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

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

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

>                                          Why should they?

To close the window!

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

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

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

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

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

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

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

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?

Regards
-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>