Re: [Usability] Control Center Appearance Capplet

[Calum Benson <Calum Benson Sun COM>]

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.

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

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

It's also the case that many changes in preferences windows are very
simple (turning a checkbox on or off, or selecting a different list
item), so often you're going to be able to remember the previous
setting, and restore it manually just as easily as clicking Undo.  You'd
probably want 'dialog undo' to treat doing that as if the original
change had never happened, but that's then inconsistent with how
'document undo' usually works, so we'd be messing with people's mental
models a bit.

One argument in favour of Undo is that some settings are certainly less
easy to restore, e.g. deletion of an item from a list.  Although if Undo
could take care of that, so could Revert :)

A random-access undo a la Photoshop might be more useful (as suggested
in http://bugzilla.gnome.org/show_bug.cgi?id=95110), but feels like
overkill for a window in which you're rarely going to change more than
one or two things at a time anyway, in most visits.

Also, if you have Undo, you're probably also going to want some sort of
Redo too (if nothing else, so you can quickly compare before-and-after
states), which potentially adds even more complication to the whole
situation...

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

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            GNOME Desktop Group
http://ie.sun.com                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems