Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Usability/Improve Moodle User Experience Consistency

From MoodleDocs

Parent page:Usability

Project outcome: Moodle User Interface Guidelines

This project will create a a lightweight Human Interface Guidelines style documentation for Moodle, as part of a review of Moodle's overall user interface.

It is not about making usability recommendations to specific parts of Moodle, but trying to see patterns in the way UI's are made in Moodle, and to make recommendations concerning those patterns.

Note: This is a project plan, and although I have made an effort to organize the content, as such might it not be very easily readable by random passers-by.

GSOC '09

Overview

Executive Summary

Review Moodle's overall user interface. As an intermediary step, create a lightweight Human Interface Guidelines style documentation for Moodle. After having gathered the principle interaction styles and elements, discuss them with the community and fix the most obvious inconsistencies found.

Motivation

In Summer 2008, I worked to enhance the usability of the Moodle Quiz module, based on reported needs of teachers. During this project the lack of usability documentation became obvious. On one hand, there is an implicit Moodle way of doing user interfaces, but then it is not very well documented.

When I started working on the Quiz UI I was not deeply knowledgeable about Moodle as a whole. Though consistency was discussed in that project, the fact shows in the outcome. It was difficult to keep a complex UI design consistent with the whole of Moodle where the spectrum of UI elements and interaction styles used is quite limited. Moodle is just starting to introduce the fluidity of AJAX-style UIs.

Although I have been developing for Moodle since Summer 2006, I also consider this an important learning experience about the whole of Moodle for myself, to gain deeper understanding about the different possiblities provided by Moodle, and about how they correspond to actual user needs.

Summer 2009: In practice

Moodle is a web application. Web applications do not, in general, have strict consistency rules or UI guidelines. However, Moodle is also starting to be a big application.

Different parts of it share similar interactions, and they should work similarly across different components, or modules. To this end, developers should be capable of searching the documentation for topics such as “selecting a group of users” or “opening a file” and find a concise explanation describing what the user experience should look like and possibly how to implement it.

Based on the usage scenarios and use cases of each component, a limited amount of usability testing will be carried out. Necessary improvements will then be suggested on the user interface level to enhance the interoperability between different parts of the whole.

I will implement changes, the need for which rises from the research phase that can be sufficiently usability tested, agreed about in the community, and are reasonable easy to implement in terms of software development. Larger-scale guidelines for improving consistency will be discussed in the community and documented.

Project plan

Detailed project plan (and schedule): Usability/Improve Moodle User Experience Consistency/Detailed project plan

The idea is to keep ideas and perceptions in this docs page and possibly in subpages. I will go through Moodle 2.0 HEAD and in case something is broken I will refer to Moodle 1.9. Results of the project will possibly be in Interface_guidelines although that may still be something different from what I'm actually doing in this project - so another page might be needed. During the project I will listen to the community of developers a LOT to understand their needs and the scenarios in which they might use something like a HIG.

TODO DONE May09: Create a ticket in tracker with the subsections of the project ... hm. I really don't find the tracker UI very suitable for this kind of a project. Can anyone name a real reason to use time creating those subtickets? Maybe I'll just create a single big ticket and link it here to the actual project plan. 

Well, it's useful to organise the stages, indicate their completion status, 
Moodle versions, as well as add watchers/notification and so on.  Consider
it a Moodle.org usability guideline :)   Martin Dougiamas 08:25, 3 June 2009 (UTC)

UIs to examine

My current impression is that at least the following are an integral part of the core Moodle experience, and need to be evaluated as a part of this project. This list is not definitive, but serves as an initial perspective of the scope of the project.

