This site is rarely updated. benbrophy.com is more up-to-date. - Ben
How flexible is too flexible?
After the Sakai conference in Austin, the wires are humming with mesages about how to move forward with an overhaul of the Sakai UI. This is great. Part of that discussion has revolved around the ideas that Jutta Teverianus and Anastasia Cheetham presented at "We don't all have to agree:" Flexible UI Design.
"Even if we go no deeper than simple style transformations, one implication of this approach is that we would transition from a style guide to a design guide accompanied by default style sheets or other styling mechanisms. Unlike the style guide the design guide would not make any recommendations regarding the specific presentation of the UI if it is possible to restyle that presentation characteristic. The design guide would require that the tools have a replaceable presentation. The recommendations regarding styling would in effect be communicated through the default styling mechanisms. This would also aid in achieving commitments to accessibility and internationalization."
I've been re-reading the Sakai style guide, and there is very little that relates to appearance or graphic design. The bulk of the style guide is describes common views and the elements used in those views.
An example from page 6.:
3 - Column Header (required)
A meaningful label for information contained in column that displays at the top of each column. Users can change the sort order of columns by clicking the header. When using column headers, indicate the following:
- Users can change the sort order
- The column that controls the current sort order (bold heading with triangle)
- How the column is sorted
There is a parenthetical reference to "bold heading with triangle" but otherwise this entry is about interaction. Anastasia pointed out at the Friday UI BOF that the user might prefer to sort tables using a drop down menu, and hence the style guide was being to strict.
You can go too far with user preferences. Few people will want to go so far as filling out a form that allows them to choose details like what mechanism they use to change their table sort order. Even having the option of making sort order headers italicized rather than bold is a bit obscure. Institutions may make this choice, but they can do that already in the CSS.
As far as user-driven CSS overrides go, I think it's an OK idea if kept fairly minimal. I am concerned that it could add complexity to the UI that most users will not need, and that it creates support difficulty (Help desk: "Click the my workspace link. That may be on the top left, top right, bottom left or bottom right of your screen depending how you set your preferences."). Many browsers offer this functionality already, so building into the application seems odd. If I prefer white text on a black screen won't I want all my websites to look like that, not just Sakai? A browser-based solution seems more suitable for those users. We just need to make sure Sakai's front end coding plays nicely with those browsers, and issue for the accessibility team I think.
We can't make the mistake of thinking that our users will design for us, we need to make choices about what works well based on research and experience.
A couple more questions:
Is this modular functionality? It is a plugin for Sakai that people can take or leave, or is it hardwired in? If we decide this level of configuration is confusing our users, can we turn it off easily?
How much additional work does this approach create for new tool developers. It is already seen as being a fairly complex task to create or adapt a web tool to work with Sakai. Does this make it harder or easier? If was adapting something like JForums to work in Sakai, what would it take to make the presentation layer this flexible?
Tags: Sakai ui sakaiaustin05