Re: Theme Set, part two

[Seth Nickell <snickell stanford edu>]

Bill wrote:
> I'm afraid I still don't buy your argument.  If users want or need to
> mix-and-match, then they can still do that via the individual Font,
> (Gtk+-)Theme, etc. capplets.  Whereas I think we need a one-stop,
> one-click means of changing overall appearance.

1) One-click, one-stop will not happen here. Allowing fonts to be
controlled by themes will actually increase total user clicking /
locations visited:

First the user will visit the "one stop" location and change the
appearance in one click. Frequently the theme will frequently load an
attractive but unusable font (see arguments in the previous message as
to *why* I think that will happen). For many people the theme will also
overwrite the background picture of their daughter, motorcycle,
boyfriend or the scenic vista from vacation with an abstract spacey /
metallic design or (worse) a scantily clad anime character. See
themes.org screenshots for details.

Uhoh. The font was changed to something weird and/or the background
picture was overwritten. Now we have to make a second stop to rectify
the font/background and perhaps a third stop if BOTH font & background
were ovewritten undesirably. I believe that will be the standard use
scenario for the centralised system.

Are there people who would like to use the fits-with-the-theme-well cool
backgrounds from themes? Yes! Are there people who would like to use the
ornate and unusual fonts that fit with the theme visually? Yes! But I
think they're the minority (and its worth mentioning they're probably
not perfectly overlapping use cases either). So lets try to make the
interface work for them too, but don't use them as the central design
case. It turns out its easy to accomodate these users with only a little
more work on their part, and without inconveniencing the major use case.

We allow theme set authors to include a *suggested* font and/or
background (though I have other reservations about backgrounds since
they can easily triple the size of the theme set, lets assume everyone
has broadband for now). Now we have buttons in the main window of the
theme selector "Use suggested background" and "Use suggested font". The
user will be able to see what these generally look like from the
screenshot (so if there happens to be a really awesome font some people
who normally don't want theme fonts can see that and choose to use the
theme font this time). 

Its safer to do nothing than run a significant risk of doing the wrong
thing. In generaly we cannot tell which users will not want
font/background applied (I claim the majority) and which will (I claim
the minority). But because accesibility is a minority of users that need
fonts applied with as little control as possible AND we can figure out
*when* to do this so we don't run a high risk of doing the wrong thing
(when people select an accesibility theme), we automatically set fonts
for them. There's still a usability cost for many people (clicking on
the accesibility theme to "see what it is" will nuke your font and/or
background), but I think its outweighed by the usability advantage for
people who need the feature.

2) I have misunderstood you. You aren't pushing for moving the
font/background settings into the theme preference page, you are
suggesting themes work like Microsoft Plus!. In other words, themes
aren't actual settings, they are merely a tool that can apply a bunch of
related settings at the same time. While I object to this less than the
elimination of independent font/background preferences, it has its own
evils. The most important problem is that it increases conceptual
complexity. We currently have a system where preferences *live* in
particular preference pages. The user doesn't have to think about / care
that preferences "actually" live in GConf which is actually some XML
file in some hidden directory in the disk. To most users (even those who
are consciously aware of how GConf works), preferences effectively live
in a *particular* location. All of our preference pages are currently
just homes for these preferences. Its simple and uniform.

You are suggesting the addition of a new kind of "preference page" that
contains instead of preferences a tool for setting a bunch of
preferences at once. Of course, it presents itself as a preference (you
select which "theme" you want to use), which introduces the problem of
what to present when the user changes one piece of what the theme
effects (oh, say, the font), which requires the introduction of yet
another concept.... a "customised" theme. None of these things show up
in the same location of course, so the user never sees "customised"
theme get checked; it just happens when they happen to change on of teh
preferences that happens to have been set by the
multi-preference-setting "theme set" preference page.

The other alternative (and I can't quite tell which you are proposing)
is to put the preferences for, say, fonts, in BOTH the theme sets
preference page and the font preference page. This breaks the concept of
preferences as things which exist in a particular location and increases
their abstraction. Its one thing to have a shortcut for setting a
preference from another location (indicated by not presenting state,
only presenting the ability to "set" using a button or something), its
another thing to actually present a preference as living in two
locations.

> I certainly don't think that the 'Desktop Theme Set' facility should
> allow the user to select things that would not be available via the
> separate capplets.  Therefore the theme sets should be as inclusive as
> possible in order to be useful, and _must_ be so if they are to meet
> accessibility needs.  I agree with you that creators of new visual
> "looks" will often want to specify their favorite fonts as part of the
> "Theme Set", I don't see why we should make that impossible or even
> difficult.  As I said, users are still free to mix-and-match via the
> separate capplets.

Because when authors change the font, they will almost always choose
unusable fonts; there's much less incentive to touch the font if you're
going to leave it with a boring but readable font. Themes are currently
designed primarily with an interest in visual appearance. This is not
*so* bad for controls and window borders, but goes south really quickly
for text usability (fonts). And we don't want users to have to do two
settings changes per settings change. That's my whole point here Bill!
Centralising all these things *increases* expected number of "clicks"
and/or expected number of preference pages that will need to be opened.

*Additionally*, you significantly increase the conceptual complexity of
the theme interface from another simple preference page where particular
preferences "live", to a new kind of tool that sets a bunch of settings
for you.

-Seth