☑=initially examined for elements and interaction styles to include

  • Course management: Front page, category page, Main course page (including different formats; topics ☑), course completion (http://moodle.org/mod/forum/discuss.php?d=126016)
  • Roles management
  • My Moodle, User profiles, course participants list
  • Assignments, Chat ☑, Database activities, File management, Feedback (Questionnaire) http://moodle.org/mod/forum/discuss.php?d=52861&parent=550322, Forums(☑), Glossaries ☑, Quizzes (☑), Resources ☑, (Wikis ☑, Lessons, Hot Potatoes)
  • Gradebook (the new UI interoduced in 1.9 and 2.0 in 2009), Outcomes, Backup& Restore, Question bank, various Settings screens (forms).
  • More modules listed in using moodle forums listing (could not find it from moodle.org menus now)

See also: Tracker items tagged 'usability'


Various ways to categorize UIs and their parts

  • Goal-related
    • Functional wholes: site administration, course hierarchy management, user management, course management, student: keeping track of courses/duties, rights management (contexts,roles)
    • Processes: installation, logging in
    • Use cases: login when following link to protected page, checking for new posts, grading things
    • User motivations: efficiency, privacy, social meaningfulness, fitness for purpose, satisfaction/pleasantness
  • Page types: Course page, module pages, tabbed pages, configuration pages (and rights management), user-specific pages (profile/my moodle), popups/specialised pages (help windows, chat windows, quiz question preview)
  • Functional units: courses, modules, blocks, editors
    • editors: text editors (plain, wysiwyg), equation editors, image editors, sound editors
    • Modules: Forum, Quiz, Wiki, Assignment, Glossary, Gradebook, ...
    • web app taxonomy: configuration, content editing pages
    • domain-specific taxonomy: course categories, courses, modules, blocks
  • Page regions: Header, footer, sidebars, content area
  • Interaction styles: wizards, forms, different course formats
  • Elements: Tabs, different form elements, links, buttons, dialogs, breadcrumb navigation, tooltips, list tools (add element to list from a set), table tools
    • Navigational elements: Search, breadcrumb, menu, tabs, modes, headings
  • Technology: native in browser, plain html+css, browser scripted (js, canvas), dynamic/desktop-like (ajax, flash), plugin-based (java, flash, separate video players), email-based, IM-based, on-screen, printable, mobile,
    • Modality: auditive, visual, tactile
  • Modes
    • global: "view as student"

Interaction styles/elements to possibly examine

striking through as temporarily moving to an openoffice.org document

  • consistency of feedback from any and all user actions; normal and error situations; recovery
  • data listings, such as quiz editing and moodle course front page
    • functionality: moving elements in a list (reordering), moving elements between lists
    • gradebook: clicking on column titles to highlight the column
    • tables vs. lists vs. divs with complex data
    • alternating colours for rows: in general it is a good idea and helps to guide the eye better than just a table grid. There should be a contrast in luminosity of the rows (just alternating hue might not be enough), to make sure also colorblind people can see the difference. Also if some rows/colours can be selected, changing their background colour again, this might have to be rethought.
    • filtering selection lists MDL-17780 MDL-19285
  • forms
    • simplicity through progressive disclosure
      • quiz question editing forms for various question types
    • on simple forms, (less than one page / four elements or less) autofocus the first field of the form on body onload IF none of the fields have any changed content in them (i.e. if the user is not returning to the page from browser history, see: MDL-825)
    • autosave as a standard on all forms: in case of network outage / simultaneous editing by someone else / some other conflict situation, always tell the user there was an error and **give the users their data back** so that they can
      • optimally, try again saving the data, resolving that conflict
      • or at least copy what they filled in to clipboard
      • currently losing data is also a problem when the editing time of a forum post has passed but the user is already in the post editing form and has changed something: moodle gives an error message that editing time has passed, and just discards all the changes the user tried to save.
        • The same applies when user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to do that (in a different window), submitting the form again fails and the user loses all submitted data: if there are no security issues to this, Moodle should give the user their data back so they do not lose it.
    • Feedback for form actions; an intermediate page giving feedback with META refresh
      • slow, clumsy, issues with browser history(?), not standard with most of the rest of the web
    • Like in WordPress, javascript confirmation if the user presses the back button when already having filled in data but not submitted the form. Especially when using ctrl and shift with arrow keys to move around in text (though it's possibly a marginal use case), it is easy to inadvertedly trigger the shortcut key of the back button in the browser.
    • Configuration defaults: http://moodle.org/mod/forum/discuss.php?d=124533
    • Date selection: use javascript selector (how about time?)
    • Buttons in each module configuration: save and return to course / save and display / cancel. Are there really use cases to support having this choice each time?
  • editing modes: inline editing (course frontpage) vs. editor (quiz)
    • related: most CMSs have separate control panels and inline editing is extra, in Moodle there is no clear distinction between control panels and content pages
    • http://moodle.org/mod/forum/discuss.php?d=122300#p536641
    • related: when editing something in a form, if the user is exiting the page without saving page, give a javascript alert on pageunload (?) confirming whether the user wants to save the changes first
  • dialog title bars visuals: file selector vs. quiz dialogs
  • modal buttons; buttons that have an on/off state: show the command to change or the current status
    • According to the strictest rules of form element usage, everything should ideally be done with radio buttons and a submit button to confirm the selection. However, this is very clumsy.
    • track/subscribe a forum: button saying yes/no in the forums listing of a course VS link saying "Subscribe to this forum"/"Unsubscribe from this forum" or "Track unread posts"/"Don't track unread posts"
    • show/hide controls (eye icon/button): should it reflect the current status or the status after pushing? one idea is to have a button-style control with pressed/non-pressed visual status (thanks to Hans de Zwart)
    • In profile, enable/disable e-mail (2.0)
  • usage of buttons vs. links
    • general guidelines of using buttons for commands/actions (non-bookmarkable POST or AJAX request -> not in URL) and links for navigation/location (GET request -> shows also in URL)
      • VS what is usually done in Moodle
        • In profile, clicking (this e-mail address is disabled) does not explain it but just removes the link! (Apparently fixed for 2.0 but raises another issue of changing status of a setting with an icon)
    • But like facebook seems to do it now (2009-05) to remove clutter, sometimes when an element is clearly a command, it may be okay to make it look like a button only after the user hovers over it.
    • http://natbat.net/2009/Jun/10/styling-buttons-as-links/ - is the only UI difference that reloading (and browser history otherwise) works badly with POST? (this can be fixed with a HTTP redirect)
      • (08:22:26 AM) timhunt: Olli, the real reason for the difference between GET and POST comes when you think about web caches, or clicking reload in the browser, or, getting more technical, REST web services. (08:23:18 AM) timhunt: A POST does something, and should not be repeated, or served from a cache, without careful thought. A GET, that just pulls information, can safely be served from a cache, or repeated.
  • Tabs: even though users are already accustomed to the fact that tabs are not used in as a regular fashion as was originally thought, tabs in the same tab bar should still have some common denominators. Document these, compare with other HIGs
  • Search
  • TITLE elements of pages: descriptive of the specific content
  • popup_form() dropdown command menus (add new activity to course) vs. YUI dialogs such as 'add new question' in Quiz
  • Help: wiki ([1]), popups, inline help (http://www.pilpi.net/software/moodle/2009/06/18/inline-help/ [2])
  • usage of the frames which are rounded at the bottom. are they for summaries (m2q ► CF101 ► Resources ► tiedostot) or for the main content? (resource)
  • update this [modulename] button, and various additional buttons/links nearby
    • glossary: Import entries / Export entries Printer-friendly version
    • forum: subscripthion permission status, force everyone to be subscribed (->button), show/edit subscriptions, subscribe (->button)
  • visual consistency of toolbars (and other windowingsystem-like visuals) in tools such as equation editor, drawing tool, rich text editor
  • wizards, such as backup, need to act like wizards.

Moodle / CMS elements conveying specific semantics

  • Blocks
  • Themes
  • Filters

Future prospects

Outcomes

  1. As a result of having discovered consistency issues, fixes to Moodle 2.0 UI code to enhance the overall user experience (UX)
  2. Index of the current screen types, interaction styles and elements, with their intended uses. Should also be searchable by intended use, to find out what UI elements to use in a given situation.
  3. Secondary outcome: find and gather typical use cases of core UIs/modules -> useful for usability testing and further UI design

The format in which to present the guidelines is still unclear. The main objectives are

  • Lightness, quickness: rather links to examples and screenshots than lengthy explanations
  • Interlinked elements (UI's, issues, guidelines, etc.) to facilitate keeping documentation in context and easing maintenance.

What is ahead: challenges

We need to do this together. Although I am promoting building at least some sort of a skeleton of a documentation on the User Experience (UX) level, the point is to create something that the community can embrace and use, as a part of the developer documentation used in everyday development discussions. Moodle already has a lot of documentation for technical considerations and it has usually been easy to get help for technical issues. Usability needs to have an equally important role, as discussed many times before.

The challenge in trying to standardize something such as UI designs, is that the whole point about developing applications for humans is often about creating new styles of interactions. Thus, it is key to create a strong convention to keep this documentation up-to-date. That is, whenever developers decide that something is missing in the catalog, it will be added. The most standard i.e. common and mundane tasks need to be the most easy-to-find, keeping at least them standard across Moodle.

Also, usability testing the suggested solutions sufficiently for actually changing the implementation is quite a challenge during just one Summer.

Background: The Ultimate Goals

Goals

Give power to the developers to create good, Moodle-style UI's

The main goal is to gather lightweight HIG-style documentation to help evaluate the consistency of the current UIs and to facilitate the design of future UIs. For this to be useful, using the HIG needs to be incorporated in the developer guidelines (and in the moodle developer course) of Moodle. All UIs should be validated against the HIG. It does not make sense to document all "original" interactions. Still, at least where an UI deviates from something mundane that clearly is defined in the HIG, the fact and the reasons for it should be documented with in the documentation for the code.

The intended use of the main core modules will be studied and preliminary documentation will be gathered so that anyone building on an existing UI will know what user needs they are designing for. This will also facilitate usability testing since it will be transparent to what the main tasks to test against are, even to people who do not already know the UI (this seems to avoid the bias of defending the familiar, during usability tests).

As opposed to the Quiz UI work of last summer, the approach is top-down. The point is to examine the goals each of the main components of the user interface, in the context of Moodle, as a whole.

The goal is to create a framework for developers to think about and document the user experience (UX) of Moodle. The knowledge of what has been verified – typically with usability testing – to work for users, needs to be available. A Human Interface Guideline (HIG) is one way of thinking about it. However, there is rigidity and vastness to a typical HIG that we want to avoid: it is paramount that what is documented is both easily accessible and maintainable.

It also has to be said that a HIG can never replace an actual usability practitioner. Using a HIG simply helps us take a good direction, a basis to build upon, so that usability practitioners can concentrate on the issues that really require them. Just like in the corporate world, functional testing is a separate profession because different people have skills to do programming than testing, designing interaction is a intricate profession of its own. For further discussion about this, refer to Cooper's excellent discussion about the intricacies of the software industry: The Inmates Are Running The Asylum (limited edition on google books).

Later: Documented user descriptions and scenarios

The basic requirement of usability work is to "Know Your Users". However, at this point we do not deal with the actual profiles of users: the assumption in this project is that the community-based development style with a strong focus on feedback helps developers approximate user needs.

This knowledge about users is often expressed in terms of Personas, scenarios and use cases.

In a separate effort, Moodle should take a more robust approach to base its design on really knowing that we know our users, instead of the gut feeling of developers (no matter how close they might feel to teachers, students, or other users).

Also other aspects of HIGs, such as keeping vocabularies consistent and accessibility issues should be considered, but they are not the focus of this project.

My competences

In Summer 2008 I redesigned and implemented the Quiz editing UI: did interviews for scenarios, usability testing testing and community discussions. The result of this work is now included in Moodle 2.0 HEAD.

Before this, I worked in the University of Tampere on a Moodle integration project. I am also an Interactive Technology major in that university. I am currently writing my thesis about Usability processes in open source projects, with last summer's Quiz work as the principal case that is examined.

Current state of research (in constant state of change)

Advice to possibly include in the final documentation

  • do not relay UI design decisions to moodle admins (unless you really have different use cases where different UIs would be suitable for different sorts of users AND the UI can't take them into account "by UI design otherwise" (explain further).
    • moving the burden of making design decisions from development to administration seems a quasi-solution to me - in some cases admins may be interested and know their users well. But I think most of the time relaying such responsibility just gives an impression of an unfinished product. Of course they can be given the power to customize, but I think we should not think about that while the design itself is unfinished.
    • it needs to be carefully examined which configuration options are genuinely options that depend on different needs of different Moodle installations, and which are the effect of avoiding making strategic usability decisions that should be made during Moodle development
    • [http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html Joel on Software on Choices)
    • Martin Langhoff at #mmuk09: "Options are bad, it is what we put in place when we don't make a decision"
  • A hig includes an index of interaction styles that are part of standard Moodle: "if your proposition for a new UI contains new interactions, please link to it under the 'suggested interaction styles' in the HIG, and it will be checked out and discussed."
  • Progressive Disclosure
  • Tooltips
  • About the nature of guidelines: [3]

Issues, to be researched further

These are not tested and proven, but some things I have discovered while working on Moodle

  • forums
    • If users are not logged in, they sometimes get a login screen (forum) and sometimes just an error message (moodle.org blogs) when accessing content.
      • It is questionable whether content that is accessible via "login as guest" button by anyone should require passing through a login screen in the first place, since most web apps do not require such - it is a hassle to remember to mention "press the login as guest button to get to the actual target of this link I am posting"
        • there were references in the tracker to "guest autologin" feature but I don't know if this is it or what are the reasons for this being a setting
    • MDL-1626 (addressed already so letting go) [following a single thread and not entire forum does not seem to be possible. in the solution gmail+google groups, gmail automatically groups messages with the same subject line and shows them as one message ("thread") in gmail, too. The problem is still present also in google if one orders a digest mail: can't select which threads I'm interested in and threads are not sorted. is there an underlying design decision to forcing to follow all forum or none of it?]
  • if moodle.org wants to present usage of moodle, it should be consistent with moodle's ux itself. an example: where is the listing to all the forums from the breadcrumb?
    • course front page: showing/hiding sections
  • Feedback: sometimes Moodle gives non-localized, entirely technical and unhelpful feedback even to normal users.
    • "Olli - Under "Some potential things that require change, to be researched further" you mention Feedback being too technical and unhelpful feedback to normal users - could you cite an example or two to show what you mean? Thanks - Anthony "
  • Quiz:
    • new interaction styles introduced by usability work of summer 2008
      • icons in tabs: is this a problem to someone? preview icon should in my opinion be used in all preview tabs? the reasoning is to familiarize users to the meaning of the icon by associating it with the label
      • using overflow:none in listings where the content does not fit screen
      • question bank window: the concept of "toolbar window", per-user open/close state persistence
    • integration with question bank http://tracker.moodle.org/browse/MDL-18001 (is there something similar somewhere else in moodle?)
    • dialog styles: ok button vs something named after the actual dialog action, cancel button, which first, apply button(?), dialog visual style
  • New UI work recently done on gradebook
  • Moodle messaging:
    • Might be required: unobtrusive notifications for new private / forum messages, external notifications consistently regardless of whether user is logged in
    • Block user: green icon? (Tim, Anthony)
  • Facilities for consistent undoing across Moodle, see for example Talk:Projects_for_new_developers#XML_templates_for_admin_settings
  • Moodle messaging: mail/whatever notifications should come regardless of being logged in (is this true in the new notification framework?), unobtrusive web notifications (moodle is the only thing to use unrequested popups; see facebook and basically any web app on the planet for less distractive interaction styles)
  • new gradebook: visual report disabled states
  • file selector visual hierarchy: icons/list selection is positioned in the dialog to communicate it is related to both the panes below it when it is related only to the right-side pane
  • There is a convention to create feature description pages when new features and changes are planned (sumewhat such as the page you are reading). I am struck by how much cleaner such pages are for mozilla.org, for example. https://wiki.mozilla.org/Thunderbird:Folder_Pane
    • are all these pages organized somewhere in the wiki centrally?
  • The fact that the help system is made of popups is a problem; popups get lost under other windows, and less experienced users (the primary users of the help systems) get confused by them (surprisingly few novices master the task bar very well). Yahoo dialogs don't solve it since they are modal and don't enable the user to both use the system and refer to the help at the same time. Windows has contextual help popups that split the current window, showing the help beside the normal content of the window. Also, there should be some kind of a standard for the help texts themselves; many of them explain things assuming that users know a bunch of other techie/moodle concepts.
    • TODO: review other web apps, how is help done
    • differentiate between tutorial content that explains things (non-modal popups are suitable), and with clarifications that answer to the question "what does this mean" for example with individual configuration options (inline help - always visible or not, different icon to activate than with popup help?; short text for which a popup would be too slow and cumbersome)
  • Headings of sections: always right under the header, before any other content, stating type of activity (=module name, configuration, course categories) and possibly name of activity (a specific activity in the context of a course)

Other considerations

  • Guiding teachers to better gain from Moodle's wide array of pedagogical features has been discussed quite a bit recently. This may require novel interaction styles: guides/wizards/assisted functionality
  • In Moodle Moot UK '09 Martin Dougiamas mentioned setting up functional testing in the tracker.
    • -> This is not very far from the goals of usability testing:
        • -> some of the base work is similar since to do functional testing the core functionality has to be defined and perhaps even prioritized.
    • -> And usability testing core functionality is the basis of this project.
    • TODO: Where is this discussed and documented? http://moodle.org/mod/forum/view.php?id=56 Not here?
  • Configuration screens (Update [modulename]) / content editing screens (also sometimes in update [modulename]) / various buttons nearby the Update [modulename] button (glossary:Import entries / Export entries Printer-friendly version)
  • module configuration: a big commitment required of users up-front, giving them a huge configuration screen before they can see anything at all about what the element itself is. (advanced uploading of files)

Further reading

HIGs

About guideline/pattern/HIG writing

Patterns


Forum discussions

Retrieved from "https://docs.moodle.org/dev/index.php?title=Usability/Improve_Moodle_User_Experience_Consistency&oldid=12922"
Powered by MediaWiki