Re: [Usability] Control Center Appearance Capplet
- From: Thomas Wood <thos gnome org>
- To: Matthew Paul Thomas <mpt myrealbox com>
- Cc: GNOME Usability List <usability gnome org>
- Subject: Re: [Usability] Control Center Appearance Capplet
- Date: Wed, 09 May 2007 10:58:02 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]