Re: [Usability] Decision: instant apply window buttons



On Mon, 2002-01-21 at 01:47, George wrote:
> (Hmmm, must have missed the original message or something)
> 
> > >There have been two primary objections to this approach:
> > >  1) Users will be confused and not be sure how to dismiss the dialog
> > >  2) Some window managers / themes will not have close buttons
> 
> 3) Accessibility
> 4) Being able to TAB to the close button

I think these are the same point, unless there is some inherent
advantage to being able to TAB to the close button. I think having a
global "close window" shortcut is better solution to this, particularly
because it would work for all windows.

> 5) Users do not seem confused by the presence of 'Done'/'OK'/'Close' (or
>    whatever you call it) button, which was the reason to get rid of it

No, that was not the reason. The reason was not a concern that users
would be confused, but in encouraging a "good" conceptual model for how
the system fits together. Its a longer term thing that's rather hard to
test, though I would be open to testing this and re-evaluating things
based on that.

> > >2) The "Window Manager" is responsible for managing windows. Should we
> > >try to make GNOME accomodate broken window managers who have no resize
> > >mechanism, or don't draw window borders correctly, by adding resize
> > >handles inside GtkWindow? I would hope that everyone agrees we should
> > >not. I think the situation with the close button is similar. Window
> > >managers or themes that do not provide a mechanism for closing windows
> > >are broken: they are not doing the job of managing windows adequately.
> > >Furthermore, we need a standard keystroke for dismissing windows anyway,
> > >which should work on instant apply windows too. I'm guessing that users
> > >who use a window manager without a close button are primarily using
> > >keystrokes anyway.
> 
> ^^^ Slippery slope argument

Sort of, except that I consider the movement case not significantly more
extreme. I would consider it pointing out a potential inconsistency
instead of invoking a slippery slope, but it doesn't really matter much
either way.

-Seth




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]