Re: [Usability] Re: Control-center styles

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Dec 27, 2001 at 08:48:20PM -0800, Maciej Stachowiak wrote:
> On 27Dec2001 09:27PM (-0600), Gregory Merchan wrote:
> > 
> > As I stated earlier in this thread, a top-level widget for instant-apply
> >  windows is nearly complete. I already presented screenshots of what is
> >  so far the best way of doing this.
> > 
> 
> Why not make it a dialog?

For all the reasons already stated elsewhere.


> > > > >       . . . I think that, if we are going to instant apply, we 
> > > > > should add [ Help ] [ Close ] for familiarities sake. . . .
> > 
> > This is exactly the reason we must not do this. If you make the windows
> > look like dialog windows you are going to confuse people because they
> > will think that they can change settings without affecting the rest of
> > the environment.
> 
> I doubt it. I don't think the Nautilus preferences dialog ever
> confused anyone that way.

And the Nautilus preferences window was originally designed correctly.
Because it was the first and only instant-apply preferences window in
GNOME it confused users and somehow someone convinced the designers to
add a completely unnecessary and misused OK button; it should not have
been added, but being added is should probably have been labelled Close.


> > 
> > Actually, you don't. The GtkDialog widget must not be used for any
> > instant-apply windows. Instant-apply windows are not dialogs and 
> > should not hint to the window manager that they are such.
> > 
> 
> They are in fact dialogs. Hopefully modeless dialogs. Just like a Find
> window should be a modeless dialog. Why are you so convinced that
> dialogs must have no effect until you close them? I don't think that's
> what users expect.

I have not said they should have no effect until closed. I specifically
mentioned command buttons such as Try and Apply which would not close
the dialog but would have an effect.


> > Bingo. It looks bloody awful to have just the Help button down there 
> > alone. Since we should be providing disclosure triangles for more
> > advanced settings, the bottom of the window is a bad place for any 
> > sort of window controls; they would move around too much.
> 
> Do we really need the help buttons all over the place? They clutter
> the UI and 95%+ of people never use them. Can we invent some window
> manage protocol so we can have these on the title bar, where they will
> be small, out of the way, abd perhaps useful for other
> contentxt-sensitive help situations? Until we implement that, we
> should just leave out help buttons in dialogs.

They are not "all over the place". Help is either in the bottom left corner
of a dialog, should be in the top right corner of an instant-apply window,
or is available from the help menu. That's three different kinds of views
and a different place for each because of the requirements or provisions
of the view.

A dialog already has a row of buttons that apply to it, so the help button
should be with those.

The typical document view has a menubar for commands, so that is the place
for the help command.

An instant-apply window would not have a menubar or the row of buttons that
a dialog has, so commands applicable to the whole must be presented in
another way. The top-right (or top-left) corner is the best place. The bottom
row is out on two counts: it would make the window look like a dialog and 
would not be a stable place given the presence of a disclosure triangle.
The bottom sides are out on the latter count as well. A row across the top
would looks very odd unless notebook tabs were placed on the sides. (Tabs
on the bottom are out just as buttons there are.) So far as I can tell,
no one likes tabs on the side, though I don't know why this is so.

Remove help until we can get a new protocol implemented? . . .


> > 
> > (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. 
> 
> It's interesting to note that this is confusing only to Unix/X users,
> because historically not all window managers have even provided a
> close button.

Some place it on a menu like ctwm. Some got it right and didn't provide
a close button for dialogs because that would confuse the user as previously
stated. (See the next quote.)


> > 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?
> 
> On the Mac, it's common for modeless dialogs to not have any kind of
> close button and for users to close them with the WM control. However,
> dialogs with action buttons generally lack the window manager close
> button. I think it would make sense to try to provide only one or the
> other, but on the other hand not assume that all dialogs have a close
> button, both for the sake of modeless instant-apply dialogs and for
> legacy apps that sometimes have windows with no close button. 

The "Moveable Modal Dialog Boxes" and "Modal Dialog Boxes" are
supposed to have a closing dialog button. The "Modeless Dialog Boxes"
are supposed to provide close via the window frame.
(The "Modal Dialog Boxes" dont even get the usual adornment of a titlebar.)


> > >           . . . 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.
> 
> I agree that we should, in general, design apps assuming a reasonably
> sane window manager. On the other hand, the window manager should be
> designed to handle all sorts of totally broken apps, since users often
> have no alternative to these.
> 
> As for the issue of the close button, it does tend to terribly confuse
> Unix users not to have one (even if they have a window manager close
> button, they'll not realize they can use it to close the window,
> perhaps because of early bad experiences with twm).

WindowMaker and CDE, as I recall, exhibit behavior similar to the Mac.
Afaict, the window managers that do not ever provide a close button provide 
the same function through a menu. I suspect, but cannot confirm, that most
of the Unix users are CDE users. A good number probably use OpenLook; I
further suspect that most of the people befuddled by inconsistent UI are
those that have used only open source software and that they are a small
percentage of all Unix users. Perhaps the undergraduate environments have
been some oddity too. From those that I've seen the admins don't give a
damn about the users, because they tend to be insignificant. The graduate
labs I've seen usually provide a decent environment such as CDE or the IRIX
desktop (name?). OpenLook, at least, is often available for whatever reason.


> > 
> > 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.
> 
> This is an unusual choice of terminology. I've seen many experienced
> UI designers refer to modeless instant-apply preference windows as
> "dialogs". I've never seen any of them except you deny they are
> dialogs. While you are welcome to your peculiar choice of terminology,
> it probably should not be used to drive the UI design of GNOME.

And how many were not Mac designers or trained by the same? My choice is not
peculiar. The concepts I'm presenting are consistent with those in the CUA,
but I do not use the odd language that they use. (Maybe I should.)
The CUA is the basis, to varying degrees, of Windows, CDE, and OS/2.
Windows has legacy bits from the age of fullscreen console apps.
CDE, at least recent versions, is almost right on.
OS/2, coming from the same source, follows most closely.


> > An instant apply settings window is another way of looking at and
> > manipulating data. If you have a file open in a word processor and
> > choose to view the properties of the file, by way of either the file
> > manager or a similar command chosen from the menu shown by the word 
> > processor, then in both of the windows present (word processor window 
> > and settings window) you are looking at the same data. The word
> > processor window shows the data in a composed view, whereby you do
> > not see markup and paper settings but instead see their effects. The
> > settings window would probably not show markup either, but would show
> > paper settings and other such information applicable to the same 
> > class of data that the file is. Because you are looking at the same
> > thing in both windows, you should expect actions taken in one window 
> > to affect the other window. It's almost as if you had issued to emacs
> > the C-x 5 2 command and changed the font used by one of the frames.
> 
> I don't think users would understand your distinction very
> well. Although I do think properties windows specific to a particular
> object should not be treated the same as a preferences pane or the
> like.

And they don't have to do so. That's not the point of this. We don't go 
about telling users that the menu that just appeared is actually another
window which contains a bunch of little windows either. But as the developers
of the environment we need the distinctions. I don't know what the underlying
language of the other environments has been, but at least Mac and OS/2 users
will attest that they never noticed any of the distinctions . . . everything
just worked.

>  - Maciej

Cheers,
Greg Merchan