Re: [Usability]Re: An alternative proposal for instant-apply vs. non-instant-apply

[Christian Rose <menthos menthos com>]

On Fri, 7 Sep 2001, Adam Elman wrote:
> >It may the case that you don't need to worry about those users without
> >close buttons on their windows, but that doesn't mean that one should
> >eliminate the close buttons (whatever the label) from the dialog.  The
> >vast majority of windows can be closed with a button on the window or
> >with a pull-down menu.  The exceptions are so rare that whenever I
> >encounter them, I find myself pondering for all of about 5 seconds
> >before I remember the close button on the title bar.
>
> Do you generally use the actual pull-down menu or a key binding?  I
> can't remember the last time I actually used a pull-down menu to
> close a window; I nearly always use either an application key binding
> or the WM key binding to close a window.  I think it's important that
> there _be_ a standard WM key binding to close a window, but assuming
> there is (and there will be in the common case), it's not necessary
> to have a close button for a dialog box which is what I would call an
> "object property" box, as opposed to what you describe below:

I think there is too much assumption here about everyone using the window
manager buttons to close applications and dialogs. I don't have user
testing data on this, but I would argue that it isn't true. I believe
there are many users that use dialog buttons and the application menus
exclusively - I know this is true for both my parents at least.

The reason seems to be that whenever they do a task, to perform it they
look for buttons and menu options in the application. They are used to be
able to do everything this way, since you normally can do everything
this way, including controlling the application, exiting dialogs, and
exiting the application via File/[Exit/Quit] and the like. They always
forget about the WM buttons. I also don't think they are unique in that
aspect, since I've seen a lot of other users also always exiting via
File/[Exit/Quit]. It's handy for those who are not savvy with shortcuts
and what the buttons represent, because these users use the menus
frequently and thus the File/[Quit/Exit] entry is the most obvious way to
exit.

The step to dialogs isn't far - if you are not already used to exit
applications and dialogs with the WM close button, using this way to exit
a dialog isn't obvious at all. They look for what's actually inside the
dialog...

Considering this, I really think we should have some user testing on this
before we even consider removing all button ways of exiting a dialog.


> >The dialog ought to typically walk the user through a series of
> >operations.  The button on the dialog is the user's way of communicating
> >his intentions to the dialog ("no, i didn't mean to do that", or "I'm
> >done now", or whatever).  Having the only way to exit that conversation
> >being clicking on the close-box breaks the conversation away from the
> >focus of the rest of the dialog.
>
> This is a specific kind of dialog box.  Some dialog boxes are really
> there just to modify properties of an object; in that case the dialog
> box is not so much enabling a conversation but rather collecting a
> set of controls; the user's attention is focused on the object in
> question.

I agree, but the next focus of attention, when the preference is changed,
is "how do I close this". If you are not used to using the wm buttons for
closing, you are lost in a button-less dialog.


> >  > > If we use this strategy with no buttons in instant-apply dialogs and
> >  > > only relying on WM buttons, a user can easily put himself in the
> >  > > position of an unusable desktop just by trying out some themes...
> >  >
> >  > So they can figure out how to close the windows via some other way (a
> >>  keybinding, a right click menu on the titlebar, or ...). Or they can change
> >>  back to a theme that isn't so ridiculously broken.
> >
> >I thought we were trying to make things easier to use....
>
> We are, but that doesn't mean we should make it possible to do things
> in multiple, redundant ways; we want to minimize the visual and
> conceptual clutter the user has to deal with.

I'd rather let users use the way they are used to, rather than forcing
them to re-learn because we think it's cleaner that way.

Also, we can recommend window managers and themes all we want, people
still want to change themes (and possibly the window manager). We *cannot*
assume these things about the window manager. In an ideal world we could,
but this has never been the case in GNOME, nor will it probably change any
time soon - simply because that GNOME, in contrast to KDE and many other
environments, already from the beginning was designed to be a desktop
environment, not a window manager, and that it shouldn't do the window
manager's job. It was designed to allow maximum window manager choice and
flexibility, and until that policy is changed we will have to live with
hardly being able to assume any things about the UI of the WM.

Also, keyboard navigation is crucial to accessibility. To close a
button-less dialog, you have to
1) Realize that you should use the VM for this (see above on how this is
not obvious to everyone)
2) Realize that the only way you can do is is by using some kind of
shortcut
3) Know the window manager shortcut for this.

Now comes the tricky part. How do you know this without actually firing
up the window manager configurator and look this up?

Also, someone mentioned "why not just use ALT+F4". Well in my copy of
Sawfish, ALT+F4 switched me to another desktop... so much for
standardizing. Every Sawfish release lately has also switched default
shortcuts.
Yes, we can solve this particular problem by forcing Sawfish to have
certain sane default shortcuts, but that still won't sole the problem with
education about shortcuts, and it will still only solve this for one out
of many window managers.


To summarize, I think removing every way of exiting a dialog except using
the wm is a very bad idea. It is only arguably cleaner, yet it gives a lot
of trouble and forces users to re-learn, and is also questionable with
regards to accessibility. I'd say that in a lot of ways, this is clearly
more trouble than it's worth.


Christian