Re: Theme Set, part two
- From: Seth Nickell <snickell stanford edu>
- To: Seth Nickell <snickell stanford edu>
- Cc: desktop-devel-list gnome org, bill haneman sun com, calum benson sun com
- Subject: Re: Theme Set, part two
- Date: 28 Aug 2002 23:03:32 -0500
Oops, this message got filtered out by mailman because I included too
much image data in the attachements...
"Attachements" in question are at:
http://www.gnome.org/~seth/theme-set-editor.png
http://www.gnome.org/~seth/theme-set-selector.png
Text of message included below:
(sorry for the new thread, I can't figure out how to attach files from
my web mail client, and my mailer, which doesn't work behind the
firewall at work, doesn't have the thread yet)
I did some quick mockups (in glade) for an alternate proposal for the
theme set preference page using elements of Bill & Calum's as well as
incorporating my own comments on the issue. They are attached.
1) I do not think fonts, background, and other elements should be
changed from this page. I think menu/cc entries and tabs are both
organization tools toward the same end.
Seperate cc entries should be used when the division is at the primary
category level For example, I might say I was going to change the
background even if I were going to only change one little aspect of the
background, background is the most natural level of description[1].
Categories that are more broad than people would naturally use are going
to increase incidence of people wandering through categories looking for
an item a lot.
Tabs get used when we are breaking items up not because the user would
think of them as seperate categories, but because we need to find
reasons to break the items up for space reasons. So in the "chair"
category we might have "plastic outside chair", "kitchen table chair"
and "antique wood chair" categories because each one had a lot of
preferences you could set.
My claim is that "font" and "background" are both at the primary
category level for most users, and a generic "appearance" category is
sort of like "furniture"....it follows the nice heirarchical information
tree but is a broader category than is good. If I see a font cc
category, I can be pretty sure that I can change the font size, face,
family, weight, etc from there. Would you be immediately sure if you saw
"Appearance"? My guess is that at best you would have to scan the entire
list of categories to make sure there wasn't a better item, and at worst
you would try opening something else instead first[2].
2) Lets say we put Font in its own category. So we have a problem now,
because for a11y reasons its important to make it easy to set font (in
particular) along with appearance. Every interaction we make user's with
vision trouble go through to get to a system they can use without major
difficulty is a big problem. I propose that while we do not *generally*
expose the ability for theme sets to alter the font and background (in
other words, we don't provide the ability from the editor interface), we
provide the technical ability. The accesibility themes can then specify
larger/different fonts (and perhaps a plain background to reduce noise)
in their themes.
3) I put a random idea in the mockup which is allowing the accesibility
themes to show up in the list with a larger font, to make it just a
little easier for user's with vision trouble to escape a hard to read
setup. Bill & Calum can probably comment this would be at all useful.
Another idea would be always placing the high contrast theme at the top
of the list.
4) I'm still a little unsure about handling of theme
installation/removal sort of operations. In some sense I like the idea
of shifting these abilities over to the file manager (the "Open Theme
Folder" button). I still included a "Delete" button... not sure exactly
why though. I want to think about this issue more.
-Seth
[1] A little cognitive psychology on human categorization: People tend
to categorize things at three distinct levels. One empirical way to sort
these is by reaction times, which tends to sort things into three
categories, of which the middle category (containing items like chair,
table, pop, etc) tends to be noticably faster for people to access
information from. There are other methods too, but they all tend to
produce similar categories and levels of categorization. A rule of thumb
is that the most basic categorization level (the middle levnel) is the
broadest category that a person can visualize an exemplar of the
category, or what a person will usually call something if you ask "what
are you sitting on?" or "what are you looking at?" (so for example,
"chair" is at the primary categorization level, whereas "furniture" is
not). Clearly context does change people's answers so if you ask
questions like "what's that?" and point people will assume you already
know it was a chair and might say "rocking chair". The important point
is that people have more ready access to information at a particular
level of categorization. More vague, or more specific than this and
people make more mistakes and are slower to access information.
[2] I have actually observed problems with this on MacOS 9, which does
have the more generic "Appearance" category.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]