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.
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.
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.