This is a working document, so expect more detail to be added as needed. Please DO NOT ask me to make changes to it – just make the change yourself. If necessary, I'll revert to a previous version.
If you haven't looked at the 3akai demo site, please review it now. The URL is:
You can create an account and login on your own.
In early 2008 I embarked on a project aimed at improving the user's experience with the 2.x Sakai platform. While the project was well received, a new product vision that dwarfs the limited 2.x LMS model has taken center stage in our community. This new vision not only promises LMS capabilities, but seeks to enhance the product experience with rich and intuitive web page creation features, thoughtfully designed work-flows across different modalities and tasks within the system, easy and rewarding connectivity with other Sakai users, and better control and production of documents, materials, and other academic content.
No doubt this is a tall order! But the embryonic groundwork for these enhancements has already been laid!
What's needed now is a quick, solid, tactical UX strike. We'll have very little time for execution, and even less time for planning (although there will be planning). This project is ideal for people who can self-motivate, roll-up their sleeves, push their ideas, work collaboratively as a team and not get bogged down by lack of formal process.
This project will have two basic teams:
1. UX designers who will produce wire-frames, visual design treatments, and supporting documentation.
2. Developers who will implement the designs, offer suggestions, point out constraints, and clean up functional as well as aesthetic bugs.
While much of the design work remains to be done, we already have a good starting point with the current demo site. We'll evaluate the demo site, along with any relevant new ideas, and work together as a team to arrive at final design solution that is timely, easy to use, modern, and meets the needs of the project details below.
Note: These are not in any particular order. In fact, the bottom of the list is probably more critical than the top.
1. Portal Level
1.1. Review/design "My Profile" area & related parts
Nico has added some social networking functionality at the footer of the demo site. We should review this functionality and consider re-designing it.
1.2. Review/clean-up headers, meta-heater, and general portal interactions
Depending on some of the changes that happen in the UX at the Site and Page levels, we may want to reconfigure the layout and general patterns of how users find, join, and generally navigate sites and other areas of Sakai.
1.3. Redefine the gateway page to reflect a more "open community" metaphor
The site model may change to be more open and inviting by default, without a requirement to "join" a site before having some access to it. If we achieve that enhancement at the site level, it would help if we also modify the portal gateway to communicate this openness.
2. Site Level
2.1. Clean up site and page management UI controls
In addition to the standard "Site Settings" options, Nico has introduced various page editing/management controls at the site level (i.e. Create Page, Edit Page, etc.). The UI for how these controls are presented needs refinement.
2.2. Design screens and work-flows for site and page based operations
The above mentioned UI controls call up various screens, each with a different purpose and a varying degree of depth/complexity. We will need to review what's there and clean it up if necessary, as well complete any missing pieces.
2.3. Adopt a different sidebar model
A more flexible sidebar design is needed. I have worked on a few ideas that we can use as a starting point. Ultimately, the sidebar will need to support navigation of Pages within Sites, but will also have a management (add/edit/delete) aspect to it – so expect more behind-the-scenes screens to support the sidebar functionality.
3. Page Level
3.1. Redesign TinyMCE editor to look visually more appealing
When all the controls in TinyMCE are turned on it's frankly overkill. We'll want to decide what controls to present by default. We'll also want to skin TinyMCE to look more consistent with any visual design changes that take place in Sakai.
3.2. Incorporate controls into page edit mode for adding gadgets/media/etc.
We'll need to add controls somewhere on or near TinyMCE for adding various functional bits into the page. This is really the starting point of the most crucial part of this project.
3.3. Design screens and work-flows for adding/editing/deleting gadgets/media/etc.
In addition to the controls mentioned above, we'll need screens for adding – and in some cases, inline editing – of the various functional bits that a user might add to a page.
To facilitate this work, we'll need to identify two or three entities that we'll want to get into this release. These will give the design team a contextual starting point from which to work form.
3.4. Design screens and work-flows for globally modifying permissions with gadgets/media/etc.
Once a functional bit is added to the page, it will need to be managed in someway. In many cases, the object itself will have inline editable features, but in some case there will need to be an aggregate view of all such functional bits so the user can manage them in one central location rather than hunting them down from page-to-page.
4. Other Odds & Ends
4.1. Review original UX Improvement screens and decide if any need enhancement, change, or abandonment.
Project Tasks & Timeline
TBD. However, the project timeline will work backwards from the assumption of a early to mid April code-freeze!