This site is rarely updated. benbrophy.com is more up-to-date. - Ben
User controlled design
This note is reposted from an email I sent to the Sakai UI discussion group
Someone at MIT asked me to provide more information about what complications I see with the plan "to provide maximum flexibility for institutions who were keen to implement their own look & feel on the interface." This was a follow up to the recent "Do you support moving toward a flexible or adaptable UI approach in Sakai?" thread on the Sakai design mailing lists.
Unless I'm misunderstanding the plan from Toronto is not "to provide maximum flexibility for institutions who were keen to implement their own look & feel on the interface." It is to provide maximum flexibility for INDIVIDUAL USERS to implement their own look & feel on the interface.
I think everyone wants to make the UI flexible for institutions, there's no debate there.
Here are some issues with asking users to set their own interface preferences:
Help desk support
If every users' interface is different, it is much harder for the help desk staff to tell user how to do something, because they have no way of knowing what the user is seeing. Even if they if can see what the user is seeing it means they help desk staff need to know all of the possible configurations of any given tool.
Added complexity to the UI
A lot of UI design is centered around understanding user goals and making it easy to accomplish those goals with as little interference as possible. Adding additional forms that let users tweak the interface is more interference.
Easy to make bad choices
We also don't want to make it easy for people to shoot themselves in the foot. People messing around with the settings might think setting their link style to pink italics is fun for now, but it can cause them to not see links they need to work with in the future. People really do make some bad choices in this area, you can be a smart and talented person and not know a thing about UI design.
Not a great track record
Someone on the list pointed out (I lost the email unfortunately) that many portals have tried this, and found that users don't tend to be all that interested in personalizing the UI. So a lot of effort towards this might be misdirected when there are so many features more important to teaching and learning.
Let browsers do it
Many browsers have the power to overrule website CSS styles. So users who are keenly interested always having white text on a black background can use this method already - we just need to make sure Sakai uses web standards behaves well with supported browsers.
It may break the goal of loosely connected modular tools
It may well make tool development in Sakai closely tied to a particular technology (JSF or RSF or JSTL or whatever). This will make much harder to bring tools that were not explicitly designed as a part of Sakai into Sakai. By forcing all developers to use a set of shared JSF tags you've closed Sakai to most 3rd party application, and all applications written in PHP, Ruby, etc. New Sakai developers will have to learn an obscure method of coding in order to contribute a Sakai tool. This could really impact the future prospects for Sakai.
The accessibility argument
The strongest argument for this approach is that is supports accessibility, but there may be better ways to make accessibility work.
- In addition browser feature, operating systems now have features for magnifying screens or forcing high contrast.
- Make this explicitly a mater of accessibility by offering simple presets in the user preferences that do things like increase font size or increase contrast.
- Best of all do rigorous accessibility testing to ensure that the UI works for all users right out of the box.
Sorry for the long note! I was afraid I hadn't written clearly before, and I wanted to break it down a little. I also want to be clear that the work demoed by Toronto is really strong, especially in the area of working with multimedia in the LMS. I think there is an important place for it in the content authoring space.