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

[Kenny Graunke <kenny whitecape org>]

<rant>

Ok, I'm sick of this discussion coming up again and again, so I'll make my
few points here, admitting that I haven't been following the entire thread
this time, but have in past times. Not all of this applies to your message,
Christian, so I apologize, but I really want to make these points
somewhere.

<quote who="Christian Rose">

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

The user does not have to use a window manager. I can get my work done just
fine by simply clicking on the items in the tasklist to raise a window and
using desk guide to switch desktops. Nowhere does it say that the user will
be using a window manager. It's not required.

Then again, anyone who isn't using a window manager regularily probably is
asking to be ignored. It's just silly.

> Even if it has one it doesn't have to be easily recognizable as
> a close button.

This is a problem not just for close buttons, but of themes, or more
accurately, in all of user interface design. If the button is unclear, it is
poor user interface design. If different themes have things that look
differently, it can be confusing. If you have a dialogue box which phrases a
question poorly, and then provides confusingly labeled buttons, or like
Liam's kppp example, a [Close] button that could close the connection or the
dialogue - it's confusing. It's a user interface design issue, not something
isolated to this one little [X].

> Depending on window manager and window manager theme
> used:
> 
> * The number of buttons vary
> * The functions of the buttons vary
> * The positions of buttons vary
> * The ordering of buttons vary
> * The shape of the buttons vary
> * The images on the buttons vary

I've got you beat here. ;) Just to show that you can do ANYTHING with
themes, I've hacked my popular Klarth theme. You can obtain a copy here:

http://www.whitecape.org/runic/kWCOtest42-sawfish.tar.gz

Simply unpack it in ~/.sawfish/themes and enjoy - some notable features:

* The number of buttons on each side is random between 0 to 5 or so
* You get a completely different button function at random, out of:
  close, min, max, shade, menu ... no guarantee you'll get any of each type.
* The buttons are positioned completely randomly.

Unfortunately, I didn't get around to mislabeling the buttons. However, as
an added bonus, shading the window causes the button order to completely
rearrange itself. Try clicking a shade button only to discover close pops up
right under it. Nice touch, eh?

You might say I'm being sarcastic and absurd here. I am. My point is that
programs don't have to support every theme combo. If they do, they'll have
to support mine as well. Imagine the confusion this would cause a user. Bad
themes are always a problem. There's nothing we can do about it. Same for
bad taste, as mentioned earlier when the user runs no WM at all. At either
point, it's their problem.

And speaking of bad taste and more crazy themes, enjoy the GTK theme. Those
of you who have seen me working on SVGs or testing alignment code for my
sawfish themes will enjoy the pure greenness, in memory of all the hideous
colored boxes and backgrounds I use:

http://www.whitecape.org/runic/kWCOtest42-gtk.tar.gz
(requires "Xenophilia" engine, I have 0.7...)

The features: You can't read the text. Any of it. You can't see button
bevels either, so basically you don't know there's a button there unless it
has an icon. Even then you can't really tell what it does. (Red sphere,
anyone? Huh? No sense.)

