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

[Matthew Thomas <mpt mailandnews com>]

George wrote:
> 
> On Thu, Jan 03, 2002 at 02:24:10AM +1300, Matthew Thomas wrote:
> >
> > 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.
>...
> Just because we can't make this simple assumption doesn't mean we
> can't build a usable environment.

No, but it does mean you can't make it as usable, or more usable, than
the alternatives. Granted, perhaps our goals differ here, and you just
want to be *nearly* as good as the alternatives. However, building on a
Unix base introduces enough real usability barriers as it is, without
introducing artificial barriers like `oh, we have to cope with broken
window managers!'.

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

If it is quite simple, that's a bug. Most platforms don't let you do
that unless you put *really* serious effort into messing it up, in which
case (as I said) you get what you deserve.

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

Dear me, so the person proposing the solution with the least number of
GUI elements is the one who has to spend squillions on measuring just
how much faster it makes users? I must have got Occam's Razor the wrong
way round all these years.

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

There is a lot of bad UI in Nautilus.

> > > 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.
> 
> Do you have an evidence for the case of the instant-apply window?

Yes, you just snipped it.

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

What would you have done if the terminal had been running Dekar's 
kWCOtest42 theme? Would you have started up an emacs session and begun
coding `Maximize' and `Minimize' buttons into every window in GNOME?

>                                           It would be impossible to
> then change properties/settings in this case.

Um, these are *instant apply* windows. You don't *need* to close the
window in order to change properties/settings. (I can understand your
confusion, since including any buttons on the bottom of a window is an
indicator that you *do* need to close the window in order to change properties/settings.)

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

Naturally you're used to it, since GNOME hardly uses instant-apply for
anything yet. Just as a pidgin speaker is used to talking pidgin. But
that doesn't mean we should be forever prevented from having a more
varied and efficient UI language, especially when your arguments boil
down to `but I'm used to the old stuff!' and `but our school [/window]
managers aren't required to teach it!'.

>...
> If there is only one type of window which needs to be closed by wm
> close button (the instant apply settings window), then it will slow me
> down quite a bit.

Types of window where the type is partially indicated by the close UI
being in the window manager frame are:
*   utility windows -- e.g. control panels, assistants, most preferences
    windows
*   document windows -- e.g. text documents, spreadsheets, pictures
*   floating windows -- e.g. toolboxes, system messages, formatting
    palettes, IME pads. (Imagine a `Close' button on a typical IME pad.
    It would take up more than 50 percent of the size of the window!)

Not just `one type of window', obviously.

>                    It's consinstency not at work.

Having window-closing buttons inside all these types of window, rather
than just inside dialogs and alerts, would be the UI equivalent of
having `-ly' on the end of all English words, rather than just at the
end of adverbs. Butly heyly, youly havely toly bely consistently, rightly?

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

In which case (as in the case of Nautilus) it would be basically lying
to the user -- suggesting that changes won't take effect until you OK
them, when in truth they take effect immediately.

>...
> > 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.
> 
> If we're pulling time estimates out of our asses,
>...
> Plus since we're making up time estimates
>...
> We definately can't be pulling out time intervals just based on
> intuition if we haven't done the testing.

The time range I gave is based on watching people using such windows in
badly-designed Microsoft Windows and Macintosh programs. I can't measure
it to the tenth of a second, as these people are using computers for
their everyday work rather than sitting in a usability lab. Sorry about that.

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

I wasn't exaggerating about it being immoral.

>       Where's your evidence besides that it is obvious for you?

See above.

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

I don't know, though it's interesting that your results are the opposite
of mine. Perhaps it's due to a biased sample on either your part or
mine. Or perhaps it's due to a small sample size. How long do
you spend watching computer users each day, on average? Is it more than
five hours? Is it all novice users, or all expert users, or do you have
a variety? And is it just Americans, or do you get to observe people
from all over the world?

>...
> > 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.
> 
> <rant>
> I hate modal dialogs with a passion.

Naturally. Which is why utility windows should be the rule, rather than
the exception. (That's one good reason for moving to instant-apply
windows in GNOME in the first place.) Dialogs should only be used where
a change in the parent window would make the secondary window more
confusing (or meaningless) than useful, so that it needs to be modal.
That is sometimes the case, but not often.

>                                       And I never expect a modal
> dialog.

Yes, in general window manager themes currently don't do a good enough
job of communicating when a window is modal and when it is not. As with
GNOME overall, that situation should improve over time.

>          Say I runa druid that asks me some information, say that
> information is somewhere in my document.  Unless the app is
> telepathic, it cannot know this.  So I try to go back to the
> application window to say compare the information I'm entering.  And
> ... whoops can't do that, I must close the window and lose the
> information to check that it's correct?  Huh?

No. If an assistant is modal, that's a bug. (If it's called something as
gratuitously obscure as a `druid', that's also a bug -- but that's
another story.)

