After the last iMoot session I had, I was chatting with Silvia Calvet about usability and its social nature.1
During the iMoot conference I also got a couple of precious chances to hear about different community members’ usability efforts within their organisations. Turns out there are a bunch of people already doing usability related to Moodle, mostly inside their organizations. Even more people are interested, but the environment to discuss usability in the context of Moodle does not exist.
We need an environment where community members can make their usability efforts visible to the rest of the community:
- A place where people are encouraged to brag about what they have done for usability in their organisation, and to share what has been learned (usability test tasks, results, …).
- A site that could propose you directions to take with usability: give instructions interactively for usability testing, for instance.
- A corner in the community to chat in about usability, where you could share your frustrations with Moodle, and with doing usability work, and with usability issues in general.
Another aspect of this effort would be to visualize actual concrete usability data about Moodle.
- Have a hierarchy on the site for the high level to low level goals, and for red routes of the Moodle UI (of course, these need to be defined first).
- Allow people to link user interfaces (cvs/git), tracker issues and usability tests (containing test tasks and results) into these goals, although keeping the user goals as the starting point for everything.
The slogan? How about… We are all about the goals of the learners!
The magic I want to make happen: make usability visible socially since it is, at its foundation, a phenomenon of social artifacts. Engineers are creating artifacts to users, when they would be better off with other kinds of artifacts. If we can make this disrepancy obvious in the community’s social sphere, there would perhaps no longer be a need to try to convince software engineers of the concrete need for the work. As it is currently, it seems many perceive usability as something too abstract and distant for them to actually do something about it.
Before any of this though, I believe the first milestone is to do usability testing to determine the current level of usability. This is to set measurable goals for Moodle usability, and to prioritize the things a given part of Moodle is primarily intended for. The fun thing about the above vision is that it is easy to start small: first start filling in data for one activity module while it is usability tested, and then build on the vision I am proposing here, as we go. Even if we end up just creating a site for documenting Moodle’s current level of usability (as a side effect of doing usability testing), it is still worth it.
Twitter Tweets about Moodle on Twitter as of February 13, 2010 | Moodle Magazine 10:00 pm on February 13, 2010 Permalink
[…] · Reply · View pilpi: Social usability in Moodle: The user’s experience http://www.pilpi.net/software/moodle/2010/02/13/social-usability/ 2010-02-13 18:12:46 · Reply · View nathancobb: New blog post – When […]
silvia calvet 12:26 pm on February 14, 2010 Permalink
mmmm. I like the idea of having a place where we could share our usability experiences with Moodle with other members of the community, with the double benefit of sharing possible solutions, and at the same time, enlightening the developers community with the kind of problems we have.
Where we could start?
Olli 9:13 pm on February 14, 2010 Permalink
As said, usability testing seems the first thing to get started with – it is the most practical and immediately useful thing. I tried to make the point in the iMoot presentation that there might be a clear learning route for the community from usability testing to approaching the higher level *goals* of users too: We start by listing the usability testing tasks (reported by anybody doing usability testing anywhere) for each UI, then prioritizing them, and then hopefully, eventually starting to see links to actual user goals.
But first we have to have quite a bit of usability testing done for Moodle, so that people seeing the results of that testing within the community might create motion. A primary goal should be not only to test but to think of ways for people to empathize with different kinds of users. I’m thinking the easiest way to do this would perhaps be short videos with lots of different users’ frustrations during a test, each video illustrating a given issue on a specific UI in an obvious manner.
Tim Hunt 9:26 pm on February 15, 2010 Permalink
moodle.org provides a good set of tools (forums + wiki + tracker) which let people have vibrant and useful discussions about other aspects of Moodle. And there as been a usability forum http://moodle.org/mod/forum/view.php?id=7229 for quite some time. Why does that not get used by the usability people?
Olli 8:47 pm on April 28, 2010 Permalink
You know the saying? When all you have is a hammer, every problem looks like a nail. Usability work is different from software engineering: code or feature centric tools such as the tracker are designed to deal with code. On the other hand, forums are for ongoing discussion: the only tool that reflects a permanent, evolving element is CVS/git. For active discussion and documentation about what user goals the functionality is supposed to serve, there is nothing systematic.
When user goals are made into visible entities of a tool used in development, and efforts directed into keeping that knowledge about users up to date, only then can more and more of the community become aware of the fact that user goals are in fact a factor in what Moodle is made into. Only then can they read the user goals listed for, say, Quiz, and realize it if their goals are not represented or if they have somewhat varying goals – and inform the community. Only then can we see how distant what we are doing is from what different users need, and only then can we do something about it.
If this is not done, you need usability people like me going explicitly to users who don’t use Moodle (or who are not keen enough to participate in the community), and advocating for their needs. Just like I did with the Quiz project. The problem is, there are never going to be enough usability people in a community that does not recognize such issues, but where usability people have to fight to get listened.
Making sure we understand the goals of users and seeing that those goals correspond with our user experience is a factor that should be considered with the development of Moodle, just like pedagogical considerations and software security and robustness.
At the moment that is happening almost not at all. User goals are not explicitly discussed in the community nor considered as entities that should be perfected (like pedagogical considerations or architectural structure that leads in software properties such as flexibility or modularity) when creating Moodle. This results in it being hard to actually design user interfaces at all, since what the user experience is made of, does not exist to most developers or other community members.
So even if I or any other usability professional were absent, what Moodle as a community needs to do is to mirror user goals against the UI.
Actually, to get started, standard tools such as Moodle docs or the database module might be explored. Only when we get to a point where entities such as user goals (or test tasks, see below) need to be versioned, and given versions need to be linked to other entities (such as a version of a UI that a given set of goals corresponds to), I start seeing a need for a dedicated tool.
It seems to me that user goals are still perhaps a bit abstract, but a joint effort the community could do together is gathering usability testing tasks. As you saw in my iMoot presentation, usability test tasks can be prioritized (by vote) and to a degree, I think that can tell us something about which goals are the most important for a given UI. Here we might, for example, have a low-fidelity indicator of what should be emphasized in UI design and what could be made less visible (say, with progressive disclosure).