Latest Updates: GSoC RSS

  • Quickie Usability Testing: File upload and Forgotten password

    August 19th, 2009

    Note: The below test results require understanding about the UIs in question. Follow the links in the beginning to have an idea what the UIs in question are like.

    I had eight test subjects during three days usability tests last week. The tests took about 15 minutes each, but gave plenty of data. The main conclusions:

    • Uploading images to the rich text editor in Moodle 2.0 has too many steps and they are well hidden. All 8 of the users really struggled in one or more of the steps (different users in different ones). If it weren’t for a test situation where users typically try more (since they assume the task is possible to do and there is social pressure), even more of them would have likely failed the task.
    • The old ‘forgotten password’ form failed or caused struggles in 4 out of 5 tests. The new form caused no confusion in any of the three tests. (I intended to have an equal number of tests for both. This was a mistake on my part.)

    This is discussed in the tracker item MDL-16597, along with proposed solutions (Updated September 2nd).

    File Upload in the Rich Text Editor

    In the foreseen Moodle 2.0, it is possible to upload images whenever there is a rich text field. Except for the [Choose…] button in the Insert/Edit Image dialog, this diagram/mockup is a very close image of the functionality in Moodle 2.0 HEAD I tested, although there were only three sections int

    • Getting from the text editor to the dialog where you can select which image to upload takes five clicks. Users got lost in all four steps except the last one (pressing the “Browse…” button), most of them in several steps.
      • 1. Get to the add image dialog (4 users found toolbar button, 1 found the item in the right click menu for opening the dialog)
        • Failure: 2 subjects (needed my help to proceed)
        • Struggles: 3 subjects (searched how to do it for several minutes, trying clipboard and drag&drop etc. but continued on their own)
        • Passed this step without struggles: 3 subjects
      • 2. Click the ‘browse’ button (URL is a technical abbreviation and got many users lost; some complained that they do not know what it means; one user complained that URLs have nothing to do with uploading an image from the local computer and was confused due to that. Some users wrote the image name in the description/title field or both; they did not understand the difference between the fields)
        • Failure: 2 (1 needed my help to proceed; 1 gave up at this point)
        • Struggle: 2
        • Passed this step: 4
      • 3. Click “Upload a file” (after this clicking “Browse…” and finding desktop where the file was, was quick)
        • Failures: 0
        • Struggles: 4 (In general, users assumed ‘Local files’ to mean the local computer and first thought they should look there. Thus they  were not looking for upload anymore – apparently they assumed they were uploading already.)
        • Passed this step: 3
      • 4. Press “Browse…”
      • Passed this step: 7

    Notes:

    • One or two of the users did not recognize the rectangle under the file upload field as a button so got stuck for a moment there.
    • One user did not understand they still had to click the Insert button in the first dialog to actually get the image in the document.
    • Users ignored “Current files” section, some of them wondered what that is

    Forgotten password form

    The old form was confirmed misleading since it made 80% of the subjects fill both of the fields. Some of the subjects still did not understand what to do after the form gave the error message to fill one field or the other – apparently the visual (erroneous) message given by the form was a stronger clue to them. What the original forum thread reported was clearly right. I am really surprised such an issue has not been spotted before.

    When it was too late, I noticed the WordPress people have designed it even better, though than I did. How bitter: I did not believe it when someone told me having a single field might be a better solution. Now that I see it I think that might have worked better. (Especially due to the formslib bug we have that makes it impossible to have two forms on the same page and thus probably makes the current solution not accessible). Nonetheless, since we now have promising usability test results for my design and none for that of WordPress, I still recommend keeping my design (patch) for now.

    Other notes

    • TinyMCE and other parts of the file uploading were in English, although the browser and rest of Moodle were in Finnish since all the test subjects were Finnish. This may have slowed users down but all the test subjects demonstrated during the tests that they understood the English they encountered.
    • All test subjects were my friends and in theory this might have introduced a bias. However, as they were unfamiliar with the UI in question and I did not help them during their test taking, the issues they encountered seemed genuine. This can be disputed though and I welcome discussion about this style of low-fidelity testing.
    • The test subjects were Finnish young people between ages 20 and 30. Three males, five females. Occupations: software development basic degree graduate, musician, social worker student, industrial engineering student, unemployed, interactive technology student, college teacher, kindergarten teacher

    The videos taken (screen image and recorded voice in Finnish) are available on request.

    I hope to explain how I did this round of testing and which were the parts where I made it easier for myself. There will hopefully be a blog posting or a video, to show the community how little work this can be.

    The test preparatory talks and setting were roughly the same as in last summer’s Quiz UI tests, though less formal.

    The test tasks

    (More …)

     
  • The fruits of the summer

    August 17th, 2009

    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 backuphelp tooltipspaint 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:

    (More …)

     
  • Course editing

    July 18th, 2009

    Note: this thinking continues from another angle in What is a course & the tools for having a great one (Part 2).

    Addition May 2010: Note that the solution presented here is problematic with touch screens where there is no mouse hover so the UI can not be activated.

    Wondering about various switch controls and how to give guidelines for their use, I ended up designing an alternative UI for editing the course page (discussion and related cross post). Addition Jan 30 2011: the screenshot image is so hard to view in a useful size in the new version of Moodle Tracker that I am posting this here – also the shoes version seems to have broken over time.

    Click to enlarge
    Prototype for course editing

    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…

    I am so exhausted. Next: staring at the ceiling for about 36 hours.

     
  • Paintweb + comment gathering

    July 3rd, 2009

    On Monday, I published the current form of the guidelines and asked for comments. Otherwise, this week was spent working on my master’s thesis (about Moodle & open source usability). It is going forward surprisingly well. Fitzgerald in The Transformation of Open Source Software (PDF, 268 KB) talks about OSS 2.0. I thought that the fact that Moodle is a vertical domain application and shares also other properties of OSS 2.0 seems to explain why usability work with Moodle is quite different from usability work with more traditional F/OSS applications.

    Today, I also made some mockups to suggest some new designs to Mihai’s Paintweb, the upcoming drawing tool for Moodle 2.0 I am very excited about.

     
  • Usability discussions

    June 30th, 2009

    There was a bit of discussion related to Tim Hunt’s last week post about what really matters in Moodle development. The answer is, the users’ educational needs matter. I was excited to see these thoughts. It seems to indicate that the overall user experience is starting to get taken into account the Moodle community.

    Then, someone raised the question in the developer forums: “Why open source software usability tends to suck” – how do we work around this? That thread includes my reply to both Tim’s post and the questions raised by Matt Gibson.

    As a sidenote: For a moment, I have switched over to the “dark side” – I am trying out MS Word 2007, and I still can’t help admiring the UI. Even the colour theme adds up to create a peaceful writing environment where I can concentrate on what’s important – my writing – arguably better than in any other word processor. If only I could stop drooling at the UI and start writing… ;)

    I noticed that this thing incorporates a complete blogging client, too, neatly integrated into the UI without adding any clutter – a feat requiring sophisticated understanding of the users’ needs in itself. Maybe Microsoft is learning something…? It didn’t even add any garbage “msHTML” in the postings. It seems to have added line breaks in the final post though they are not visible in Word.

     
  • Pattern literature

    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. Other HIGs 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.

     
  • Inline help

    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.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel