Re: [Usability] Re: Control-center styles

[Matthew Thomas <mpt mailandnews com>]

George wrote:
>...
> 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.

>                                                             Or a find
> dialog that is such.

Ditto. (And it's not a dialog, it's a utility window. The buttons in a
Find window should generally be at the top right -- with the `Find'
button right next to the text field -- rather than at the bottom right
of the window, where they could be confused with the buttons in a dialog.)

>                       Or any non-modal dialog.

No dialogs should be non-modal. Being non-modal *and* being a dialog
makes it annoyingly unclear to the user whether you want their input now
or later. If the window shouldn't be modal, you shouldn't be using a dialog.

[snip stuff which Gregory knows far more about than I do]

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

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.

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

Perhaps, for that particular brokenness, someone could implement a
global `My Window Manager is Stoned' mode, which adds a `Close' button
to the bottom of every window. And hey, why stop there? Why not add a
`Maximize' button to the bottom of every window too?

>...
> > No top-level window which immediately affects anything else without
> > an explict OK, Try, Apply, Test, or similar command from the user is
> > a dialog.
> 
> That's an over simplification which has no base in reality.  Unless
> you decide to call dialogs some other subset of windows then what most
> people call dialogs.

It's not an over-simplification. Over-simplifying is when you call
everything that isn't a document window a `dialog', even if it's an
alert or a utility window. It's like calling everything which isn't a
noun a verb, even if it's an adjective or a preposition.

> I'm very much opposed to such simplifications, mostly because only UI
> designers know them.  Users don't.  A user doesn't care what you call
> a dialog and what you call a window.
>...

Similarly, many (most?) English speakers couldn't tell you the
difference between a verb and an adverb and an adjective. But they
benefit hugely from such a distinction existing.

The Microsoft Windows GUI (and KDE after it) is a pidgin UI language.
The Mac OS GUI is a bit more advanced, but it's still only a creole. In
order to make any progress (i.e. make GNOME more usable than either of
those two, so that people actually prefer to use it for reasons other
than stability or freedom), you need a language which is more varied and
more articulate.

When it comes to windows, the parts of speech for that language are:
*   no title bar buttons + buttons at the bottom
    = dialog
*   no title bar buttons + buttons at the bottom + no title + icon
    = alert
*   close button and minimize button in the title bar
    = non-modal utility window
*   minimize button in the title bar + progress meter
    = progress window
*   close button and minimize button in miniature title bar
    = floating window

Now, it's probably not the case that all of those distinctions can be
implemented with the currently avilable set of wm hints. But many of
them can be. And for the sake of your users you should at least *try* to
produce a decent language for them to use, rather than descending to the
level of pointing and grunting at `Close' buttons.

-- 
Matthew `mpt' Thomas, Internet cafe assistant and Mozilla UI guy
<http://mozilla.org/>