Hi Guys:

This one is a stinker from accessibility POV.  Calum says we have a
plan for this; at the least we need to merge the font and theme capplets.

I know we're on the cusp of freeze here, and we may not have resources
assigned to this until Tuesday.  But can we get agreement to slip this
into RC1 post-Monday if we get it done and the docs folks agree? 
Subject to your final OK...

-Bill

My "plan" was basically what Bill said: the two dialogs are so small
that we could easily just merge them into one.  If we decide the
background capplet should be in there too (and I think it should, but
that's less of an immediate requirement), then a second tab is
probably required for that.

Stephen is about to (or may already have) added metacity theming
options to the font/theme capplets, however... I'm not sure how this
affects our ability to merge as I haven't seen his modifications yet,
but I expect them to be trivial...

Well, we really cannot make substantial (in any form) changes after
the RC - so either it happens (once all concerned people, inc docs
have agreed to having the change) before RC tarball for cc or it will
have to wait until after 2.0.0

I don't think these capplets should be merged. Metatheme was going to
handle all theme elements from a single place. This is breaking the
organization of the desktop preferences that I have been working with
after going back and forth over it for a couple weeks trying to figure
out what was best.

There are two basic organization methods here. One is menus, the other
is tabs. So the question is, do we arbitrarily use one or the other?
The differences I see between the two are... Tabs are slightly easier
to explore to find specific control elements, but they also occlude
information because you have to launch the capplet to find out what's
in the tabs. Menus on the other hand allow you to a scan a large(r)
number of categories fairly quickly. My conclusion from this is that
menus should be used as our primary category level seperator. Tabs
should be used to seperate categories users wouldn't think of but are
necessary to reduce the number of controls on the screen at any given
time.

So by way of example... If I want to change my mouse tracking speed I
probably think "mouse". That makes mouse a menu-level category. If the
mouse capplet has 40 controls in it though, we split them into tabs
"Tracking Speed", "Pointer Appearance", etc. Its better when you don't
have to use tabs, but sometimes the most sensible category has a lot
of child settings. Now... enough theory, on to application...

What this means is that unlike MacOS and Windows I'm avoiding creating
"monster capplets". These have ambiguous titles and so you aren't
really *positive* that what you want is under them. When I go looking
to change the background, I think "Background" (even if I want to
change to gradient, Background is still the natural level of
categorization, not "Background Gradient"). Similarly with "Font". I
think "Theme" is sort of a bad name because its not so obvious to many
peope (though it probably is to existing *nix users).

"Appearance" is a monster category. This confuses me when I use MacOS.
You just can't predict exactly what's going to be in it. You have to
think before you select the item unless you're already familiar with
it. And its wrong because we already *HAVE* a good system for
category-level grouping, which is menus. When I want to change the
background I do not think "I want to change the Appearance". Should
toolbar and menu settings be under Appearance? (they change
appearance...) How about Windows? etc. Its a slippery slope precisely
because Appearance is not a well defined category. And I don't think
there is a well defined thing that groups Fonts, Background and themes.

re: the usability study... I don't really see evidence that users
needed a single Appearance capplet. What I saw is that it was
confusing to have , for example, the font settings distributed
throughout all applications. I think its a major stretch to go from
that to say that they'd be confused by having "appearance" settings
distributed throughout the *entire massive huge* desktop preferences.
In fact, as I've mentioned, I think grouping under an ambiguous
category such as Appearance only increases confusion.

Looking at the dates for this... Wearing my release team member hat
I'm sort of taken aback. Post-RC1 is *not* the time to make changes
like this.

I'm quite frankly really surprised that this bug was filed now- these
capplets have been in their current form, or reasonably close to their
current form, for several months. How it was figured out after three
string freezes and a UI freeze that /now/ something needs to be done
is beyond me.

If this needs to be done for a11y purposes, then speaking for Ximian,
then fine- we'll work[1] to get it in sun_patches. But this should not
be in any community release while we're attempting to stabilize and
get something shippable. This is why we /have/ freezes- to avoid the
temptation to do something like this the weekend before a Release
Candidate.

[1]under protest, given the timing of the change and the number of
other, much, much more serious issues we have on our plate

To address some of the points (while I'm watching Germany stuff 
Saudi Arabia in the World Cup...):

- Late posting of the bug: hands up, pretty much entirely my fault.  
I have mentioned it on the lists in the past, and again during the 
ui-review three weeks ago, but mostly from a usability perspective.  
I'd taken my eye off the accessibility aspect of it until Bill 
(quite rightly) really started making noises about it again this 
past week or two.

-Metathemer: yep, it's exactly what we need, but it's not there, at 
least on Solaris, and nobody's working on it.  Unless it's going to 
be up to the job in time for Sun's release, it's not the answer, 
unfortunately.

-Usability study: okay, so I generalised in my haste :) Seth is 
right to say we only reported problems with changing fonts.  
However, we did only ask users to change fonts and wallpaper, not 
themes.  The comments we received on those tasks all pointed to 
users being overwhelmed by multiple customization categories, 
although we've certainly done a decent job of reducing the number 
for 2.0.  (On the other hand, we've introduced the extra motor 
effort of forcing the user to navigate to, find and open the right 
things on a sub-menu now, but that's a tangential argument).

"Appearance" is potentially an over-vague category, as Seth says, 
but taking the accessibility angle clarifies things I think.  From 
that perspective, such a dialog needs to contain all the controls 
necessary to let a visually-impaired user with no other disabilities 
change the visual appearance of everything on their desktop that 
isn't (or shouldn't be) controlled at the application level.  
Nothing more, nothing less :)

Any other approach increases the number of interactions a visually-
impaired user needs to make with the desktop while it's in what is a 
potentially unusable state for them, just to make it usable... which 
is of course an even bigger barrier if the user also has motor or 
other impairments.

I don't get it.  One of the reasons we split them up was the large
number of complaints from users who couldn't figure out where the font
settings were.  If you want to change your fonts, you go to the font
dialog.  If you want to change your theme, go to the theme dialog. 
It's not really obvious what chinging your desktop font has to do with
the color of your applications.  

As for the accessibility comment, I find that a bit of a red-herring.
 If we're really concerned about that, we need to write an
accessibility wizard to help you set up initial options.  I certainly
don't want to make a change like this at this point.

Fonts are *part* of the theme, it makes no sense to have to set them
somewhere other than the "theme" dialog.

It *is* an accessibility issue, but we also consider it a usability
issue.  I was shocked when I first discovered that the fonts had been
split out of the theme...  

Absolutely from an accessibility point of view, when one speaks of the
"theme" it includes display attributes of the toolkit, most
importantly default fonts and colors.

There are accessibility issues not just around bootstrapping but
around one-stop settings for user themes (by the above definition).  

To clarify:  I personally would be happier doing this in 2.0.1 given
the lateness of the hour, but I don't feel that it should wait until
2.2, and don't want us to get caught in a catch-22 that says the
capplets can't change between micro-revs.  If we can get consensus
that it's OK to change the theming ("Appearance" ?) capplet post
2.0.0, based on discussion and review, then I think that would be
fine.  Getting locked into an inappropriate capplet format for freeze
reasons would not be so nice.

Can the main interested parties other than accessibility accept that
proposal?

I was going to suggest what Jonathan suggests, namely an assistant.
Assistants are perfect for reducing "the number of interactions a
visually-impaired user needs to make with the desktop while it's in
what is a potentially unusable state for them".

We're getting into this disagreement (again) because I fundamentally
disagree with the premise of making changes that (I at least feel) are
detrimental to overall usability for a small minority of the
population. Looking at the accesibility POV doesn't really change how
I'm looking at the situation, because I've already recognized this
would be much better for disabled users, and then balanced that
against the interests of the general population and decided to go with
the latter.

However, in this case I think the problem isn't terribly hard to
solve. I see two approaches.

1) Putting a "setting up accesibility" assistant in actually reduces
the amount of time somebody is in a bad state, even compared with
centralised preferences.

