Friday, December 7, 2012

Usability problem of the day (Moodle, part 1 of n)

In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

Moodle is... a Free [sic] web application that educators can use to create effective online learning sites.
I'm ambivalent about Moodle, the system my university has adopted for course management. It's awful beyond reason, but if I'm ever at a loss for a usability problem to show my students in class, I just do something in Moodle and take screen shots as I go.

Say that I'm creating a new Moodle space for a course, at the start of the semester. I enter information about how the course page should look and then click a button labeled "Create My Moodle Space". The message box shown at the top of this post appears. The text reads,
Are you sure you want to leave this page? 
Are you sure you want to navigate away from this page? 
If you have not clicked Create My Moodle Space, your changes will not be saved. 
Click OK to leave this page, or Cancel to stay on this page.
Moodle apparently wants me to think very hard about whether I should leave this page. But would a competent software person design a system that poses the same question twice in a row? Doubtful. The message may be built from information from different, independent modules (I'm guessing here), and the resulting text is not checked for redundancy.

The lack of internal communication continues. The third line tells me what will happen if I have not clicked on a specific button that I have just clicked on, less than a second earlier. Why wouldn't this information be available when the message box is created? The system is trying to ensure that I don't make a mistake, even a mistake that's not possible to make. Usability suffers. By analogy, imagine asking a work colleague to run an errand. He answers, "If no one runs that errand, bad things will happen." You say, "I know! Why do you think I'm asking you to do it?" Moodle is behaving something like that.

The fourth line is just confusing. I've told the system to create my Moodle space, but the message box ignores that context, assuming that I will translate "leave this page" to mean "Create My Moodle Space". This turns out to be the correct translation, but it's not obvious. Back to your annoying colleague: Instead of confirming that he will run the errand he says, "Do you still want me here? Yes or no?" You hope that when you tell him to leave he'll run the errand, but it's hard to be sure.

Moodle is shot through with confusing, irritating flaws and inefficiencies like this. The online documentation is often of little help. Our local technical support team can explain things, but they're working within the confines of the system. For example, last year, when teaching an HCI class, I organized the students into teams. I wanted to monitor their work on their course projects, so I had the thought that each team could maintain their own wiki, adding new material as they went. The Moodle documentation suggested a procedure that involved what seemed to be superfluous work, so I contacted tech support to see if I was missing a simpler solution.
Me: “My understanding is that I need to put students in groups, then groups in groupings, and then associate a grouping with a wiki. Is that the least cumbersome way to give different student groups their own wikis?” 
Tech support: “That is correct. When you assign groups to a grouping, only students in the groups in that grouping can see each others’ work in the wiki. If you want all students to see each others’ work, you don’t need to add the groups to the groupings.”
Does that make sense to you? A year later, it sounds like Dr. Seuss to me.

My students can learn a few lessons from examples like these.

Moodle is terrible. It turns out that most of my students already have this opinion, based on their own experience. (The I HATE MOODLE Facebook page has 6,056 "likes", the I love Moodle page 16.)

There's no silver bullet in building usable software. Moodle is a free system, in the sense that the software doesn't cost anything, and also in the sense that you're free to do whatever you like with it. Richard Stallman famously characterized one type of sofware as "'free' as in 'free speech', not as in 'free beer'." Free speech can have costs; free software just as much. To adapt a free software system to my own needs, I have to understand what my needs are. And I need to figure out what to do to match the software to my needs, and then to actually do it. By analogy, imagine that you're talking with a company that's in business to meet transportation needs. Unless you've analyzed your needs from the start, you may end up with a fleet of bicycles when you really wanted a couple of large buses, or an airport when you really needed a subway station. There's a lot of work left to be done.


  1. G'day Robert,

    Came across your post while doing some development around a Moodle activity module. The "are you sure you want to leave" warning was causing me problems. As I moved on and learnt more about the origins of this warning, I think it says some more about the complexity of developing a system like Moodle. Thought I'd share what I found.

    The origins of this warning are explained in this tracker entry (used by the Moodle developer community). In short, there were problems with users of Moodle navigating away from changed forms before saving. I can imagine the howls of frustration these mistakes will have generated from the people making these mistakes. Some of those howls will have been directed at the local Moodle support folk etc. Which brings up the good idea of providing a mechanism to prevent this from happening.

    The trouble is that the diversity of the modules, people and purposes involved with Moodle is always going to lead to difficulties for any single solution. Of which this tracker issue is symptomatic. There are times when you want to turn this off (like I did).


    1. Thanks for the perspective, David. And the pointers to the tracking pages; they help me better understand the challenges that large open source projects like Moodle face, and the specific usability problems I tend to run into. This comment, for example, is representative:

      I hadn't thought about making this generic to every mform, but it actually turned out to be the easiest way to implement.

      I can see that the functionality is important; it just needs to be tailored to the context, for end users.

  2. Forget about it, it’s just not worth the trouble. Its only a waste of time I think… we got better things to do guys.