Creative Commons

The fruits of the summer

August 17th, 2009

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.

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

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

The efforts I participated in

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.

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

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

Start new discussions to gain further feedback about the guidelines and about many of the above suggestions, and about Moodle usability in general

I think that this future work related with usability has to be guerilla-style for a while and very transparent. Developers are busy with their stuff and they feel they are working for the users… so the usability has to demonstrate it’s value, because if not, it looks like more work.

The usability is not cared, to make it took into account has to be proved with results in the way developers understand results.

You make a good point, developers need to be shown tangible results in manners they can see something clearly beneficial can be achieved with usability.

And thanks for yesterday’s discussion, too. Hope you did not interpret my reaction to your ideas yesterday such that I find your approach suspicious or not good. It is simply that I am still myself a bit confused about how to approach the situation of Moodle usability. As you said, these things will not be solved in any small amount of time.

I do not feel that Moodle usability is, or ever could be, in any manner reserved for me (or any other single individual), but I welcome you to work on it any way you feel works. I am glad if I can be a part of it, but if not, it is still more important that the important things get done.

I appreciate you showing an active interest in Moodle usability. Please do not let me put you off, if I do not instantly understand what your approach is like and how it can benefit us. I am just slow sometimes! Keep pushing it to me and to other crazy people in the community, the way you see fit. We will come around and understand eventually :).

Late, but still, I want to congratulate you on the amazing work you did over the summer for Moodle! Also, big thanks for your really great feedback on the paint tool project I worked on – more of your ideas will be implemented once I get to do another user interface overhaul.

I really appreciate it, since admittedly I have been pretty disappointed with some of the community response to my work. I am impressed with your work and your attitude, and as PaintWeb’s usability develops, I will probably recommend it to be used in our university’s Electronic Exam system, as well, if they agree to acquire some Wacoms or the like to make usage worthwhile.

I only just got put on to this link after Helen Foster posted a link to the Moodle wiki’s GSoC page on Twitter.

Just like to say, thanks very much for your efforts. I thoroughly enjoyed participating in some of the aforementioned discussions with you, and this article provides an excellent overview of Moodle usability, as well as the various points for consideration about usability in general.

Thank you! The discussions were great, indeed. :) I needed the encouragement, as I will be talking about the subject in http://www.imoot.org/ next week!

Actually, it seems that Ricardo Fleck (in response to whom Helen posted the url) has tried to contact me on Google Talk, as well. However, I didn’t know who he was so I rejected the request. Good thing you sent me this, so I went to Helen’s twitter page and figured out who he was (http://twitter.com/lezardfleck )!