> And yes that would be a dialog,

Ah, *there's* your problem. You're under the misapprehension that an
assistant should be a dialog. Of course it should not be, for the
reasons you gave above. It should be a utility window.

>                                 and it should be not modal.

Utility windows never should be modal, correct. Otherwise you're
muddying the distinction between them and dialogs (just as you are if
you give them a `Close' button).

>                                                              A find
> dialog should be not modal.

That depends on how it is used. If it is just used for initial entry of
the search terms, whereupon it goes away and there are menu items (with
keyboard shortcuts) in the document window for Find Next, Find Previous,
etc, then it should indeed be a modal dialog. Otherwise, you could open
the Find window from document A, then focus document B, then focus the
Find window and enter some text, and then get *extremely* aggravated
that the search of document B didn't appear to be working.

If it's a more persistent function, where you will often want to carry
out several slightly differing searches in succession, you have a number
of choices -- none of which involve a dialog.
(1) You could use a utility window and allow the function to be
    document-independent -- that is, provide controls for performing the
    operations on any given file or selection of files, not just the
    single file from which the window was opened.
(2) You could use a floating window which is dependent on the parent
    window -- so that it's not modal, but it gets minimized, hidden, or
    closed as the parent window gets minimized, unfocused, or closed.
(3) You could open a Find bar underneath the toolbar, which the user can
    carry out any number of searches in, and close at her leisure. (An
    additional benefit of this approach is that you can do emacs-style
    find, so that no keypress or click is required to trigger the
    search.)

>                              In fact very few dialogs should really be
> modal.
>...

All dialogs and alerts should be modal, but very few situations should
really require dialogs or alerts. If you're constantly working to
improve usability, in fact, the number of dialogs and alerts you use
should gradually decline to zero.

>         The window manager might want to keep dialogs above their
> parents and such stuff, but I should be able to interact with the
> application in the meantime.

Only if it's not a dialog or an alert. If you should be able to interact
with the parent window in the meantime, then you should use a utility
window instead.

> Just because modality of dialogs fits into some theory of usability
> doesn't mean that it makes them actually more usable.

They are part of the theory, but only as a stop-gap measure while the
hackers and system architects get their act together. Eventually, as I
said, the number of dialogs and alerts used should reach zero.

>                                                        Modality of any
> dialog is eternally frustrating to me and I bet I'm not the only one.

The injury caused by any fall from a great height would be eternally
fatal to me and I bet I'm not the only one. Does that mean we should
wear Non-Modal(TM) brand parachutes at all times? No, it means we should
avoid falling from a great height. If you don't want modality, don't use
a dialog.

> There are a few exception, but any sufficently complex dialog will be
> annoying when modal.
> </rant>

Sure. The more complex a window is, the less appropriate it is for it to
be a dialog.

> Anyway.  So a window having dialog style buttons is not an indication
> of modality.  In fact up until you pointed out to me that instant
> apply windows are not dialogs, I was perfectly fine treating them as
> such and never had absolutely any frustration that came out of this.
> In fact I still think of them as dialogs.  Dialogs are temoporary
> windows that I trigger then use and then close to perform some action
> or change some setting or property.

Sure, it's going to be hard for you to learn the distinction. Just as
it's hard for anyone, brought up beyond puberty talking a pidgin which
doesn't differentiate between present and future tense (and who never
has absolutely any frustration come out of this), to get the hang of
making such a distinction when learning a different language. But that
doesn't stop the distinction between present and future tense from being
immensely useful once you *do* learn it.

As I said, eventually dialogs and alerts should go away altogether. Now,
obviously that won't happen until several years after utility windows
are widely and properly used, which requires that hackers such as
yourself get a good grasp of their function and behavior. It'll be more
of a challenge for you to learn it than for a new user to learn it,
naturally, because you're so very used to a UI language where there is
no such distinction. But I'm sure you'll rise to the challenge.

And while we do still have dialogs and alerts, you'll see that blurring
the distinction between them and utility windows (by making dialogs
modeless like utility windows, for example, or by giving utility windows
closing buttons like dialogs have) is just a basic grammar error which
makes your UI less understandable.

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

I've never read CUA. Does that re-qualify me for the discussion? It
does? Jolly good.

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

All your utility windows are belong to dialogness! You have no chance to
click close, make your twm!

(Sorry.)

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

Ohly, definitely. Butly consistently isn'tly *alwaysly* goodly,
especially ifly youly arely tryingly toly distinguishly betweenly
typesly ofly windowly whichly *actually behavely differently*.

>...
> > 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.  I have zero clue what it is now, and I'm sure
> it is something.  All I know is that I can traverse widgets with tab
> and get to the close button and press space or enter or some such.
> Currently I can just use my very limitted knowledge of keybaord
> shortcuts to do most gui things by keyboard.  These end somewhere with
> "I use Tab to move among widgets, space or enter to activate them, and
> alt to go to the menu"
>...

Good for you. But surely you must see how that is vastly less efficient
than learning the window manager's keyboard shortcut for closing a
window. Relying on `Close' buttons is more learnable in the short run,
but less usable in the long run.

>> 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.  It is not exactly the same.  A wm close button and an app close
> buttons have different strengths.  Thus having both of them is not
> silly.  Having two app close buttons is silly because the second one
> is accessed in the same way as the first.  Same with two wm close
> buttons.  A wm and an app close buttons are accessed in different
> ways.

Alas, they're not. A window's close button can be accessed either with
the keyboard[1], or with the mouse[2]. A closing button inside a dialog
or alert can be accessed either with the keyboard[3], or with the
mouse[4]. The two different controls do the same thing, are similarly
accessible, and can be accessed with exactly the same input devices.
That is why they shouldn't ever be seen together in the same window.

[1] e.g. Alt+F4 on Windows, Command+W on Mac
[2] clicking it
[3] e.g. Enter for `OK', Escape for `Cancel', Alt+D for `Don't Save'
[4] clicking it

>        In fact you're forgetting one more way to close a window and
> that's from the window menu.  So are you suggesting to remove it from
> the window menu as well?

If the window menu was similarly accessible to the close button itself,
removing it would indeed be a good idea. (The same applies to the
`Close' item in the `File' menu.)

>                           I could be just as (as you say) frustrated
> if I see an 'x' on the window and a 'Close' entry in the window
> menu.

Yes, you could indeed. However, the `Close' item in the window menu is
considerably more difficult to get to -- either with the mouse or the
keyboard -- than the close item in the window menu. And when you have
that menu open, your locus of attention is likely to be completely
different than when you do not.

As a result, while I have seen plenty of people dither while deciding
between a close button and a `Close' button, over the past ten years I
have only seen two (2) people consistently use a menu item like you
describe when a clickable object (not counting toolbar buttons) was
available instead. One of these was a computing teacher brought up on
Windows 3.1, who always opened the window menu to choose the `Close'
item, rather than double-clicking the button to close the window. The
other is one of my regular customers, who always launches games by
right-clicking on the icon and choosing `Open', instead of just
double-clicking on them.

Both those cases are marginally tragic, but for only two of thousands to
have that problem I think is pretty reasonable.

>        Plus I can also right click on the tasklist item and close it
> from there.
>...

In which case your locus of attention is the tasklist, quite removed
from the window itself. Again, that's fine, as the items are not
similarly accessible. I've *never* seen someone use the tasklist menu to
close a window when the window manager's close button was closer.

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