Creative Commons

December 20th, 2011

At LUNS Limited they’ve collapsed the Moodle form fieldsets that only contain optional items, in Moodle forms. Without having seen any usability test results or knowing whether they exist, it does seem like an elegant solution at first glance! (Discussion)

They’ve also used the example of the Quiz Add question dialog (tracker item) we did with Tim for allowing people to add activity modules on the course front page. Originally I actually found this UI pattern in QuestionMark during the user research sessions done for the Quiz UI redesign project – great to see it being put to good use.

This should make adding activities more straightforward. Yay!

(Thanks to Helen Foster for the screenshot and to Mary Cooch for the screencast)

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.

As the plans to usability test a part of Moodle as a part of this project have not become reality as easily as I hoped, I was wondering if testing this idea would take on. So I needed a prototype, and then I remembered Shoes, which I had hoped to try out. It seemed like a toolkit to build something pretty quickly.

I needed something to tinker with in midst of my flu since I could not do anything very intensive, so I started playing. And now I have something of a prototype. And it works out of the box in Windows, Linux and OS X. \o/ Plus, I have learned a bit of Ruby, though umh, in a somewhat unorthodox manner. Including tweaking, all this took me a couple hours of coding during three days, plus a fourth day to start learning the thing.

I am not sure how to combine object-oriented programming with Shoes’ way of outputting things, to iterate over the code, so I only have one ‘resource’ so far. I will have to figure out how to fix that. An upside is that he code is so ugly and unmaintainable that hopefully no one would ever consider growing production software out of a quick prototype built with that…

June 25th, 2009

Yesterday, I read A Pattern Language for Pattern Writing, which Tim Hunt recommended earlier. It was really good, and though it was at first dry, the need I had – producing Moodle user interface guidelines – kept me motivated. The book itself uses the patterns it presents – this was confusing at start. But as I read on, it seemed to work and both the form of the book and the content contributed to help understand the same substance. Although the patterns of the book are for creating software (programming) patterns, it seems to me that mostly they may be good for also UI guidelines. OtherHIGs seem to have way less form and more prose, though.

Too bad it was written in book style as a single web page. As it still had the website’s navigation, I had to copy just the text content to a word processor, format the text, add a table of contents and print it to read it. Hm, maybe I should make the guidelines I am making easily printable as one document? Not the first priority though. It makes me wonder if the guidelines themselves are appropriate for the web if they were designed for print. I am planning to think about the form of the guidelines for the rest of the week and then present examples and my core ideas to the community on Monday.

Also found Lazarus while searching for a solution to the frustration caused by various web forms losing my data. Either this sort of functionality should be integrated to all browsers, or most web apps should be WAY more careful not to lose user data. I am writing a guideline for Moodle for various Moodle scenario specific ways to avoid users getting any more paranoid about their data than they are already.

June 18th, 2009

I could not find a ready-made implementation of YUI javascript inline help online, so I created one.

Moodle uses just popups for the integrated help. They are relatively easy to find since those question mark icons are all over the UI. But they still take the user somewhat out of the context of the application. Less experienced users are typically confused with new windows opening. It is also incredibly slow to open a new window in many browsers.

So I am thinking of proposing inline help as a part of the guidelines produced this summer. Mainly to entertain myself and to see how many interaction details there are to take into account, I made a demo that uses the YUI javascript library to achieve this. Actually, the second example is not inline help at all, but a YUI Panel which sits on top of the content.

I believe popups are still required in Moodle when it comes to more lengthy help texts. The inline help can not replace a popup window when there is no space in the UI for it, but an YUI panel perhaps could.