2) Put centralised preferences needed for accesibility in the
accesibility capplet as well as in their "normal" places in the
interface. Ordinarily I think its bad to duplicate settings across the
desktop preferences, but in this case I think our user bases are
largely non-overlapping. That is, I don't think the majority
population is going to become confused and not be sure if "themes" and
"fonts" are located in "Themes", "Fonts" and "Backgrounds" or whether
they are in the "Appearance" tab in the accesibility capplet. So I
don't see a problem putting two places to set things into the
interface. This has the advantage that "normal" users don't have
interface changes made on them for accesibility reasons, and
"disabled" users get the advantage of having *all* accesibility
settings in a single location. No fuss, no muss.

re: usability study, I don't object to the generalisation from fonts
to include themes and background, I disagree with your intepretation
of what the user confusion meant. I don't think it meant they wanted a
single location to change *everything* (why have capplets at all? lets
just put all desktop preferences in one monster dialogue ;-). I think
it meant they were confused that they had to go into multiple
applications to change "Fonts". In desktop preferences all the
dialogues are close together, so I don't think this is a serious
problem. The problem there was that it was totally non-obvious how you
change the "application font" (GTK Theme!) vs. Desktop Font (Nautilus
Preferences!) vs. window title font (Sawfish theme capplet! ... unless
you use a different wm :-).

The categorization of desktop preferences is clear, i.e. its obvious
that fonts contains only fonts and its not hard to find background. So
I don't think this problem of "not knowing where to go" exists. If
anything I think having an ambiguous category such as Appearance
increases the "not knowing where to go" factor.

re: metatheme - one of the things I object to about metatheme is that
it handles background as well as themes. I would want that to go
before I pushed for metatheme. Background isn't part of the theme...
Themes are, more or less, shrink-wrapped packages of appearance other
people setup. Backgrounds are, on many to most computers I see,
totally personalized, often being photographs of family or scenery
they particularly like.

re Bill: fonts sure don't seem like part of the theme to me, though
maybe that's a hacker's skewed view of the world. I'll do a little
research and figure out. But...that unsureness granted...I'm almost
positive that "background" and "theme" aren't connected in most user's
minds.

re Stephen: I'm not sure why he's working on all this custom metacity
stuff. I have a Windows capplet in control center CVS that could be
finished w/o too much work. It makes me grumpy because its the
RightSolution(TM) since it handles multiple window managers
transparently rather than doing exactly the same broken thing we did
with Sawfish in GNOME 1.4 (WM-specific capplets). I even talked about
this capplet as far back as GUADEC.

re: fonts and themes: well they are certainly part of the theme in
GTK+ parlance, and they are part of the theme in Windoze parlance as
well.  It's also very much part of the Java idea of "Look and Feel"
which is what Java calls theming at the UI level.  I am confident that
this view of "theme" (i.e. including fonts) is what the accessibility
community expects and requires, but I think many if not most end-users
of other OSes have similar expectations.  

I do think, without intending offense, that there is a "hackerish"
view of themes that is not the same as what many users have in mind;
that alternative view (which I believe Seth and others are espousing)
has its roots in the theming of window manager borders, etc, which was
historically separate from "UI Toolkit" theming.
OK - so GTK+, Java, and other OS'es think fonts are part of the theme,
I believe.  Why should we break ranks over this if there is not an
uncontroversial argument in favor of separating them?

I don't think that putting font settings in the same capplet with
other parts of the theme is in any way detrimental to overally
usability, and I think the Sun HCI folks agree with me here.  I see
this as a usability win, and the accessibility angle as a harder
requirement favoring a move that is an overall usability win.

Having an "assistant" for accessibility is a fine idea but it does
*not* address the issue of separating fonts from "themes".  Also bear
in mind that RC-file themes *do* specify font sizes, so what happens
if a user selects a large-print theme from the theme capplet but
didn't select a large font in the "fonts" capplet?  I worry that this
will cause bug reports, i.e. "the theme capplet overwrote my font
settings"...  which, if the two coexist on the same page, would appear
as "selecting a theme causes the GTK+ font to be respecified" which
looks more like an integration feature and less like a bug.

Regarding "fonts are part of the theme", I don't think users see it
that way regardless of how we treat them in the code.

chema, that is just an "I say"/"he sez" argument.

