Summary of the Summer of Code
For me, this summer has been full of small and bigger openings. I have gotten overwhelmed, figured out why, and organized my thoughts about Moodle development and usability time and time again. I have found a lot of new, relevant questions and understand much more about the challenge that is Moodle usability, and more broadly, Moodle user experience.
The main outcome of the project, Moodle User Interface Guidelines, got off to a good start, and I believe it will serve as a useful reference in the development of current and future user interfaces.
At the end of the project, I did some brief usability testing (contrary to what I believed in the previous post) which shed light on the Login/Forgotten password form and on the File picker for the rich text editor (see below). I will write more about these very guerilla-style usability tests later. The code produced is in the linked tracker items of MDL-19586.
I have interacted with the community a lot in the forums, on Jabber channels and in the tracker (see below). Still, the actual guidelines never got as much attention from the community as I planned, so this work continues. Time did not seem ripe for many of the guidelines I planned for. And honestly, I did not spend as much time writing some guidelines I perhaps could have. In the end, I decided to concentrate on what was important at a given time. Sometimes it was a specific UI that needed a gentle touch, or an UI element, and sometimes broader issues were discussed.
Tim Hunt, who has acted as my mentor just like last summer, has been available to comment on anything I needed to discuss. This summer he has given me some great advice especially about interacting with the community. Some of it seemed, ehm, too good since it made me feel pretty humble.
Opening my eyes
The issue seemed to be that there were not many elements in Moodle that could directly be made into guidelines. In the last post, I outlined various ways that a guideline can get born. With Moodle at the moment, way too many of those were just things there was a need with but nothing tangible existed. As there was nothing implemented that could be written about, often the first step was to talk about a given subject in the forum, to get people to think about whether this thing X, that could later become a real guideline, should be taken into account (keeping user data safe, wizards).
On the other hand, I also felt the profile for usability in Moodle needed to improve. So I offered design services to some current development efforts taking place (course backup, help tooltips, paint tool, file picker/uploader for TinyMCE). My hope was that I could show developers what kind of a contribution a usability practitioner could give into the software development, and make developers start to expect someone to be available for the kinds of questions UI/UX design raises.
With the current understanding of the status of Moodle’s usability and how things are developed in the community, the next logical step seems to be comprehensive usability testing of the overall UI model of Moodle. Only after this we will understand just what exactly is in need of the most work. This requires first determining what use each part of Moodle is intended for – some sort of use cases and usage scenarios – in order to create test tasks. I know this sort of understanding exists in the community: the applications are created with the users’ needs in mind, to a degree.
But the knowledge needs to be extracted and documented. If I have to squeeze it out of certain Mr. Dougiamas’ head… well, just kidding. We need to listen to everybody in the community, but we (I?) also need to understand better just where the understanding about users comes from, and how it is being used. It seems to me that at the moment, much of this is never explicitly discussed in the community.
Based on testing and user research, creating a strong UI style/language for Moodle will later also help further develop the UI guidelines, since there will then be something substantial to document.
I have also gathered a list of Major Usability Issues in Moodle that can be addressed in future projects. This is just a start, but it seems to me that bigger usability challenges need to be tracked, documented and discussed, than what can be done in tracker tickets about individual issues. I am not sure about the tracker’s suitability for this.
Efforts initiated
- I created an UI guideline about keeping user data safe and it generated a lot of discussion. Also, I asked about the teachers’ experiences related to this.
- Usability testing for the File picker/uploader for the rich text editor TinyMCE (blog posting)
- Wizard – in addition to the UI guideline, designed a mockup for the course backup activity to give an example about what wizards should look like
- Help tooltips: I originally published a javascript prototype for these, but did not publicize them more. A month later Nicolas Connault had implemented something similar (as part of MDL-19756), so I gave him feedback about his work: MDL-20000 display bug, MDL-20095 tooltip delay. There is a bit of a conflict between the benefits of these two implementations of quick help, so hopefully the true gains from each will be considered (well, discussed to start with) and a balance found.
- Designed and implemented an experimental prototype for the course editing mode UI for the course front page
- Accessibility: Changing the advanced form items symbol
The efforts I participated in
- Forgotten password form – designed a prototype to fix issues, implemented and then usability tested it against the old UI
- Also implemented a patch to unclutter the login form, while making it more consistent with most other web applications. Usability testing seems to hint preliminarily that users find the “Forgotten password” screen more easily after this seemingly trivial change.
- Took a shot at wondering about the Roles system, came up with an approach to develop the UI (the proposition in itself needs work to make easier to approach), and suggested better documentation for it which led to a discussion about the conceptual system of the Roles system
- Moodle paint tool (another Google Summer of Code project) – encouraged and Mihai Şucan to do user research and gave advice, commented the usability of various elements and created UI mockups. Unfortunately Mihai only had resources to do some more or less minor fixes, considering the time limits of his project.
- This discussion also led to wondering about the usability of the three row toolbar of the new TinyMCE rich text editor, and I created a patch to fix it. - further research required before launch of Moodle 2.0.
- Font display accessibility tool – participated in the discussion, gave design suggestions
Discussions we had
Forum threads I found valuable to Moodle usability:
- About Moodle usability in general:
- “Why open source software usability tends to suck” – how do we work around this? – this one, I think, got the deepest – about working with users to understand their needs, and finding an interface to share work between usability specialists and software engineers in an open source project
- The persistence of editing modality, which turned into a discussion about the Usability workflow in open source
- The discussion in the usability forums that initiated this project also got some good reflection on whose job usability is
