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

[George <jirka 5z com>]

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

A car without tyres is completely unusable, as in, it won't be able to go
anywhere.  A gnome environment without a close button is perfectly usable.
(I rarely use the close button myself)

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.

I can't even see most people agreeing on if removing the app close button
would be good even if we ASSUME the wm close button.  So it is not likely to
be an important issue as tyres.

And perhaps standard threaded tyres would not be the best solution for a high
performance car.  Best would be soft no-thread tyres.  But this car will not
be robust for normal roads.  So we sacrifice some performance and traction to
get a more constant traction on all kinds of roads.  A car designed must take
into consideration all the places where the car would go, and they can't
mandate that all roads be well maintained racetracks, and that people should
drive in only some kind of weather.

Perhaps it's taking the analogy a bit too far, but you asked for it :)

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.

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

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.

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.  Both of these
are 'transient' windows.  They pop up for me to do some change and then I
close them.  So in fact both of them feel the same to me.  Also many times I
will use the keyboard to close the window, and going to the mouse slows me
down then.  And no I still have not learned the keyboard shortcut for window
close or window menu.  It's so rarely needed I can't remember it.  I tab
over, since tab is one of the few keyboard shortcuts I remember.  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.  It's
consinstency not at work.

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

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

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

No, you're going out of your way to make sure they have to.

> 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, let me chime in with about
2-5 seconds lost every time I see a window (which to me looks like a dialog
even though you'd say not) without a close button.  I would say that I'm
probably not alone in this.  I used windowmaker for some time a couple of
years ago, and the fact that the property dialogs had no close button would
confuse me quite often.  Mostly because I can't get used to something which
is fairly rare.  I don't change settings often.  All other windows you'd
classify as dialogs and they would have an app close button.

Plus since we're making up time estimates let me counter your made up times
with my own made up times.  I'd say that a user of macos will lose no time,
especially after he discovers that closing things with the wm button is the
same as with the close button.  So since what you are saying is that people
will learn to use your way, I'm saying the same thing, they will learn to use
my way.  I for example never wonder if I should use the wm close button.  Not
even subconsiously, and definately not in the region of 0.5 to 2 seconds.

Just because there are two ways to do something doesn't mean that it's
confusing.  I'd say it's very hard to say what's confusing and for how
large a part of the population it is confusing.  We definately can't be
pulling out time intervals just based on intuition if we haven't done the
testing.

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

Except for the RMS theme which is butt ugly, I have yet to see a theme where
it is as obvious as text.  And yet again.  What if I use gnome remotely from
somebody elses box.  What if I use a public access terminal.  What if I use
gnome in my school computers where I can't choose a sane wm even, let alone a
theme.

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

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

<rant>
I hate modal dialogs with a passion.  And I never expect a modal dialog.  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?

And yes that would be a dialog, and it should be not modal.  A find dialog
should be not modal.  In fact very few dialogs should really be modal.  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.

Just because modality of dialogs fits into some theory of usability doesn't
mean that it makes them actually more usable.  Modality of any dialog is
eternally frustrating to me and I bet I'm not the only one. There are a few
exception, but any sufficently complex dialog will be annoying when modal.
</rant>

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

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

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

> 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.  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?  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.  Plus I can also right click on the tasklist item and close it from
there.  So there are 4 DIFFERENT ways to close the window when you leave the
app close button there and 3 DIFFERENT ways to close it when you remove it.
Not that much of a reduction anyway.  And this is not counting the fact that
you can also close it by a keyboard shortcut.  As a user I see no reason why
the shortcut would be the same as pressing the 'x' button so I may be just as
confused.

The idea is that they are DIFFERENT ways.  So your example is silly.

George

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