Re: [Usability] Control Center Appearance Capplet

[Thomas Wood <thos gnome org>]

On 04/16/2007 04:31 PM, Calum Benson wrote:
> On Mon, 2007-04-16 at 14:57 +0100, Thomas Wood wrote:
>
> > I am not sure 
> > if the advice in the HIG applies to this, as it is (or should be) fairly 
> > obvious that changing to a different theme will affect options not shown 
> > on the current tab.
>
> I wouldn't say that's necessarily true, especially as not all the other
> tabs (e.g. Options) do comprise the Theme, just some of them.  In fact,
> at least one of the tabs (Fonts) mixes some things that are part of the
> theme (the fonts themselves), and some that aren't (the anti-aliasing
> options).  I can't help feeling some cleaner separation would be
> preferable.

Either that, or including the remaining options in the theme. For those 
on the "Options" tab it might make sense as some themes might want to 
specify if icons are shown in buttons for example. However, it obviously 
doesn't make much sense to add font hinting settings to the theme. How 
could we separate these in an obvious way though?

> > Dialog Window
> >
> > Related to the above, I have also not set this window to be a dialog 
> > window. The window is not asking for any confirmation or action from the 
> > user, so I think it ought to be a "normal" window. We also had several 
> > bug reports[3] requesting that the previous theme capplet have maximise 
> > buttons because in contained a scrollable window. Metacity (quite 
> > reasonably) does not allow maximise buttons on dialogs, so it had to be 
> > changed to a normal window.
>
> I don't think it's too hard to argue that metacity's "no maximise on
> dialogs" theory is somewhat flawed.  Any window that benefits from
> resizing should be maximisable IMHO, although some windows may require
> constraints other than "the full size of the screen".  E.g. in this
> particular case, you probably just want to maximise the window
> vertically (something for which we even have a keyboard shortcut,
> ironically), but not change the width at all.  OSX has the upper hand on
> us here with its zoom button, I guess.


I'm not sure. After all, what's the difference between a Dialog window 
and a Normal window? Presumably Dialog windows are asking for some kind 
of user input or action, hence their name. Any other window should be a 
Normal window. I don't see that Preference windows are really creating 
any sort of dialogue with the user.


> > Undo and Redo
> >
> > There has been some suggestion on the control center list that we might 
> > like to include Undo/Redo or Revert buttons in the capplets[4], It would 
> > be useful to get some input into the usability/accessibility 
> > implications of such a feature.
>
> Well, I'll kick off that debate by restating why I tend to prefer
> Revert :)  Partly because it's essentially the equivalent of Cancel for
> instant-apply windows, so its behaviour is simple and somewhat
> consistent with explicit-apply windows. IMHO the classic, linear Undo
> concept doesn't seem particularly-well suited to such windows, where a
> change in one setting isn't necessarily related to the setting you
> changed prior to that, so having to undo the most recent change first
> can often be counter-productive.
[...]

Personally, I agree with you here. I don't think the use case is big 
enough to justify a full Undo/Redo system, but a "Revert to settings 
when I opened this window" and/or perhaps a "Revert to system defaults" 
may be useful.

> > Preference Windows
> >
> > It would be useful to clarify the above points with regards to 
> > "Preference Windows" in the HIG. The HIG specifies that preference 
> > windows should be instant apply, but does not specify a particular 
> > layout to deal with this idiom. Looking at any other operating systems 
> > where instant apply is often used (primarily Mac OS X), it seems that 
> > most preference windows do not have any Close button other than that 
> > provided by the title bar.
>
> Well, the main reason the HIG specifies an explicit Close button is
> accessibility-- at the time, the a11y team asked a number of blind users
> whether or not they felt it was necessary, and they felt that it was.
> (I don't have any more details than that to hand, I'm afraid.)
>
> As you say, that doesn't jive with the OSX model... although I think our
> a11y folks still consider OSX to be playing catch-up with both Windows
> and GNOME in terms of accessibility, and I don't know if this is one of
> the issues they have with it.

I'm not quite sure about this, as Metacity allows you to use key 
combinations to close the current window anyway. Perhaps someone can 
comment on whether this is still relevant.

Regards,

Thomas