Re: Control-center styles

[George <jirka 5z com>]

On Thu, Dec 27, 2001 at 09:27:18PM -0600, Gregory Merchan wrote:
> (At another point in the thread . . .)
> On Thu, Dec 27, 2001 at 05:53:17PM -0800, George wrote:
> <snip>
> > 
> > I actually frequently get confused by progams that have dialogs which
> > one must close with the wm close button.  . . .
> 
> Any program presenting a dialog that must be closed with the window
> manager close button is broken. Dialogs are closed with OK, Cancel, or
> a similar button.  A non-broken window manager will take the
> WM_TRANSIENT_FOR property or the inclusion of _NET_WM_WINDOW_TYPE_DIALOG
> in the _NET_WM_WINDOW_TYPE property to indicate that a Close command
> should not be provided. Providing one would confuse users because there
> would be more than one way to perform the same action; and which should
> that be and how could the user possibly know which closing the window is:
> OK or Cancel or some other option?

I think there is some confusion here, I was saying that property dialogs
(instant apply) without a close button confuse me.  Or a find dialog that is
such.  Or any non-modal dialog.

You cannot take away the close button from a transient window frame since
transients are NOT always dialogs.  AND you have to accomodate broken
applications.  Not doing so is just going to piss people off.  We're here to
make a usable desktop, not the perfect interface as long as you use only our
programs.  It has not been the case for some X window programs and we must
allow these to be usable.  These are not "our" programs.  We cannot fix them.
We must support them.  Tough.  We can remove the close button on our dialogs
by using the hints.  In any case, the app always needs to handle close as one
or other action as it can come from either a non-nice wm, another app, or
whatnot.  We are doing a desktop for X windows.  We need to support other X
windows apps well enough to be usable.

Also transient hint can be (and is) used for non-dialogs as well, so it would
be stupid to use it as an indication of a dialog.  And some dialogs can't
be transients simply because there is no window to be transient for.

Anyway, back to the Close button for instant-apply dialogs:

Can someone give a real reason why we should dump the "Close" button?  As
in other then "I think it will confuse users."  As far as there have been
usability studies of GNOME (not much) I've never seen this is as an issue.
Could we do a usability study on this rather then argue theoretically?

Without such a usability study or a real strong reason, I think we should err
on the side of "let's not break things that seem to work."  We're risking
confusing users that don't seem to be confused now otherwise.

> > The other day I logged into my university account and found a ctwm 
> > setup with no way to close windows. . . .
> 
> Middle-click on the desktop to get a window operations menu. Select from
> the menu and then click on the window to which you want to apply the
> command. It seems the only thing ctwm gets right is its presentation of
> workspaces. (I had to spend a few minutes trying to figure out what each
> item, other  than the workspace switcher window, would do.)

I had to change my wm setup to have the operations menu.  It didn't have it.
but this is off topic.  ctwm can look/work completely different depending on
your config.

> >           . . . It feels more robust to me to have the close button
> > on the dialog.
> 
> Not all of the broken window managers have been implemented. If you try
> to design for every possible form of brokenness, you may as well give up
> now; you'll never finish. Any masochist who decides to use a brokem 
> window manager rather than the defualt window manager deserves what he 
> gets; any sadist who installs and sets as default a broken window manger
> for the systems he administers should be rallied against with vengence
> and will probably also get what he deserves.

We shouldn't design for every brokeness.  However if it doesn't really
cost us anything, why break it for some user.  And it may not be just a
masochist.  I may be trapped in a bad wm and must use a gnome app remotely.
This HAS happened to me with said ctwm setup.  I finally bit the bullet and
found a good rc file for ctwm, but what if I'm at a public terminal.  Or
someone elses machine.  Or ...

Here robustness doesn't really cost us any effort.  I agree that spending
time making things robust for corner cases where such would take a lot of
effort is bad.  But here it takes effort to make things less robust.  And
I have not heard one convincing argument for doing so even without the
question of robustness.

>  Executive Summary
>  -----------------
>  If instant-apply settings windows are not going to be done correctly,
>   it's better to do them not at all.

I think you mean "If instant apply windows aren't done the way I think they
should be, we shouldn't do them."  Or that's the way I read your mail.  We
don't know what's correct.  Only user testing can say that.  "User testing"
hasn't shown any confusion among users of say nautilus which has a close
button on instant-apply windows (dialogs).

Also note that there is no "correct" design.  That whole question is such a
muddy one and an incredibly subjective one as well.  I also think that these
things usually follow the 'in-vogue' way of doing things and usually have
nothing to do with it being easier or harder to do.

In fact humans are quite resourceful creatures, and find their way around
even a non-perfect user interface.  In fact they prefer a non-perfect user
interface that lets them do what they need then a perfect one which doesn't.
We will never achieve perfection, partly because perfection is a subjective
thing and something which in 2 years will be considered obscolete, confusing
and stupid.

> No top-level window which immediately affects anything else without
> an explict OK, Try, Apply, Test, or similar command from the user is
> a dialog.

That's an over simplification which has no base in reality.  Unless you
decide to call dialogs some other subset of windows then what most people
call dialogs.

I'm very much opposed to such simplifications, mostly because only UI
designers know them.  Users don't.  A user doesn't care what you call a
dialog and what you call a window.  User doesn't care that the logic behind
it is some simple rule that we apply to everything indiscriminately with no
allowance for gray areas.  A user wants to use the app, not admire it's
pefrectness of interface design.  A user will also likely use many other
apps, most of which will have complete crack interface which we haven't
designed.  This is because unfortunately we don't write all software known to
man.

Usual crack disclaimer applies to this mail.

George


-- 
George <jirka 5z com>
   If all economists were laid end to end, they would not reach a conclusion.
                       -- George Bernard Shaw