Re: [Usability] Control Center Appearance Capplet

[Matthew Paul Thomas <mpt myrealbox com>]

On Apr 17, 2007, at 1:57 AM, Thomas Wood wrote:
> I'm currently looking at integrating the various appearance settings
> throughout GNOME into a single "Appearance Settings" application for 
> the control center.

Excellent! That's the best news I've read all week. :-)

> I have made some mockups, which can be seen here:
> http://live.gnome.org/ControlCenter/AppearanceSettings

These look pretty good in general, except that it's a bit strange for 
the window to be much taller than it is wide, on screens that will 
usually be wider than they are tall.

I also think people will change their background picture far more often 
than they change anything else in the window. If the background picture 
setting is here in the fourth tab out of five, that'll be a bit 
awkward. (And if the background settings are here, why not the 
screensaver settings? They're quite similar...)

> ...
> The themes tab provides a way of saving and apply a particular group of
> appearance settings.

What is the use case for this? How many people do you know who 
regularly switch between multiple custom themes, themes that are each 
more than a couple of clicks different from a preset theme? To me it 
seems much more likely that someone will choose *one* set of settings 
they like, then after a month or two realize their choices were a bit 
garish, and tweak them a bit ... and then never touch them again. 
(Again, not including background picture.)

One simple way of remembering previous tweaks would be to have just one 
"Custom" theme, that consists of the last non-empty set of 
customizations the user made after choosing one of the preset themes. 
For example:
1.  choose theme A; selected theme appears as "A"
2.  tweak something; selected theme appears as "Custom"
3.  choose theme B; selected theme appears as "B"
4.  go back to "Custom"; get back A + the tweaks you did to it
5.  choose theme D; selected theme appears as "D"
6.  tweak something; selected D-based theme appears as "Custom",
    overwriting the previous A-based "Custom".

> This means it will change the settings on other tabs, and this is 
> contrary to advice in the HIG. However, 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.

Mac OS 8.5 through 9.1 did exactly this, and it was quite awkward.
<http://www.macintouch.com/m85_face.html#themes> Hmmm ... How did you 
end up with tabs with exactly the same names as in that old Mac control 
panel (except for Sound), in exactly the same order? Interesting 
coincidence.

One way to fix the tab problem would be to follow the general layout of 
the "Network Settings" window: have an option menu listing the themes, 
centered above the set of tabs. The biggest drawback of this approach 
would be that there would be nowhere for the theme previews to go.

Another approach would be to have a narrow vertical list of themes with 
previews (each theme name under its preview) down the left, with the 
tabs for adjusting the current theme (or auto-creating a custom theme, 
if you started tweaking one of the presets) on the right. (If you were 
determined to allow multiple custom themes, the bottom of the theme 
list could have [+][-] buttons for adding/removing them.) The biggest 
drawback of this approach would be that the name "High Contrast Large 
Print Inverse" would be too wide. (But with all respect to whoever drew 
that theme, high contrast, large print, and inverse video should all be 
compositing options in an Accessibility control panel, not a theme unto 
themselves.)

> Close Button
>
> As you can see, there is no separate close button on this window other
> than in the title bar. I know this has been discussed before, but would
> it be impossible to require "GNOME Compliant" window managers to 
> include a close button. My main reason for removing it is because of 
> the Novel usability studies that showed[2] several people did not 
> understand that the window was instant apply. I think the presence of 
> a dialog-style button bar suggests that the window is asking the user 
> for some action, when in fact this is not the case.

Strongly agreed. <http://bugzilla.gnome.org/show_bug.cgi?id=302076>

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

Good. (I think making the window maximizable will look quite daft, but 
I agree that preferences windows should not be dialogs.)

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

The main problem with this is, where would you put them? There's 
probably not consistent room at the top, and putting them at the bottom 
would risk the window being mistaken for an assistant (Back/Next rather 
than Undo/Redo). I have no good answer for this, sorry (assuming you 
don't want to add a menu bar with an Edit menu).

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

Again agreed. Close buttons for instant-apply windows; Cancel/OK 
buttons for dialogs.

> Of course, any other comments and suggestions are welcome as well.

Many of the following suggestions may be irrelevant if you make some or 
all of the other changes suggested above. I'll be happy even if none of 
these are fixed, because just the merging of the windows by itself is 
already such a great improvement. :-)

"Theme" tab:

*   The bulb icon is inappropriate when accompanying text that is always
    present and always the same. Just as with normal-size alert icons in
    standalone alerts, mini alert icons should indicate something
    unusual. An example is "The currently selected controls theme
    doesn't support color schemes", which is true only some of the time.
    But for the introductory text here, just the text by itself is fine.

*   The introductory sentence should end in a period.

*   "Save..." and "Open..." should have ellipses.

*   But what does it mean to "Open..." a theme anyway? Maybe that button
    would be better labelled "Other...".

"Appearance" tab:

*   This is where it becomes unfortunate that the previews aren't
    visible while choosing from the various menus.

*   There is a *lot* of horizontal gap between the controls and their
    labels. According to the HIG, you're allowed to right-align the
    labels in such circumstances. (Right-aligned labels are faster to
    scan, too.)

*   "Window Borders" should be "Window borders". (The label isn't in a
    tab any more, so different capitalization rules apply.)

*   What are "input boxes"? Perhaps you mean "text fields"?

"Fonts" tab:
<http://bugzilla.gnome.org/show_bug.cgi?id=160547#c10>
<http://bugzilla.gnome.org/show_bug.cgi?id=160547#c12>

"Desktop" tab:

*   This tab probably would be more obvious if named "Background".
    "Desktop" and "wallpaper" are mutually exclusive metaphors -- when
    was the last time you saw a desk covered with wallpaper?

*   Despite that indentation style being demonstrated in the HIG, it
    still looks like an accident. Try removing the indentation.

*   People want their background to be either a solid color, *or* a
    gradient, *or* a picture. Make these options mutually exclusive, and
    make them *look* mutually exclusive (e.g. as radiobuttons or a
    single option menu).

*   "Add Wallpaper" and "Remove" make no sense. There's only one
    background, that being the one you're using. It may be useful to
    have a list of "Recently used" backgrounds to switch back to
    quickly; but such a list would be dynamically generated, not
    manually managed. (In the future it may also be useful to switch
    backgrounds every N minutes; but you'd have that collection as a
    folder full of pictures ready to go anyway, so it still wouldn't be
    useful to recreate the list of pictures here.)

"Options" tab:

*   I agree with Bastien that "Options" is vague. Unfortunately, the
    best replacement name I can think of is "Other".

*   Actually I think all of the preferences in this tab are misguided,
    and Gnome would be more elegant if they didn't exist. But that's
    another story, which I'll tell if you're interested. ;-)

Thanks again for doing this integration!

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/