Wikis, Revisited

More than a year ago, I put the final touch on a report called Wikis in Higher Education, an assignment I worked on for some time from when I started working for the University of Delaware and May 2008. Since the release of the report, there has been some success stories using the wiki tool in Sakai at UD. The latest success story comes from Persephone Braham, an Assistant Professor in the Foreign Languages and Literatures Department.

Collaborative Wiki Project for Latin American Cultures - Persephone Braham from Mathieu Plourde on Vimeo.

But at the pace that the web technologies are evolving nowadays, the Sakai Wiki tool is becoming weaker every day, as wiki-like behaviors are becoming a part of other web 2.0 technologies. Not that it's a bad thing, but having access to a protected, institutionally-supported wiki space has undeniable value in higher education.

Below are some of the missing features that would need to be included in Sakai in order to make its wiki tool competitive again. Some of these features will become available in Sakai in the near future, but I found relevant to list them here anyway.

1. Rich Text Editor

This feature has been asked for years, yet it is not implemented. Attempts have been made to integrate the FCK Editor with the wiki tool, but results have been dissapointing. The biggest issue is related to the fact that there are too many features in the FCK Editor that are not supported in the wiki markup language, like resizing a picture or formatting a table. Other Web 2.0 wiki products like Wikispaces have been using a rich text environment from the get-go, and even rarely show the wiki markup language to the user.

2. Embedding

Users create content outside of Sakai, and they would like to be able to embed objects (videos, sounds, pictures, etc.) inside the page as they create content. Again, this feature is available on all blog engines and on most wiki engines as well.

3. Table Formating

The default "first line is a header with a yellow background" doesn't cut it anymore. Sometimes, the content needs to be presented differently, and users have been complaining about this lack of flexibility. Most wiki engines support a way to turn a cell into a table header. Confluence does it with a double pipe ( || ), Wikidot with a tilde after a pipe ( |~ ).

4. Page and Comment Deletion

It is a little ridiculous to not be able to delete a page or a comment. The workaround is definitely weird. The fact that a page cannot be deleted does not promote tidyness, a basic wiki behavior that should be engrained in user's minds.

5. Group Awareness

I have been asked over and over again if wiki spaces could be created for specific groups in Sakai. Faculty want to assign spaces and change permissions to only allow certain subsets of users access to sections or pages to read or edit.

6. Listing of User Edits

Although highly inefective and time consuming (and personally discouraged as often as possible by yours truly), tracking user edits is a feature that faculty members are requesting. The idea would be to be able to seach for a user and see a list of all the edits that user has done in a specific site. Some faculty members believe that exposing that data can help them assign a participation grade.

7. Editing In Place

This one is a little far-fetched, but it is a behavior we see more and more often online. The idea that whenever a users hovers an editable part of the text and clicks it to start editing is definitely a part of the user experience expectations.

An Emerging Dilemma in the Sakai Community

Now that I have exposed some of the feature requests I'd like to see in the Sakai wiki, the problem comes back to this: How much effort is the community willing to demonstrate in fixing Sakai 2.x vs. developing Sakai 3? Sakai 2.x. is going to be around for at least another year before a stable release of Sakai 3 is available. Are we willing to put our current LMS on ice for a whole year, or are we going to make it work better right now?

I am not sure what the answer to this question is, but I would sure like to hear your opinion on this issue.

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?