Re: Theme Set, part two



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]