So long as apps must support all themes (which they already don't - try a
dark theme like Wireframe) - they get to support this one too. So they can
hardcode overrides to hack around it. Oh, but that breaks other ones. Darn.
;) (OK, I'll stop...sorry.)

> Even if Sawfish is the default and we assume we will have a sane default
> theme, it only takes a simple theme change by the user to render any
> assumptions about the look and functionality of the present window
> manager buttons untrue.

Almost every Windows and Mac user I know uses a stock setup. I don't know
hardly anyone who experiments with themes who doesn't know how to deal with
a few odd things. Most users don't - but power users will. People love
WinAmp, and many themes for that can completely hide controls or paint them
offcenter so clicking where the controls are painted has no effect and
clicking in blank space does something. Really. I'm not making that up. And
people love it. People who use broken themes can deal.

> 
> [...]
> > > Anyway, back to the Close button for instant-apply dialogs:
> > > 
> > > Can someone give a real reason why we should dump the "Close" button?
> > > As in other then "I think it will confuse users."  As far as there
> > > have been usability studies of GNOME (not much) I've never seen this
> > > is as an issue. Could we do a usability study on this rather then
> > > argue theoretically?
> > 
> > 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. 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?").

Actually, when everything applies instantly, when I'm done, I close the
window. When you shop online in a web browser, you don't expect that hitting
the [X] button will automatically cancel all the orders you placed, do
you? Of course not. That would be absurd. It just closes the window. When
you instant apply a preference, you ought to be able to tell if you like it
or not. If not, you change it back. When you're done, you close the window.
There is no Cancel/Don't Save/Apply/OK/whatever. It's instant; when you're
done, you tell the window to go away. That's it. It's far simpler - there's
no need to overcomplicate it.

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

I must admit I have a hard time beliving the "two ways slows people down and
they wobble back and forth between the two trying to decide" bit - I'll take
people's word on it because I recognize that they spend their lives looking
at people doing this, though...

One of my reasons would be that having buttons down there makes it seem like
a dialog, not an instant apply property box, where I have to enter my
choices and then actually click Apply (Test)/OK/Cancel (Back out), etc.
-That- would be confusing: I think everything will wait for me to give the
command to do everything I said, but no - I've been telling it to do things
instantly the entire time. That's why I don't want buttons there, aside from
the fact that it's redundant.

> The danger of confusing this button with one that would exit the
> application is minimized because we use different terminology; "Quit" is
> reserved for exiting applications.

A button to exit an application? Huh? The only time I've seen a button exit
an application in recent memory is when I click [X] in my web browser's
titlebar and it's the last window open...

> > 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. Why should they? Windows are
> usually the right size to begin with, they often don't use multiple
> applications at the same time, and everything else can be managed from
> inside the applications, like File/Quit.

Actually, this comes back to my point earlier - if you only use one app at
the same time, windows are always the right size, etc - why do you need
window frames at all? I suppose you could have a window manager simply to
place them in a nicer location on screen, but other than that... :-)

Also, I don't believe in File->Quit. Quit has nothing to do with Files. It
deals with closing a bunch of windows. A bunch of windows that just happen
to belong to a UNIX process. Try explaining UNIX processes to a poor user.
If I run abiword once, and then I run abiword again from the menu, it's
going to start two processes. I can open multiple documents (each in their
own window) in each of these processes. So hitting "Quit" in document A will
close document A, C, and D, but not documents B, E, or F, because those are
in the other process. In other words, it's completely random and the user's
left guessing.

You could solve that by having multiple processes communicate. Or just make
sure that you never start two. But then again...

There's no guarantee that two documents are related. I can have a
spreadsheet which I use to balance my checkbook open, as well as a
spreadsheet open which I'm using to do my physics homework. I had opened
that and went out to lunch, came back, and decided to work on something else
(my checkbook) for a while before continuing with physics. Why would I want
to "Quit"? The two documents are completely unrelated to me, except for the
fact that they both /happen/ to be spreadsheets, and they both /happen/ to
be in the same process. It just seems illogical. When I'm done with my
checkbook spreadsheet, I close that. When I'm done with my physics
spreadsheet, I close that one too. When I close them all, gnumeric goes
away. It's as easy as that - avoids unnecessary complications. It could be a
wee bit slower at times, but I don't think it really would be. I don't use
Quit, and I haven't missed it.

This would also be a great step towards making a document/task centric
desktop, instead of an application centric desktop. This is really a key
part, and a nice step is as simple as removing Quit, IMHO.

[If you think I'm just spouting off about something I made up here, see the
KDE styleguide - they brought up some similar points; however in KDE, they
use "Quit" to close a window sometimes and "Close" other times...which
confuses me. I just want to ditch Quit completely.]

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

