Re: [Usability] Re: Control-center styles

[Maciej Stachowiak <mjs noisehavoc org>]

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

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

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

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

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

 - Maciej