Re: Theme Set, part two

[Bill Haneman <bill haneman sun com>]

On Thu, 2002-08-29 at 04:10, Seth Nickell wrote:
> On Wed, 2002-08-28 at 06:09, Bill Haneman wrote:
> > On Tue, 2002-08-27 at 22:09, Seth Nickell wrote:

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

...

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

Hi Seth:

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.  Leaving out font and
background, etc. defeats the purpose of having a simple way of grouping
and applying appearance-related settings.


I do think that the current menu may bury appearance stuff too deeply, I
would propose moving 'Desktop Preferences' to be a toplevel menu instead
of putting it under 'Applications'.
But I don't see any reason why 'Desktop->Appearance->Fonts' is unclear
or hard-to-find.  If you are worried about losing the menu item named
'Fonts' (by making it a notebook tab in a more general appearance
capplet), then I don't see a problem with having two paths to the same
capplet.

And I really disagree with the notion that this should be handled
exclusively through an 'accessibility wizard'; among other things, that
fails to address shared-desktop use cases, or cases where a user wishes
to switch between using a magnifier and not using a magnifier, or wishes
to project his/her screen onto a public screen, etc.

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.

-Bill

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