Somehow I feel that by making [X] the defacto way to close windows, people
would get used to it. It indeed would be odd to have that be the only way to
close some windows such as an instant apply property box - users who don't
normally use them may get confused when they see no way out. However. If
File->Close went away, as well as [Close] buttons which aren't explicitly
answering a question in a real dialog_ue_, i.e. the user has to make a
choice, not just mindlessly closing a window...then the way to close the
windows would be the [X]. Closing a window is really a window operation -
not something to do with files...it may be related in, say, AbiWord, but for
a web browser, I certainly don't think of it as "closing a file", I think of
"closing a window". The window frame is where the window operations are.

Do these users also not minimize/maximize via titlebar buttons? We certainly
can't put min/max/close/shade/resize/etc. in every window... that would be
clutter. I'm skeptical that it's _just_ Close, and not for all titlebar
buttons. Or if it is just Close, I suspect the problem is because there are
5 different ways to close windows, and the user has to figure out which one
they want to use. When it's not the one they usually use, they may get
confused. So in a way, I'm suggesting making it just two: answer the
question for a dialogue or alert, or hit [X] for a regular window. I guess
your suggestion could be to just use File->Close, and remove [X]. Or just
have two ways. That seems to perpetuate the issue, to me.

Another example I can think of is javascript popup advertisements. I'd love
to see how users who don't use titlebar buttons get around those - there is
no File->Close menu -- there are no menus at all! Sometimes there's a
[Close] button provided by the web page author, sometimes not...even when
there is, I certainly don't trust it not to pop up more ads or have weird
side effects...and certainly there isn't always one. I've seen many, many
ads which can only be closed by the window close button. We already have to
deal with them.

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

True. This is a problem, as well as the accessibility issues and such.
However, surely you have to maximize/minimize/resize/move windows somehow.
The window frames really aren't that accessible. The buttons are small, the
images can be confusing. But this isn't just an issue with Close. This is an
issue with the entire concept of window frames being unaccessible - you
can't tab to controls in them. Nor am I certain you should be.

I don't know the answer, but I think trying to say that we can't assume
anything on the window frame is usable (if a window frame exists at all) is
ridiculous and sidestepping the true issue - making the window manager
accessible.

> > > We shouldn't design for every brokeness.  However if it doesn't really
> > > cost us anything, why break it for some user.
> > 
> > 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. 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.

OK, do I:
(1) Answer a question to close the dialog, hitting a clearly labeled button
    such as [Save], [Don't Save], or such?
(2) Click the [X] in the corner?
(3) Go to File->Close?
(4) Go to File->Quit?

What do I want to do? Will Quit close more things than I want? Is this a
regular window, a dialogue, an alert? Is this a broken dialogue that stupidly
has a [X] button in the titlebar? If I click that wrongly included [X]
button instead of answering the question, what will happen? (It's
unpredictable.)

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

Indeed. Now resize the window, maximize it, minimize it, shade it, etc. Know
how? I'd appreciate it if someone on this list would fill me in. I sure
don't. This seems to be a hack because the current window frame system is
not accessible. That's what really needs fixing.

I don't know how to fix it offhand - I only know the answer is not 42. Nor
kWCOtest42. ;)

> Clearly a dialog close
> button is a help to accessibility.

...

Dialogues are where the user is asked a question, such as "Do you want to
save?" and the user clicks a button clearly labeled to answer it, such as
[Save], [Don't Save], etc. Or it asks you for information, such as: "Please
enter your name, and telephone number."
Name: [                   ]
Phone Number: ([   ]) [   ]-[   ]

I thought we were talking about instant apply boxes. Those are different.
You do your actions, i.e. set a background image, click some checkboxes,
etc. and they take effect. Then you close the window. You're not answering a
question or providing information, so it's -not- a dialogue.

(Excuse me for being picky...but to be able to communicate our ideas
clearly, we can't terms like "dialog" fuzzily...)

> Christian

</rant>,

Dekar

-- 
Windows has its place. Not in my place, but it does have a place.
- Thomas Cherryhomes