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.
- 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
- 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
- Forms usability:
- While discussing changing the advanced form items symbol and how it should be implemented, the whole idea of progressive disclosure in forms, in the form Moodle has it now, was questioned, and solutions were discussed
- Related: tabbed sections, Collapsible fielsets for uncluttering editing pages
- Form elements: checkboxes (more about checkboxes) and communicating default values, dropdowns (tracker item, 7/Sep/09 so beyond GSOC but still related; added here 17/Oct/09)
- Forums usability
- FYI: Installation & Update documentation
- The best UIs in Moodle? (Moodle User Interface Guidelines)
Implementation advice and support:
- A Thickbox plugin for Moodle
- Questions won’t add to quiz
- I also got support for adding images to Moodle from Chris and Frank
There are still quite a few things related to this project I probably want to work with sooner or later:
- Report the usability testing done for this project. First as a summary of conclusions [DONE], a concrete suggestions for changes to the UI (will go to MDL-19586), and later as a presentation about how the very low resource (0 euros, three days) usability testing was carried out.
- Slowly work through the notes I wrote while inspecting different parts of Moodle UI
- Individual efforts to further take on (see above for links): help tooltips, course editing mode (usability testing of the current Moodle UI required to verify which are the most serious issues) , Roles UI and documentation, usability of the three row toolbar of the new TinyMCE rich text editor (create ticket), discussion with Nicolas Connault about what should be done with the different misuses of dropdown menus, Nadav Kavalerchik’s UI ideas
Available for grabs
(Edit August 19th: I decided to take these items separate, as they are things I hope anyone interested in Moodle usability could take on. My meaning is not to own any of this, but to just discover things we can work on together.)
- Start new discussions to gain further feedback about the guidelines and about many of the above suggestions, and about Moodle usability in general
- Engage with the community in the discussions already started (especially the persistence of editing modality, RFC: Editor file management in Moodle 2.0, Changing the advanced form items symbol, keeping user data safe)
- Go through the items Anthony Borrow and others have pointed me to
- Create tracker tickets where guidelines are currently not adhered to
- Improve the usability of the guidelines, namely create MediaWiki categories and templates for them to make browsing easier
- Create some of the listed, but missing guidelines
- Get feedback about the gathered Major Usability Issues in Moodle. Before this, define & explain criteria for them, to allow others to contribute to the list.