Re: Theme Set, part two

[Seth Nickell <snickell stanford edu>]

On Fri, 2002-08-30 at 07:28, Bill Haneman wrote:
> On Fri, 2002-08-30 at 08:11, Alexander Larsson wrote:
> > On 29 Aug 2002, Seth Nickell wrote:
> > 
> > > > 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 *completely* agree with this. And additionally, if we ever get a set of 
> > actually good fonts I don't want this wasted by people downloading themes 
> > and getting one of our old crap fonts back. There is also the issue that 
> > the font specified in the theme may not exist on the users system (and due 
> > to copyright issues can't be put in the themeball) so some possibly ugly 
> > fallbacks will be used ("Sans" for everything i suppose).
> 
> I think we can solve fallback-behavior problems (for instance, if the
> specified font does not exist, *don't change the font* ;-).  I am not
> saying we should encourage inclusion of font-face in the theme as matter
> or policy, only that we need to allow it.
> 
> I don't agree with the number-of-clicks argument, keeping Fonts out of
> Theme Set just decreases the number for some use cases at the expense of
> others.

That's exactly what it does, but not all use cases are created equal[1].
Decreasing the number of windows needed for the majority use case at the
expense of two extra clicks for the minority use case is a clear win.
You can disagree with my premise that the majority use case involves
*not* wanting font or background to be changed, but if you don't accept
the principle in the first sentence we're not talking on even remotely
the same wavelength.

-Seth

[1] Which is why things like "crack preferences" can even be
distinguished. If all use cases were of equal importance, including the
"0.5% of users want this preference" use case we'd be absolutely
flooded.