As I pointed out, fonts are part of the theme on most platforms. 
Therefore users familiar with those platforms will expect fonts to be
part of the theme.  This is also clearly the expectation of
accessibility users.

fwiw i agree with seth if only because putting all these prefs into
one big dialog will make accessing them more difficult for the
majority of users.

Basically i'll have to do applications=> desktop preferences => look
and feel from the menu and than i'll have to search through the tabs
for the preference i want. as oppose to applications => desktop
preferences => fonts etc. I like the current separation. It's clean,
intuitive and easy to use.

Accessibility is an issue, but we shouldn't sacrifice usability for
accessibility. I think seth's suggestion of an assistant is a really
good comprimise.

Also i think the argument that other desktops do this therefore we
should is really weak (i'm guilty of this too). Imo we should make ui
decisions because they are right.

It's also important to bear in mind that other desktops do
occasionally do things because they've done usability testing and
found it to be the best solution, however :)

(Disclaimer: I have no idea whether that is the case in this instance,
but I do know that to a Windows 9x user, for example, a "theme" is a
complete package of colours, fonts, backdrop, desktop icons, cursors,
and sounds-- so such a user who goes to the GNOME "Theme" dialog will
be sorely disappointed in what it allows them to change).

Calum, I'll be happy to accept any reputable test results you can find
that demonstrates that Microsoft/Apple tested this and found it
better. Otherwise this is meaningless conjecture, because we can make
this argument in pretty much any situation, in which case we might as
well just copy windows pixel for pixel.

To my knowledge windows only has "themes" if you purchase an extra
expansion, and even then themes are fairly weak, insomuch as they
don't change overall appearance that much. I really doubt users are
going to be "disappointed" by GNOME's theming dialogue. Now as a side
note, I'm not sure you were implying this or not, but I really do not
want themes controlling the font. Maybe we can have a "use theme
preferred font" option or something, but it should be trivial to set
your own font and not have themes daly with it.

I once again BEG Bill and Calum to decouple accessibility from the
rest of the interface. I swear the only reason this argument is still
live is because a merged appearance capplet is better for accesibility
(and I acknowledge that it may well be). Trying to mould the standard
interface around accesibility is going to result in a compromised
interface for everyone, and furthermore, for all the same reasons that
you think having a merged capplet would be better for accesibility, it
seems it would be even better to have a *single* capplet where they
can go to change all options related to their disability.

e.g. rather than making them hunt through a theme list for the
"accessible" theme, in an accesibility capplet you could have a
checkbox "Use high visibility theme".

Seth:
there is no single "high visibility theme", different users have
different needs and different preferences, so there is no magic button
for accessibility.

Also, I reject the notion that what is right for accessibility is in
any way wrong for usability, particularly in this case.  We have a
difference of opinion about what is most usable, it's not just
accessibility folks who would prefer a more unified approach to "themes".

In my experience GNOME (and GNU/Linux desktops generally) are quite
eccentric in their idea of what "themes" are.  Independent of the
"better/worse" argument I think it's demonstrable that GNOME's idea of
themes is not a "standard" or even particularly common definition
outside of the Linux community.  We are free to choose a direction,
but it's important to be aware of where we are diverging from the
"Establishment".

I don't think Calum is speaking with his accessibility hat on when he
says that GNOME's idea of themes is far from "standard".  

I think possibly the only way of solving this whole business is to
bring back the Metathemer, and probably extend it to control things
like Mozilla, Window manager theme, and Java look-and-feel as well.  I
am not crazy about duplicated functionality in the desktop settings,
but it's certainly not without precedent in GNOME... 

Just on the Windoze idea of themes-- they were an add-on in Win95,
standard in Win98, and disappeared again in WinXP (where "Theme" is
instead used to mean what we could call the combination of gtk and
window manager themes).  So it's only fair to agree that there is no
real common understanding of what a "theme" actually means (although
I'd guess most Windoze users are still on 95 or 98, so theirs is
probably the most widely-understood definition amongst users).

