The 3 Ws of Sakai 3

I have now been involved with the Sakai community for over a year. In retrospect, I feel like a lot of good things are about to emerge from the work of this one-of-a-kind crowd. The latest and most active initiative, Sakai 3, is, in my opinion, very promising.

This blog post is somewhat a summary of my understanding of what Sakai 3 is all about, from a user point of view. I hope it can become a starting point for current community members who might still see Sakai 3 as a blurry long term vision, and maybe even draw more people’s attention to Sakai as a valid alternative to commercial learning management systems like Blackboard.

This post is based on my experience at the Authoring Summit and with the Content Authoring Initiative, my implication with the Teaching and Learning Group of the Sakai community, my understanding of the discussions happening on the different mailing lists, Nathan Pearson’s mockups for the Sakai UX initiative, the awesome job done by the Cambridge folks on the 3akai pilot site, and Michael’s excellent document about the vision behind the Sakai 3 initiative.

Looking at what Sakai 3 will be all about, here are some of the most relevant features of this new approach to content authoring (the ability to create web content online).

1. Sakai 3 is Wizardly

To become foolproof, Sakai will become better at offering the most direct path to content creation through wizards. These online sidekicks will provide guidance during the content creation process to help users make the right decisions, or guide them to the most common ones. Even though most of the design process will be wizard-driven, advanced users will still have the required flexibility to bend Sakai to their will through various options.

2. Sakai 3 is Widgety

The addition of a new page type (dashboard) will create a new way of looking at content: through widgets. These widgets will give a glimpse at all the dynamic content available in a site or outside Sakai on the open web. In addition to this, Sakai will break out of its tool silos to help users link directly to what has been referred to as “entities”, which are linkable chunks of information or activities, like a quiz, a forum post, an assignment, etc. Widgets will be able to provide a summary of an entity, a digest of the activity in an entity, or event a fully working entity embedded in a web page (like a chat room embedded under an article to be discussed, for instance). A list of entities is available here.

3. Sakai 3 is Wiki-like

Just like in a wiki, all edits will be archived, preserving the history of any authored page. It will use a powerful WYSIWYG editor to avoid the tedious learning of a custom wiki markup language. Document authoring will have a clear word processing look and feel, but will add a very strong collaboration opportunity that is not readily available in a client-side word processor. Page creation and linking will also be automated to make the site creation as seamless and transparent as possible.

---

I have presented Sakai 3 to our University of Delaware’s Learning Management System Committee in January. Below are the slides I used.

Beyond Sakai 2.6

View more presentations or upload your own. (tags: opensource lms)

Most faculty members were excited about the vision of Sakai 3. They felt like they could really use a flexible yet simple environment to create their web content.

You are more than welcome to use anything I have put up here, remix it, discuss it, to make it better. Does this vision of Sakai reflect what your institution and your users are looking for? What’s missing?

The Read/Write Web and the Everlasting Quest for Usability

Since last November, I have been heavily involved with wikis. To support our Sakai implementation at University of Delaware, I wrote a full report on Wikis in Higher Education, since it is a new tool to most professors at UD, and that we believed that it could provide some major instructional benefits. I have also been involved with the Teaching and Learning group of the Sakai community, using Confluence every week to support our confence calls.

A lot of people, when exposed for the very first time to a wiki, have the same reaction. They kind of question why they are so ugly, or why they can't find anything... I can't blame them. Most wikis are not that good looking, and most of them are a total mess in terms of information architecture.

When I was thinking of a reason why wikis are the way they are, something struck me: web usability and good design were hard to enforce with web 1.0, when only a few Internet-savvy people had access to push pages to the world. It was kind of a lost cause then, but now that everyone can publish to the Internet, it's even worse.

The biggest difference between wikis and other tools is the fact that wikis are unstructured by nature. You almost always start with a blank page, and you must create the content, the format, and the navigational patterns at the same time. Not an easy task for a web designer, so imagine for a common mortal! (Not that I am assuming that web designers are superior or anything, of course... They just spent more time on a computer, and less time in the great outdoors.) Blogs and widgets are highly structured, and you can change their look and feel afterwards, but not wikis.

Which is why I think it is time to educate wiki users to basic concepts of web usability.

• Define a navigational structure: How will users navigate between pages in your site?
• Define information architecture: How will your content will be organized, and do you need to explain it to your users (if you have to, it's usually a case of poor design)?
• Keep your site shallow: Do not create a site that has sub-sub-sub-sub-sub-pages. It becomes a nightmare to navigate, and it is usually a sign that the information is not structured in a comprehensive way.
• Divide your information in chunks: Use headings to serve as visual dividers, so that the information is visually scannable.
• Use meaningful link aliases: Click Here! doesn't mean anything. Links will stand out by themselves because they are usually blue and underlined, you don't always have to isolate them.

I have more tips and tricks available in my report and on its page. I just finished a document explaining how to gain full advantage of the wiki tool in Sakai. Have a look at these resources, and give me your comments.

Open Question:

Do you have tricks, methods, references, or links to promote usability to non-designers, instructors, or students, wiki-related or not?