Re: Theme Set, part two

[Seth Nickell <snickell stanford edu>]

On Wed, 2002-08-28 at 06:09, Bill Haneman wrote:
> 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?

Actually, in the sphere of accesibility, I see arguments why theme sets
should NOT in general control fonts. It seems reasonable that even a
user with vision impairement might want to use a different theme. It
would not be good if the font were changed to a tiny or exotic font
(which I'll argue in a later paragraph is the likely outcome of allowing
fonts to be changed....for most themes).

On the usability side, please address the categorization issues. I
suspect that a quick usability test would defend my conjecture that
people will find font settings more quickly in a preference page in the
menus labelled "fonts" rather than in a preference page labelled
"appearance" (or even worse, "themes" !!!!). If this is true, I think
the arguments for familiarity you are making are more or less void.
Additionally, according to Calum in
http://bugzilla.gnome.org/show_bug.cgi?id=83722, Windows is inconsistent
between versions as to what a "theme" is, and apparently doesn't even
have the item in Windows XP. 

So putting fonts in the same page as themes on a different tab is one
thing. Letting them be controlled by the theme itself is MUCH worse:

I claim that if you make a capability reasonably straight-forward to
access most theme authors will use it, whether its really beneficial or
not. I don't think any good will come of this. How many theme authors,
however graphically talented, do you think are really going to select a
nice readable font for their theme? Many/most people are going to choose
complex fonts that look good in screenshots. And if you're going to just
use a nice readable font, why bother specifying the font anyway since
most nice readable fonts look pretty much the same, and the user is
probably already using Arial/Helvetica/Verdana/Something-Like-It anyway.
No, I predict a proliferation of otherwise nice themes that come with
horrible-to-use (but perhaps nice to screenshot) ornate fonts. That's a
net usability loss, since it means that changing themes involves
changing the theme then (in the best case where there's also a font
dialogue) changing the font or (in the worst case where "themes" provide
the primary interface to fonts) having to "customize" the theme.

So lets handle the important font changing case: accesibility (I still
think that an accesibility wizard at first login and then later
available from the preferences section is a better idea for centralising
these preferences, but I know you dislike that). But that doesn't
necessitate a totally generic mechanism.

This isn't really a reliable testing mechanism, but unfortunately I
don't have access to a good base of people to perform tests on this
summer. I made a list of items that might be themable and asked people
which ones they would like the theme to control. "Background", "font
face" and "font size" were considered bad items for the theme to
control. Somebody suggested, and I think this is an excellent idea, that
there be a mechanism for the theme to *suggest* these items, but that
they wouldn't get applied by the theme set by default. People disagreed
whether they thought skinnable applications (things like xmms and
mozilla) should be set by a system-wide theme. Some people liked this,
some people didn't.

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

I don't care if the item is called "Customize" or "Edit", but I do think
its less confusing (and less complex) to not introduce the notion of
"real system themes" and "user tweaks to those themes" and instead just
have "themes, which users can change as they like". The idea of
"customized" is *introducing* complexity, not decreasing it. Rather than
theme sets and then variation layered on top of that, the "edit" model
just has "theme sets".

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

Huh? I don't see where any inconsistency comes in?

> 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

I really don't think its useful to introduce saving and "themes that
have unsaved changes". This isn't a document from crying out loud! Being
able to have themes with unsaved changes is a major increase in
conceptual complexity. If you can't have unsaved changes, then "Save
As..." no longer follows the right order of operations, since you'll
need to "Save As..." before you actually make changes, and then make
changes in the resulting theme. A think "Duplicate" more naturally
expresses the natural order of usage...but I think that's less important
a point than avoiding the whole "saved vs. unsaved themes" concept.

> and would avoid clashes with the existing appearance capplets.

I don't see any clashes with existing appearance capplets, please
explain further.

> 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 argue that putting fonts, capplet, background, etc under the same menu
item in different tabs was a *BAD* idea, just to clarify.

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

I don't see how "Save As..." and "Delete" is any particular advantage
for expediency here.

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

I think the quirkiness is justified, but I only think allowing themes to
modify fonts is only an improvement to usability in the case of
accesibility themes. In general, I think its a bad idea.

-Seth