Summary of the Summer of Code

Related forum thread

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.

notet
tärkeät parannusta kaipaavat alueet

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

The efforts I participated in

Discussions we had

Forum threads I found valuable to Moodle usability:

Implementation advice and support:

To do

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.)

Tags: , , ,
Posted in Coding, Communication, design | 6 Comments »