Re: Theme Set, part two

[Bill Haneman <bill haneman sun com>]

On Thu, 2002-08-29 at 17:56, Seth Nickell wrote:
> 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. 

I don't follow you; I think it will in many cases.

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

Or, of course, if the 'Theme Set' was so horrendous, immediately revert
it and change the corresponding 'gtk+ theme' and maybe 'WM theme'
separately,  Whatever the user thinks is easier ;-)

At least with this proposal there is a reasonable chance that *some*
theme sets will be OK out-of-the-box.  If not, the deltas involved in
reverting the bits the user doesn't like may be smaller than the actions
involved in applying all the meta-themed settings separately.

Anyhow the whole point of this is to allow these settings to be grouped;
if you do grouping then more work is required to do substitutions.  My
proposal in no way prevents people from going a-la-carte if they choose.
 
I think you are right that you have misunderstood the intention
however.  I don't think we are talking bundling the bits that compose a
theme, the proposal is to create a tool for modifying multiple settings
at once, i.e. managing and applying "Theme Sets".  The question of where
the backing data comes from is separate, and I think that should not be
the subject of this proposal.  I do think that the organization of the
relevant gconf keys, etc. falls within this topic's scope, but not how
the bits are packaged.  (please see below)

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

Yes, absolutely.  That is why I say the existing capplets and mechanisms
should stay ( at most, getting reorganized in terms of gconf key or menu
hierarchy).  This proposal is mainly for a UI that allows the user a
'shortcut' to applying and grouping settings.  It does serve the
additional purpose of giving graphic artists a nice way of providing
"skins" for the whole desktop at once, but the issue of packaging is a
separate one, and there is absolutely no need for a new "Theme Set" to
include data for every aspect of appearance.  Certainly theme sets that
provide new installable fonts would be in the minority, etc.; and if a
Theme Set includes settings values that are not valid for a given
desktop (i.e. the font is not installed, or the gtk-engine isn't
installed, etc.), then things should gracefully default, possibly with
an informative warning to the user.  Certainly Theme Sets should be
permitted *not* to specify fonts, or backgrounds, etc.

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

I don't think so; it potentially introduces a new level of grouping, but
this grouping actually reduces complexity in the abstract sense, by
allowing users to think about "themes" at a coarser level of
granularity; users don't have to know about gtk+ themes versus different
kinds of fonts versus window manager decorations versus desktop icon
sets, etc.  unless they really want to fine-tune their desktop's
appearance, in which case the Font, Theme, Window-Appearance, Background
capplets offer that possibility.

GNOME already offers multiple paths to the same end in many places, and
sometimes the added complexity is worth it because of the added
convenience.  I think that any users who would be confused by having two
different things that could change their background would be even more
daunted by an array of appearance-influencing capplets; in other words a
simple 'click to try a new desktop look' feature would be a win for
them.  Though I think we shouldn't assume that all GNOME users will be
seasoned hackers in the future, I don't think we should expect them to
be confused by having a 'fine' and a 'coarse' adjuster instead of just a
single 'go' button ;-)

I agree that putting separate controls for exactly the same thing (for
instance, a font control in the Theme Set UI and also in the Font UI)
would be a silly thing; I am not suggesting that.  That is why I feel we
should make the metathemer UI as simple as possible.  The minimum
actions seem to me to be:

1) apply a Theme Set
2) save current settings as a (new) Theme Set
3) delete a Theme Set

and a nice optional action would allow 

4) preview a Theme Set

#2 and #3 really require one another; though the simplest possible UI
would offer only #1, I think that from a user convenience point-of-view
#2 and #3 are well worthwhile.  For one thing, they address your
concerns about users wanting/needing to fine-tune Theme Sets that
contain settings they don't like.  For instance, the case you cite where
an illegible font gets used and a favorite background overwritten by a
theme set, the savvy user can revert font and background *once*, save as
a new Theme Set (and perhaps delete the old one), and forever after
things "Just Work" with a single click.

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

I totally disagree with the conclusion, sorry.

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

Right, it's a convenience feature :-)

I am not sure the user needs to think this way anyhow; gtk+ RC files set
lots of things for the user, who often does not need to be aware of them
as separate entities.
 
> -Seth
> 
>