Re: Control-center styles

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Dec 27, 2001 at 11:25:54PM -0800, George wrote:
> 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.

The only example given of a window that should set WM_TRANSIENT_FOR
is a dialog window. What other kind of window would set this?


>                              . . . AND you have to accomodate broken
> applications. . . .

The kind of brokenness that is accommodated is the failure to set properties.
This is accommodated by using a normal frame.


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

So we should make the environment completely inconsistent so that it will
at least be consistently inconsistent?  Why bother?


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

The X Window System has rules like any other. Give me a example of a window
that should set WM_TRANSIENT_FOR and is not a dialog and I'll agree that
removing the close button should be handled otherwise.

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

Example?


>                                             . . . And some dialogs can't
> be transients simply because there is no window to be transient for.

Then why did it appear? What dialog could the user have requested that does
not have a parent window?


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

There are two UI I know of that users openly acclaim. These are the Mac
and OS/2. Both of these treat windows of the kind being discussed as I've
described, but Mac calls them "Modeless Dialog Boxes" and OS/2 calls them
"Settings Views". I don't think I've ever heard anyone say that he liked the UI
of Windows.  Some people are just used to because that's what got dumped
on them.  Once Windows bites the dust, it'll be GNOME that must adopt
the "Get used to it!" motto.


<snipped ctwm stuff, ot>
> 
> > >           . . . 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.

Once it is proven that the close button should not be provided, the decision
will be between a good UI made robustly, or a mediocre UI made with little
effort.


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

If you believe that everything is subjective, then I can't argue.


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

(See the rest of thread.)

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

Here's the problem in a nutshell. The users probably don't give a damn
about any of the applications.  They do not want to use applications. They
want to get something done.  When an application screws up, they almost
always blame the entire environment, unless they're involved enough to
know better.  The better the design of the environment, the less a user
has to notice some particular application.  Unfortunately, programmers
want their applications to be noticed, and with open source development that
just about all they expect, so everyone goes out to make little changes here
and there and the whole thing falls apart, or we get an about box that is
800x600.  Programmers talking about users seems to be about as meaningful
as politicians talking about children.


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

Then why bother to have any guidelines at all?


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

If the government didn't meddle in the affairs of the economy, then it
wouldn't matter.


Cheers,
Greg Merchan