Re: Theme Set, part two

[Bill Haneman <bill haneman sun com>]

On Tue, 2002-08-27 at 22:09, Seth Nickell wrote:

> I did some quick mockups (in glade) for an alternate proposal for the
> theme set preference page using elements of Bill & Calum's as well as
> incorporating my own comments on the issue. They are attached.
> 
> 1) I do not think fonts, background, and other elements should be
> changed from this page. I think menu/cc entries and tabs are both
> organization tools toward the same end. 

As you know, incorporation of font and background settings into the
"Desktop Theme" is the primary motivation for having a meta-theme UI
from the point of view of accessibility.  So a 'Desktop Theme' must be
capable of setting background and font, in order to meet accessibility
requirements, as you note in your point #2 below.  However I don't see
the value in "not using" this capability for other "Desktop Themes" or
"Theme Sets" or whatever we call them.  Yes, I _know_ we aren't trying
to emulate Windoze here, but after all it (and some other OS'es) do
include background and font info in their equivalent UIs, so this is a
familiar and conventional concept, even if one can construct reasonable
alternatives.  Since we need this (inclusion of both "primary" and
"furnishings" settings in the meta-theme sphere of control) for
accessibility, why be inconsistent when it comes to other theme sets?

I also think that this proposal may be a little more complex that what
we need; I think the ability to indicate when the user has customized
the current desktop appearance settings (i.e when the current settings
are a variant of a "Theme Set") is simpler than adding "Edit" features,
and just as effective.  Besides, if we don't have some sort of
"is_custom" binary indicator, there will be an inconsistency between
what the user sees in the "current theme set" and what is actually
displayed.  So I think the indication that a theme has been "customized"
(i.e. the user has changed an appearance-related gconf key after
selecting a metatheme) is required anyway.  "Save As...", as a means of
snapshotting the current appearance settings into a new named theme
seems much simpler than the alternative of

	Duplicate->Edit

and would avoid clashes with the existing appearance capplets.

Putting the existing capplets underneath a general "Desktop Theme" or
"Appearance" menu makes a lot of sense, and using notebook tabs to group
them seems OK also, but I would put the "Theme Set" or "General" tab in
the same group, in that case.

I am factoring in "expediency" here, since we really need this for 2.2;
the more refactoring of existing capplets we do, the more we delay this
feature, and the more controversy and discussion (potentially useful as
it might be) we will generate.  So I vote for just reordering the
capplets in the menus, adding a "Theme Set" or "Desktop Theme Set"
capplet with "Save As..." and "Delete", and leaving the old capplets as
they are.

The mini-previews are potentially useful as mnemonics or to show color
schemes, but probably too small to be useful for users who haven't tried
the full-size settings before.  But the use of the list seems nice, the
resulting layout with buttons on the RHS and the list on the LHS looks
good to me.

Actually copying the font from the metatheme into the list label (a
small extrapolation from Seth's suggestion to make accessibility-theme
labels larger) is a clever idea; it does provide new useful information
that the mini-previews cannot.  It seems a little eccentric HIG-wise,
but do the advantages justify the quirkiness?

Thanks for your comments, best regards


-Bill

> Seperate cc entries should be used when the division is at the primary
> category level For example, I might say I was going to change the
> background even if I were going to only change one little aspect of the
> background, background is the most natural level of description[1].
> Categories that are more broad than people would naturally use are going
> to increase incidence of people wandering through categories looking for
> an item a lot.
> 
> Tabs get used when we are breaking items up not because the user would
> think of them as seperate categories, but because we need to find
> reasons to break the items up for space reasons. So in the "chair"
> category we might have "plastic outside chair", "kitchen table chair"
> and "antique wood chair" categories because each one had a lot of
> preferences you could set.
> 
> My claim is that "font" and "background" are both at the primary
> category level for most users, and a generic "appearance" category is
> sort of like "furniture"....it follows the nice heirarchical information
> tree but is a broader category than is good. If I see a font cc
> category, I can be pretty sure that I can change the font size, face,
> family, weight, etc from there. Would you be immediately sure if you saw
> "Appearance"? My guess is that at best you would have to scan the entire
> list of categories to make sure there wasn't a better item, and at worst
> you would try opening something else instead first[2].
> 
> 2) Lets say we put Font in its own category. So we have a problem now,
> because for a11y reasons its important to make it easy to set font (in
> particular) along with appearance. Every interaction we make user's with
> vision trouble go through to get to a system they can use without major
> difficulty is a big problem. I propose that while we do not *generally*
> expose the ability for theme sets to alter the font and background (in
> other words, we don't provide the ability from the editor interface), we
> provide the technical ability. The accesibility themes can then specify
> larger/different fonts (and perhaps a plain background to reduce noise)
> in their themes.
> 
> 3) I put a random idea in the mockup which is allowing the accesibility
> themes to show up in the list with a larger font, to make it just a
> little easier for user's with vision trouble to escape a hard to read
> setup. Bill & Calum can probably comment this would be at all useful.
> Another idea would be always placing the high contrast theme at the top
> of the list.
> 
> 4) I'm still a little unsure about handling of theme
> installation/removal sort of operations. In some sense I like the idea
> of shifting these abilities over to the file manager (the "Open Theme
> Folder" button). I still included a "Delete" button... not sure exactly
> why though. I want to think about this issue more.
> 
> -Seth
> 
> [1] A little cognitive psychology on human categorization: People tend
> to categorize things at three distinct levels. One empirical way to sort
> these is by reaction times, which tends to sort things into three
> categories, of which the middle category (containing items like chair,
> table, pop, etc) tends to be noticably faster for people to access
> information from. There are other methods too, but they all tend to
> produce similar categories and levels of categorization. A rule of thumb
> is that the most basic categorization level (the middle levnel) is the
> broadest category that a person can visualize an exemplar of the
> category, or what a person will usually call something if you ask "what
> are you sitting on?" or "what are you looking at?" (so for example,
> "chair" is at the primary categorization level, whereas "furniture" is
> not). Clearly context does change people's answers so if you ask
> questions like "what's that?" and point people will assume you already
> know it was a chair and might say "rocking chair". The important point
> is that people have more ready access to information at a particular
> level of categorization. More vague, or more specific than this and
> people make more mistakes and are slower to access information.
> 
> [2] I have actually observed problems with this on MacOS 9, which does
> have the more generic "Appearance" category.
>