 | Check out the proposed skin! You can currently check out the proposed skin changes in action on QA1-US. The admin password is 'sakaigers' Peter Knoop |
| Files Posted For those who have asked how to accomplish some of this, files are attached |
Fine-tuning the 2.2 skin
Looking back over old usability reports and user surveys, it's striking that the 2.2 default skin resolved a host of problems caused by people just not being able to see what they needed.
Are folks open to fine-tuning what we have? Here are five suggestions for ongoing improvement in the skin, mostly in tool.css, which was not the main focus of the 2.2 skin effort. Maybe concerned parties can reach a consensus and lobby to get some of this into the 2.4 or 2.5 releases.
Improving the skin is incredibly cheap compared to other UI changes; it's the low-hanging fruit, and we should grab it.
1. Add an underline to the default links within the tools.
These still don't show an underline, and there continue to be situations where this lack makes important links within tools hard to discern for users at institutions that haven't adjusted the links in a local skin. Most links fall into some category that is underlined, so one learns that links are underlined--and then some aren't.
Default skin:
New tools:
2. Use colored folder icons
Why: Users often complain that it's hard to follow the hierarchy of listings in the Resources tool. The problem is an offshoot of deeper issues with the tool design, but using color to differentiate folders from files offers one helpful clue for most users.
3. Show column borders on sortable lists
Why: It's easy to miss the link as a clue that many tables offer sortable columns. Showing column borders calls attention to the column structure. The skin illustrated also uses a small graphic.
4. Eliminate default margin-bottom and padding-bottom on h3, h4, h5 tags in tool.css
Why: The people who designed html and the first browsers were brilliant, but they didn't know typography or consult anyone who did. The default for most html elements comes with an em of vertical padding or margin, which interferes with visual chunking unless it's corrected in the css. Most Sakai forms don't chunk information effectively, and reducing space after the tool-level heads helps a little. It also slightly reduces page length and the ever-present need to scroll. In the first example just above, margin-bottom and padding-bottom are both set to 0.
5. Implement a more literal tab metaphor in the sites listing.
Here we probably enter more debatable realms.
There have been many observations that the significance of the sites in navigation, and the user's location in the sites, aren't as clear as they could be. Some of this has to do with the "My Workspace" site being conceptually quite different from other sites, but some of the confusion may be ameliorated visually by giving this area more graphic prominence and differentiating it more dramatically from other links.
Is there much agreement about this? The current skin has the advantage of being clean and streamlined, and the majority who voted for it in the default skin contest were probably voting for that look.
Comments?
6. Removed 2/8/07
An item suggesting that many links be treated as buttons has been removed.
Suggestions for button/icon mappings
Icons and keys: http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png
Item actions
| Button | Icon key |
|---|---|
| add | page_white_add |
| revise | page_white_add |
| reorder | page_white_put |
| permissions | page_white_key |
View actions
| Button | Icon key |
|---|---|
| remove checked | page_white_delete |
| move checked | page_white_go |
| copy checked | page_white_copy |
Application actions
| Button | Icon key |
|---|---|
| site resources | application_home |
| upload/download multiple resources | drive_network |
| permissions | application_key |
Comments (20)
Feb 06, 2007
Mark Breuker says:
Regarding item 6: what about using icons from the icon service project ICON:Home...Regarding item 6: what about using icons from the icon service project as buttons?
Feb 06, 2007
Kathy Moore says:
Can you suggest specific mappings between words and icons, and make it easier fo...Can you suggest specific mappings between words and icons, and make it easier for us to see the specific icons you have in mind? Not the set, but a handful of icons that would substitute for the specific terms that appear in the interface shown?
(If the icons are supposed to replace the words, it would require altering the underlying code and is no longer a skin-level change.)
Feb 07, 2007
Mark Breuker says:
See above for some suggestions. I think (some of) the buttons should be accompan...See above for some suggestions. I think (some of) the buttons should be accompanied by text (e.g. mouse over or right-aligned). I can imagine using icons would be quite a big step
Feb 07, 2007
Marc Brierley says:
Personally, I'm a little dubious about icons in the context of Sakai (there are ...Personally, I'm a little dubious about icons in the context of Sakai (there are other contexts where they are entirely appropriate). Users need to learn what they mean before they have selection benefit. The research we have been doing for the Course Management project and some that we are now doing at SU shows that a vast majority of our faculty users are of low to mid tech savvy. Also, many just use the CMS in a significant manor just at the beginning of the term, not everyday. So having to relearn something is not attractive.
Look here for an interesting thread from the ixdg.org professional group on this issue:
http://www.nabble.com/Lists---icons-or-no-icons-tf2714519.html
Feb 07, 2007
Marc Brierley says:
I really like all of these suggestions (way to go Kathy!) except #6: links and...I really like all of these suggestions (way to go Kathy!) except #6:
Feb 07, 2007
Stephen Marquard says:
I'm in favour of 2, 4 and 5, opposed to 1 (our local skin does underline on mous...I'm in favour of 2, 4 and 5, opposed to 1 (our local skin does underline on mouseover for links, which is clear enough), definitely opposed to 6, and neutral about 3.
Feb 21, 2007
Seamus Byrne says:
Should links be underlined in all states? I believe so! As a designer I like th...Should links be underlined in all states? I believe so!
As a designer I like the clean and trendy look that a link with no underline has. However, after conducting user testing for UC Berkeley's new skin for bSpace, I am not so sure.
I originally wanted to make the interface more sophisticated by removing the underline from the primary links in all the tools. To my dismay, 27% of all participants did not see these as links, and did not "x" them as clickable on in the screenshots on the paper prototypes.
This suggests that many users still rely on the good old-fashioned underline to communicate textual interactivity.
Feb 22, 2007
Stephen Marquard says:
OTOH you can't move your mouse over a piece of text on a printed screenshot to s...OTOH you can't move your mouse over a piece of text on a printed screenshot to see what it does. So a more meaningful methodology for testing user discovery of links would be to watch users interacting with the application, rather than ask them questions about paper.
Feb 22, 2007
Seamus Byrne says:
Good point! Paper is not an ideal medium to test user discovery of links. Howeve...Good point! Paper is not an ideal medium to test user discovery of links. However, I wouldn't dismiss the methodology as meaningless too quickly. The findings at the very least highlight areas that are worthy of further investigation.
In a separate user test we observed 18 users interacting with the app, but we were not focusing on discoverability of links at the tool level, but perhaps another round of testing is in order.
Feb 08, 2007
Colin Clark says:
This is great work, Kathy. I support your suggestions 15, and they echo a number...This is great work, Kathy. I support your suggestions 1-5, and they echo a number of the complaints I've had as well. #6, however, is an interesting problem which I have some concern about.
I don't like the notion of styling links as if they were buttons for the same reason Marc Brierley mentions. A link styled as a button with CSS will never look like the platform-specific buttons we're all familiar with. My sense is that if there are links in Sakai that really should be buttons, they should be changed to actually be buttons. I know, however, that this is much harder work than just changing the skin, but it may be better not to paper over the problem with CSS.
Feb 08, 2007
Juliette Mai says:
Thanks very much, Kathy, for putting this together. I fully support #1#5 althoug...Thanks very much, Kathy, for putting this together. I fully support #1-#5 although I suspect you will get mixed responses for #1. Visuals are always good so if you have time, a visual for #1 would be nice.
Feb 08, 2007
Judy Stern says:
I definitely agree with #1 and #2. #3 seems fine, though I don't feel super stro...I definitely agree with #1 and #2. #3 seems fine, though I don't feel super strongly about it. I can agree that less padding is better for visual chunking (#4). If #5 means "make the sites look like tabs", I can agree with that, but I don't know if there's a counter-argument that might convince me otherwise. And, I'm not sure I understand #6.
(Note: Kathey, as per your request, the text above is the text of email I sent yesterday. It doesn't reflect any changes you've made or comments others have added since then.)
Feb 12, 2007
Tim Archer says:
1 for items 1, 2 and 3. 1 for item 4 (but I would change your page to specifiy ...+1 for items 1, 2 and 3.
+1 for item 4 (but I would change your page to specifiy the new padding you want, and it should be a relative unit such as em)
+.5 (can I do that?
) for item 5. I see the need, I see the point, but I don't want to increase bloat too much or reduce that clean look you mentioned.
Feb 13, 2007
Gonzalo Silverio says:
Kathy 2 things would make a decision easier and more solid 1) research, primary...Kathy - 2 things would make a decision easier and more solid
1) research, primary and secondary (you mention some testing, where is it?) and less a matter of opinion.
2) doing the work - produce a skin with these changes and let everyone eyeball it
Feb 13, 2007
Clay Fenlason says:
Yes, I think it's worth providing actual CSS and images and serving it up somewh...Yes, I think it's worth providing actual CSS and images and serving it up somewhere for easy comparison. In fact, since we're in pre-QA, we can do this on qa1-us. Can you produce the CSS and images that would go into this, Kathy? I'd volunteer to apply them to a 2.4 tag and serve it up.
I'm not sure that research would elucidate each point - some of it depends on professional experience that I don't have as background, where it isn't merely commonsensical. But, again, if we have this on one of the QA servers we could more easily collect some end-user responses, with some easy contrasts.
Feb 13, 2007
Kathy Moore says:
Will do! I have all the css, will produce tab graphics in the default Sakai col...Will do!
I have all the css, will produce tab graphics in the default Sakai color.
Kathy
Feb 23, 2007
Kathy Moore says:
1) Much of the testing we're reviewing is linked from1) Much of the testing we're reviewing is linked from http://issues.sakaiproject.org/confluence/x/ZIs One of the pages linked there, http://issues.sakaiproject.org/confluence/x/-SM is itself a listing of studies and observations.
I'm also drawing on personal observation, comments from our head of User Services, and conversations with other UE people who also talk to users and user services staff.
2) Clay has posted a live skin with all the suggested changes at http://qa1-us.sakaiproject.org:8580/portal.
See claytest>Resources and claytest>Resources>Add for colored folder images, bordered table columns (less dramatic here than in screen shot #3 above, because the gif that adds emphasis shows up in a few odd places if you use it) and an h4 treatment that eliminates the default margin-bottom and padding-bottom and adds a fine rule above, to make the sectioning more readable.
Feb 20, 2007
Daphne Ogle says:
Sorry for chiming in so late. It sounds like there is quite a bit of agreement...Sorry for chiming in so late.
It sounds like there is quite a bit of agreement on most of these suggestions. I'd also like to add my +1 vote to 1, 2, 3 & 5. I conceptually agree with 4 but I'm not clear all the places this would affect. Sometimes a little extra white space can help the heading jump out and improve general scanability on the page. That said, we also have to worry about proximity so if the heading is so far away from the content meant to be within in that they don't look connected, that's no good either.
How do we make a final decision here? Should we add votes below each item?
Also, my design colleague at UCB, Seamus, just desinged a new skin for us and just finished some informal user testing. Some the of the results are quite relevant to this conversation...especially the links. I think he's going to post some information here.
Feb 23, 2007
Clay Fenlason says:
One comment on the rounded tab graphics, based on observing qa1us: it responds i...One comment on the rounded tab graphics, based on observing qa1-us: it responds in a fairly brittle way to text size changes (e.g. increased through the browser), since they enlarge the size of the tab rectangle that you're fitting the graphic to. Is there a way to achieve the intended effect without assuming default browser configurations?
Feb 27, 2007
Kathy Moore says:
I believe this is fixed in the latest build onI believe this is fixed in the latest build on http://qa1-us.sakaiproject.org:8580/portal.