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

[Kenny Graunke <kenny whitecape org>]

<quote who="Christian Rose">

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

Perhaps. As I mentioned, the family and friends I've observed never use the
menus to close things...but perhaps.

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

Okay. Though I do think that everyone should know what the close button does
- knowing the basic titlebar buttons is pretty essential to using the
computer...I *definately* learned what the close button was when I first
started using a mac - and there it is used a lot.

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

Sure. I suppose the users you've observed work differently than the ones I
have.

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

I suppose...I honestly can't imagine not knowing what the close button is
for - at least not for people coming from environments such as Macintosh or
MS Windows. But I'll take your word for it...

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

Sure.

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

Consider this policy changed. As I alluded to in my mail earlier today, we in
the GNOME project _must_ work towards better integration between WM and the
toolkit, applications, and rest of the desktop. Everyone I have talked to so
far in the usability project has recognized that we need the WM to cooperate
and be a part of the desktop that functions well with the other pieces, not
just some part that we can rip out and put any old thing in. If we expect to
make a decent desktop environment, we cannot cling to this no-assumptions
rule anymore. We took a step in this direction switching from Enlightenment
to Sawfish - Sawfish is smaller and integrates better with GNOME (because it
overlaps less). Enlightenment did not fit the desktop at all - it seemed
like something thrown in just because we needed a window manager. Sawfish
fits better, but it can be improved further. Windows, Macintosh, and KDE all
have *much* tighter integration between the WM and the best of the desktop,
and I believe they are better off for it. Under KDE, you can still change
the WM - but most people don't - there is no real reason for them to want
to, and kwin (or kwm in KDE 1.x) integrates and fits best with the desktop
anyway.

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

There is a standard keybinding for the default GNOME desktop, power users
will memorize it. Keybindings for this kind of thing are mostly for power
users anyway - the mouse is always available if they don't know.

That is a good point about accessibility; I am not an expert in that. I do
think that a keybinding is OK, though I guess there isn't anything you can
tab to to do that. As an aside though: what about minimizing, maximizing, or
other features? How would you access those via keyboard-only? Keybindings.
If that's not sufficient, then perhaps it is a problem which needs solving.

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

I mentioned Alt-F4, but I didn't mean "just use Alt-F4 to close the window"
- I meant that we would definately have a standard keybinding for "Close
Window", and mentioned that MS Windows (and KDE, IIRC) use Alt-F4. I was
thought it would clarify what I meant by that, not that Alt-F4 was the
keybinding we would use for this. One of Arlo's UI principles he tought me
was that users should never have to deal with F# keys. I strongly believe in
this.

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

Face it, people who navigate with their keyboard only are going to discover
shortcuts. I used to navigate via the keyboard quite frequently, and the only
way I could possibly do so was to use shortcuts. They essentially are the
way you can use your system with a keyboard only, aside from mouse-keys.
Sure, you can tab around and use space/enter in windows - but then what
about beyond windows? Shortcuts. Or to deal with windows (close, minimize,
maximize, ...) - shortcuts.

Most people just use the mouse anyway, plus shortcuts for things they do
often enough.

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

It was merely a suggestion. If user testing shows that enough users prefer
having a [Close] button in the dialog, or use the Close menu items...then
sure. I won't mind keeping it at all. The reason I brought it up was because
I thought they were only there because long time TWM users would complain,
or people who use _obscure_ themes with no window buttons would be unhappy.
(For what it's worth, I recall seeing exactly two themes with no window
buttons, not exactly something I would worry about as GNOME's target
audience.) Again, I do not mind keeping them if most users really use them,
but I will not stand for it if they are there only because of crazy
assumptions that we cannot integrate with any window manager.

> Christian

--Kenny