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

[George <jirka 5z com>]

On Wed, Jan 02, 2002 at 11:59:10PM +0100, Reinout van Schouwen wrote:
> > > 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. And how is "obvious" defined? Back in 1994 I
> thought doubleclicking the topleft titlebar button was a pretty obvious
> way to close a window.

A button with 'Close' written on it is fairly obvious.  If we want to be more
obvious we could do 'Click here to close the window'.  But that's redundant
probably.  double clicking on the topleft titlebar button would not be
obvious to me, not even in 1994.  Imagine I am on such a system.  I will not
be able to close my settings window if I run a gnome application.

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

1) There are themse for gnome compliant WMs that don't include a close
   button, and some that include it but it is not as obvious
2) What if I use a GNOME app from a non-GNOME environment.  If we want to be
   a 'Network' environment we must allow this.  In fact I'd consider not
   allow it a regression, since it now mostly works.  I also use some KDE
   apps from withing GNOME, and I might want to use GNOME apps from within
   KDE.  Or from withing CDE, or windows, or mac, or ctwm or whatever happens
   to be running on the computer I have to use at the moment.

One of the original goals of gnome was to design things that would run in
many different environments (thus the original idea of not having a default
wm).  We should not make GNOME apps to only be usable from within the GNOME
environment.  Why are we so unwilling to accept some restrictions on what we
can do with the design.  Oh well, we can't do everything, big deal, why
should we exclude certain valid use cases, just to get some questionable
improvement.  Questionable because I don't think it's an improvement even if
we assume a wm close button.

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

Not each and every window.  Some windows have File -> Close menu item.  And
yes, IMO, different enough to warrant it.

Plus the fact that I use the app close buttons even if there is a wm close
button.  Not because I'm weird but because it's easier and faster for me.

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

That is assuming she is on her own system 100% of the time.  And as we all
know this is not the case.  This is also not the case if she perhaps doesn't
like GNOME, but likes some other environment.  That doesn't mean that she
likes to poke around.  Perhaps she is home for the holidays and must use her
parent's computer.  Or a computer in an internet cafe.  Perhaps she's not at
all clueful about the GNOME ways of doing things.  A button with 'Close' or
'OK' is self explanatory.  A little 'x' somewhere is not as good.

> > Staroffice's MDI windows, dialogs and palettes don't use my window
> > manager, they use Staroffice's own title bar thingie, which AFAIK can't
> 
> that wasn't the point, I was providing an example.

I've tried using staroffice and I would not use it as an example of good UI
design.

> > 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. That's a different problem that should be addressed, but
> not a cheap excuse for having an extra Close button.

It's not THE argument, it's ONE of the arguments.  Your counter argument is
that in a perfect world it would not be a problem.

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

Again we see that only those users who've read the CUA know that it's a
'utility window'.  The rest of the world seems to be convinced that it's a
dialog.  Now whoa re we designing the interface for.  CUA readers, or 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 think the consensus is that we are not completely agnostic.  That we have
some 'official' window manager that is shipped with gnome.  That does not
mean that GNOME apps should only work under that windowmanager.  A GNOME app
should NOT require the gnome enviroment unless it is REALLY neccessary, such
as for the panel which doesn't amke sense to run outside the gnome
environment.

We are designing apps for people to use.  That is, they shold be useful to
people, and not just GNOME users.

George

-- 
George <jirka 5z com>
   If I had my life to live over again, I'd be a plumber.
                       -- Albert Einstein