Re: [Usability] Control Center Appearance Capplet

[Thomas Wood <thos gnome org>]

Firstly, apologies for the dely in replying. I often miss e-mails if I 
am not explicitly included in the recipient list!

On 18/04/07 17:53, Matthew Paul Thomas wrote:
[...]
> 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...)

I know OS X has Background and Screensaver in the same window, but I've 
never really understood the connection.

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

I imagine this is the most likely use case, but it's also nice to be 
able to create and save your own themes to share with your friends 
through websites like art.gnome.org.

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

I think you're describing the current theme manager behaviour?

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

Coincidence? Let's just say I did my homework on what different 
interfaces have been used in the past.

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

We did try something similar, but with a horizontal list. Screen shots 
are available at http://live.gnome.org/ControlCenter/AppearanceSettings
However, the whole tab ended up looking too cramped, so we will probably 
use the separate window approach.

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

Excellent. Unfortunately as you suggest, this will have to be a "GNOME 
3.0" feature, where we can change all the preference dialogs to be 
consistent.

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

Again, until we can have this consistent across all preference windows, 
I've had to revert to the old dialog style window.

[...]
> > 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 text was really just to explain to people looking at the mockup. I 
didn't have any plans to include it in the final product.

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

Open should be Install (or possibly Add?)

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

After some more feedback, people are keen for this tab to be a seperate 
window as it was in the past. We could then use the lists again and 
include previews.

[...]
> *   What are "input boxes"? Perhaps you mean "text fields"?

Almost. This colour also affects listboxes and icon views, as well as 
quite often the background in check and radio boxes. However, if "text 
fields" is more understandable, then I will happily change it

[...]
> "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?

Noted elsewhere also, and will be changed.

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

We also wondered about the mnemonics in the heading labels. In fact, are 
the labels really necessary?

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

It is possible to set a translucent background, and have the background 
colour or gradient show through.

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

As well as "Recently used", we'd want to include the system installed 
backgrounds. I can't quite imagine how the UI for this might look, but I 
imagine it would end up something similar to the OS X layout. Under OS X 
you get a choice of various standard "collections", or you can add your 
own folders to the list.

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

Probably true, but I think options like turning on or off text in 
toolbars is useful and could possibly have accessibility benefits. The 
ability to turn off icons in menus and buttons might also be useful for 
people with particular sight problems, or who just find it easier to 
recognise text than icons.

Regards,

Thomas