What's Wrong with the Sakai User Interface

Like many, I have been eagerly awaiting the public unveiling of Sakai, the Open Source course management system being created by an alliance of MIT, IU, University of Michigan, Stanford, and uPortal. At last the long wait is over; the first public release is available, and with it a demo portal. So I went in and kicked the tires. The first place I like to go when checking out a CMS is the discussion boards, since (a) they are typically one of the most critical and heavily used components in the system, and (b) they are often very poorly designed. Would Sakai do it right?

Sadly, no.Let’s start with conversation flow. In a live conversation, you hear the give and take of all the responses without having to do anything. The conversation…well…flows. In contrast, on Sakai’s (and many other) discussion boards, you have to click to read each message in a thread. Since distance is measured in clicks on the Internet, that’s the functional equivalent of having to run to the next room to hear what the next person has to say. Sakai’s interface favors always showing the entire list of comments made in all conversations over giving a scrolling, one-page narrative of one particular conversation.

Why do they (and many others) arrive at this design decision? It’s the necessary consequence of a deeper design decision which is also (in my opinion) an oft-repeated mistake. Sakai’s underlying model is the classic “threaded” discussion. The word “thread” seems to evoke the poetry and complexity of human conversation, doesn’t it? It always makes me think of Queequaig, the warp, and the weft. Unfortunately, “thread” is a misnomer. The underlying data model for a threaded discussion board is a tree. Picture a grammar diagram of a sentence and you have about the right image. You end up with lots of little unconnected feet at the bottom. Threads intertwine; trees branch. Conversation branches in threaded interfaces usually do not intertwine; they fragment. They become separate conversations. The Catch 22 here is that the discussion board interface forces fragmentation of conversation, which in turn makes the best interface for following the conversation one in which you can always see all the branches.

This problem is compounded by the fact that most threaded discussion boards (including Sakai’s) have a “reply” link on every post. Now, in non-virtual group conversation, we generally reply to the conversation. While we are perhaps directly responding to what the last person said, we are doing so in the context of what everyone had said so far. But in the threaded discussion board, clicking on “reply” means reply to that post. It means create a branch. In order to keep from branching and instead, in effect, reply to the entire conversation, you have to reply to the parent post. In a long conversation, this usually means scrolling back to the top of the page and clicking on “reply” for the very first post. In Sakai’s case it’s arguably worse, because you have to first click on the link to the parent post and then reply to it. Can you say “counter-intuitive,” boys and girls?

Now, to their credit, the Sakai team took several steps to mitigate the problems. First, they added a check box to the first post, allowing the poster to effectively turn off branching. I hope that they also allowed the discussion board to be configured to turn off all branching by default (though I couldn’t get to the admin options in the demo, so I couldn’t check). Second, they added a button on the main interface that allows the user to see all the posts in one thread. But these changes don’t solve the fundamental fragmentation problem that their interface creates. You can’t reply to the conversation from the unified view of the thread, which means that if, for example, you want to look at several posts in the conversation and respond to them as you are writing, you have to click back and forth between views, remembering exactly which posts you want to look at and clicking on their appropriate subject lines as you compose. And although it is possible to turn off branching, the fact still remains that the branching interface, when on, tends to encourage fragmentation of the conversation.

In my book, each post should have two buttons. One, the obvious default, should be something like “reply to conversation.” The other, the obvious non-default, would be something like “start a tangent.” Tangents do happen in real conversation and the interface should allow that. But starting a tangent shouldn’t be the easiest and most obvious way to reply, and the discussion board shouldn’t be primarily structured to make it easy to view all tangents. It should be structured to easily view the entire main conversation, which means a flat interface in which users can scroll through an entire conversation in one page. A tangent should start a new discussion page, also flat, that pulls in the parent post as the first post in the new conversation.