Re: [Usability] Close buttons on instant-apply dialogs
- From: Christian Rose <menthos menthos com>
- To: Reinout van Schouwen <reinout cs vu nl>
- Cc: usability gnome org, gnome-accessibility-list gnome org, desktop-devel-list gnome org
- Subject: Re: [Usability] Close buttons on instant-apply dialogs
- Date: 03 Jan 2002 02:00:59 +0100
ons 2002-01-02 klockan 23.59 skrev Reinout van Schouwen:
> > > But it does have to provide a way to close a window;
> >
> > That way doesn't have to be a way that is obvious to mere humans.
>
> "Mere humans" are unlikely to install a wm that doesn't provide an obvious
> way to close a window.
You should have read further in my response. Most distributions will
happily install several window managers and window manager themes. We
don't control which ones those are. The user is free to choose among
them and try different themes as he likes. He might not prepared that
doing so will break anything, and we cannot assume anything about the
window manager except for maybe what's in the window manager spec
(http://www.freedesktop.org/standards/wm-spec.html), which is only a
technical spec and doesn't say anything about the user interface.
> And how is "obvious" defined? Back in 1994 I thought doubleclicking
> the topleft titlebar button was a pretty obvious way to close a window.
Even back in 1994 it was entirely possible to use a Windows 3.1 system
without ever using the window title bar buttons, or having to use them.
I know there were people that didn't use them back then and I know there
are people that don't use them now.
> > Usually more than one window manager is shipped with an operating
> > system, and the GNOME control center will happily list them all as valid
> > options. Besides, this is not just an issue about window managers, but
>
> Then, perhaps, if it isn't already done that way, the CC should only
> display GNOME-compliant wm's. If you want another one, fine, use the
> disclosure triangle. ;-)
The window manager spec doesn't say anything about user interface. I
guess there could be a "GNOME window manager and theme user interface
specification", but it is only hypothetical until it is a) written and
will be only academical until it is b) followed.
> > window manager may also change the functionality, and usually does), so
> > this makes the situation different than that for Mac OS or Windows.
>
> IMO not different enough to warrant extra Close buttons on each and every
> window.
Accessibility will be a key part of GNOME2, and we should try to help
reaching the goal of making GNOME accessible. According to the responses
from the GAP list, a dialog close button is beneficial to accessibility.
> > > have difficulty finding back the titlebar close button. (unsubstantiated
> > > claim, I know, but people who like to tweak things usually aren't afraid
> > > of poking around until they have the behaviour they want.)
> >
> > There's no need to make it more difficult than it has to be. Usability
> > is (to me) usually about making interfaces where the user *doesn't*
> > necessarily have to poke around to figure out. In this case, not
>
> I'm quoting a situation where the user *likes* to poke around. If she
> doesn't, she doesn't have to because she won't change the default theme.
Changing the theme doesn't necessarily mean that you like to poke around
(it could just be that the default colours makes you sick), nor that you
want to debug why a simple theme change reordered the buttons, or that
you want to empirically figure out which one of the reordered buttons
with cryptic symbols happens to be the close button.
> > Yes, I would in fact very much like to still see a close button added to
> > that dialog. One of the reasons is that the title bar close button is
>
> I wouldn't, it's large enough already. Each pixel more is less visible
> document text on my screen.
So you do prioritize screen space over usability and accessibility?
Usability is not about reducing pixel "waste", in fact it in some cases
it is about the opposite, to make things clear, visually distinct and
not jammed together. See the Padding + Style thread for a good example.
:-)
> > very, very small and can be hard to hit for people with motion
> > disabilities. That tiny button title bar button is an accessibility
> > problem IMHO.
>
> Current title bar/scrollbar/whatever buttons are likely too small as well
> for those people.
This very much depends on what theme is used, but I also suspect that
most themes have too small buttons.
> That's a different problem that should be addressed, but
> not a cheap excuse for having an extra Close button.
It is not a cheap excuse. An instant-apply window Close button helps
solving more problems than just the size of the button. As an example,
it also removes the need for remembering window manager shortcuts for
closing the window with keyboard navigation. Shortcuts that are likely
to differ with every different window manager used, and I might not even
be able to change the wm (think school computer). Having to start the
window manager configuration application and browse through its panels
and windows just to find out which keyboard shortcut gets rid of the
(insert ugly word here) window I first got sure seems like a large step
backwards.
> > The dialog you're quoting has other accessibility problems too... it
> > seems to be lacking keyboard navigation completely.
>
> It does indeed, but I was able to achieve the exact same things as the
> Stylist _utility window_ using the keyboard and menu navigation. The
> palette is an extra convenience for mouse users I guess.
Probably. Which makes the StarOffice example even more irrelevant as the
instant-apply preference windows surely have to be usable and accessible
by all users.
> > change to reorder/remove buttons either. GNOME was designed from the
> > beginning to be pretty much window manager/theme agnostic and that is
> > what we have to consider and base UI decisions on.
>
> I believe in a thread a few months ago it was said this is no longer true.
> But I wouldn't know if there is any official stance on this...
I don't believe that goal has changed.
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]