I tend to agree that a working metathemer is probably going to be the
best compromise here, with Seth's idea of an 'accessibility druid'
(like Windoze has) to help set up *all* accessibility options in one
go the first time a user needs to-- after that I'm guessing it's
unlikely that they'll want to make wholesale changes to their setup,
so the current self-containted Preferences dialogs would probably
suffice.  (And if they do want to, the metathemer would be the more
suitable tool to use for wholesale changes).

So-- who's going to make the metathemer work in time?  :)

One thing...I'm was thinking about this, maybe the window manager
theme should be set in the theme capplet as well...comments, thoughts?
I can open another bug if necessary. 

My idea stems from the fact that window manager themes and gtk themes
are very similar in that they affect tha actual look of an app (how
the widgets and screen items appear, ps. i don't think fonts quite fit
in here). I think putting these items together along with a window
manager capplet ala the one seth has done but with the theming done
via the theme capplet might be really nice. 

So to sum it up, the window manager capplet would let you choose the
wm and set the wm properties (focus type etc.), the theme capplet
would let you change the look of apps (both the widgets and window
borders).

Definitely, yes... I believe Stephen is working on that here (adding
WM theme selection to theme capplet, and WM font selection to Font
capplet).

I have filed bugs for including both icons and wm border in the theme
capplet. (see bug 86231 and bug 86232) Can this bug about merging the
font capplet into the theme capplet be closed as wont fix? (that seems
to be the consensus I believe)

shouldn't be closed on that basis, there is no consensus on this bug.

FWIW here is my reasoning as to why i don't think fonts/backgrounds
belong in this capplet. I'll do it via an example.

When I think of theming, I think "How can I make my desktop look like
X?" Where X could be aqua, luna etc. This is what I consider theming.
This include the widgets, the window border and the icons. However I
usually don't associate fonts/backgrounds with how my desktop looks as
these are highly personalized. Other than the very nice anti aliased
fonts that osX does, I've never considered them an integral part of
the aqua look. Same with the background. OsX has a nice default
background but it is not an integral part of the aqua look.

I know this is a poor way to make an argument, but I can't really
think of the terminology to explain this. Perhaps someone with more UI
design background can transfer my example into theory.

As new development is taking place things are moving away from the likelihood
that the font and theme capplets will merge.  Specificly, the font capplet has
not got a pile of xft2 font rending control in addition to the the font
selectors.

Its still potentially feasibly to change the theme capplet into 'Appearance' or
something like that and move the fonts to an additional tab or two.  However,
its not going to be feasbile if either theme or font gets much bigger.

Can someone do a mockup of a shared layout and we can do a survey on
gnomedesktop.org.  No matter what the outcome this is a gnome-2.2 issue.
Lets try to resolve it now rther than during the next freeze ...

I'll try and have a stab at this, not sure I'll manage it this week
though :/  (One thing that your comment did remind me of is that
there's no way the XFT preferences should be as in-yer-face as they
currently are anyway... if anything deserves to live behind an
'Advanced' button, they do!)

If anything deserves to have its interface totally redone its the XFT
stuff... I almost had a heart attack when I saw it :-)

I don't think we need to have this as NEEDINFO just because there's no
consensus, right?

seth had proposed a simplified metathemer see this thread on desktop
devel:
http://mail.gnome.org/archives/desktop-devel-list/2002-September/msg00601.html

Mine isn't a metathemer. That's the whole poiint. That term is just
getting off on the wrong foot right out of the starting blocks.

Hey, dudes! GNOME2 keyword says "Don't forget me."

Hey just to let everyone know, JRB apparently is trying to implement 
seth's design and will try to get it in by the feature freeze.

Doesn't that rather make a mockery of the GEP system?  We haven't even
voted on the functional spec yet... (partly my fault admittedly, I
haven't posted the final version yet, will do so today)

SPAM as discussed last night. Search for 'SPAM as discussed last night' to catch
these all and delete them. :) 

Calum: in answer to your question, yes it does. [Though alternately
one could argue 'doesn't this point out a fatal flaw in the GEP
system.] Either way, bugzilla is not the best way to deal with that
particular discussion. At any rate, the capplet is in CVS- I'm going
to close this; political discussions should be on lists and technical
questions should be separate bugs.