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

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Jan 02, 2002 at 05:04:11PM -0800, George wrote:
> 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.

The button of which he speaks was the window menu button. The menu was,
more or less:

  Restore      Alt+F5
  Move         Alt+F7
  Size         Alt+F8
  Minimize     Alt+F9
  Maximize     Alt+F10
  Hide         Alt+F11
  ---------------------
  Close        Alt+F4
  ---------------------
  Window list  Ctrl+Esc

The double-click close was a documented shortcut.

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

Are we going to stop using structures, enumerations, queues, hashes, sockets,
CORBA, XML, and all the other things that we need to make the system because
the users don't know about them?  We're talking about interface design here
and there are some language and standards that are used in talking about that,
just as there are the same in code development.


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

The user may not be running a window manager at all, so should we add a
complete frame to every window?

The user's window manager may do many things to interfere with the operation
of programs, so should we make all windows use override redirection and
grab the server while focused to prevent the window manager from disabling
the application by placing it in some inaccessible part of the screen or 
stealing its keybindings?


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


Gregory Merchan