Negotiating User Needs in an Open Source Community

UI design and PHP, JS front-end development: UI for creating and editing quizzes and exams, etc.

I championed teacher needs, discoveries originating from University of Tampere. I engaged the Moodle.org community to reconsider their UX priorities. After about a year of negotiation, I got a new, dramatically more novice friendly design accepted and implemented.

Contributed source available at GitHub: initial commit.

(… and all commits by username ‘pilpi’, which was me then.1)

This is what the UI looked like before the project. It broke pretty much every usability heuristic in the book.

I created a bunch of prototype at various stages of the process. Both the prototypes and the eventual first implementation were usability tested, which is documented in my master’s thesis on this work.

Moodle statistics state 531 million quiz questions created. Even taking into account older versions, it seems safe to say this design has affected millions of individuals.

ACM SIGCHI Finland awarded an honorary mention for the thesis.

Story with pictures

The fun thing is that the screenshot above is just the tip of the iceberg. The community work required to reach that simplicity visible in the third screenshot was very significant, taking several years. How is it possible the challenge was that great? After all, the complexity level of the initial mockups is roughly the same as that of the resulting UI?

The difficulty of delivering this was largely due to change resistance. The conceptual model of the set of Moodle modules involved is complex. It is what the developers thought was necessary, having added features as time went by. As opposed to what I had thought at first, the issues were not on the surface level  – UI element misuse – only.

The change resistance in the community was strong, even after getting the initial project cleared for implementation. I still had to accommodate the old conceptual model to a degree. So a lot of the old complexity had to be kept at first.

Diagram attempting to explain an aspect of the proposed change to the community

It was only after I had actually left the project that I found out they had gone through with the entire simplification work.

Overview

On this adventure I felt like a settler in a open source community that had no apparent prior exposure to systematic learning of user needs.

During my time in the community, I initiated a Human Interface Guidelines community process and did general usability consulting in various areas. I also advocated usability testing also for a Moodle development process standard.

The meritocratic nature of open source projects gives developers with no particular UX skills a lot of voice. We had to simplify gradually; build a more complex UI first to accommodate change resistance.

  1. If you’re really curious, use this github search link and browse to 2008-11-20 and forward, until approx the end of 2009 and perhaps a little bit over to 2010. – I couldn’t really get github search to cooperate.

    Btw, the initial commit is a big ball of code since there was a transition from svn to git going on at the time, and bringing in the individual commits seemed like too much to manage vis-a-vis the perceived benefits.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment moderation is enabled. Your comment may take some time to appear.