Note:

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

Usability

From MoodleDocs


Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.


Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.


Some pointers, links, and resources on the topic of usability with respect to Moodle.

For general information on the concept of usability see Definition of user experience (UX).

Contribute to Moodle through Usability testing

An ongoing need of a project such as Moodle is to keep the interface usable as the code matures. Improvements and added functionality may seem like a wonderful innovation from the coder's or administrator's point of view, but if the end-user is confused or frustrated by it (or can't even find it!), its usefulness drops dramatically.

The idea of usability testing is simple: a person who is well-versed in Moodle gets together a small number of willing participants, who have no previous experience of using Moodle, and who are not technology experts (such as web designers etc...). The closer these people are to the "typical user" (for example a high school student), the better. The person conducting the test simply observes the participant as he/she tries to achieve a number of tasks. A video/sound recording can also be made with the prior consent of the participant, and is useful for later analysis.

The person conducting the test then pools together the issues that were common between most participants, and produces a short and concise report that is then used by Moodle developers to improve the user interface.

This sort of contribution requires no coding skills whatsoever, not even HTML. You just need to be familiar with using Moodle as a learner.

The links at the bottom of this article include Steve Krug's book, "Don't make me think!". This books is the best introduction to Usability testing I know of.

See also: Usability testing protocol

"Bike Sheds"

Because changes with regard to Usability are necessarily visual and on the surface, it is a potential Bike Shed issue. This is a metaphor bandied around in Open Source circles that suggests (in brief) that the smaller the change, the greater the discussions that surround it in forums and mailing lists. People proposing small improvements to Moodle should be aware of this phenomenon and not take the level of discussion as an implicit criticism of their suggestion.

You can read a well-written account of this metaphor that originated on the BSD mailing list under http://www.bikeshed.com.

Avoid the word "intuitive"

(Definition: Intuitive)

Intuitive is a word you should avoid in discussions of usability as its meaning is often confused.

It is generally accepted that a large part of usability is based on familiarity and experience. Human Interface Guidelines published by people such as Apple or Gnome strive for logic and consistency so that the learning can be easier, and the experience more valuable. Using 'intuitive' as a short-hand for something that is familiar often gives the impression that if something is 'intuitive' then it is so regardless of prior learning or experience and therefore equally true for everyone. It suggests that the goodness or badness of an interface is situated within the interface itself, rather than in the relationship between the user and the interface.

Very few people would object to the statement that 'Apple software is more intuitive than Windows software' yet to someone who has only used Windows software, this is clearly not the case. Avoiding using the word yourself and mentally translating other people's use of intuitive as 'something I like' e.g. "Moodle's block system is unintuitive" = "Moodle's block system is something I don't like" may help to defuse arguments because it is harder to argue about personal opinions that are stated explicitly as personal opinion rather than disguised as objective statements about the software.

Therefore what is called intuitive, in the case of Moodle, will depend on your experience and expectations of other learning systems, web applications or sites, as well as software in general and thus varies from person to person. Usability studies should therefore average out the expectations of many people to find what is 'intuitive' and check to see if different groups (e.g. users of particular alternative systems, total beginners) have different expectations.

This article explains more and better (with diagrams!): http://www.uie.com/articles/design_intuitive/

Learnability versus usability

People often confuse these topics, understandably as they do have a great deal in common. Generally what are referred to as 'usability' improvements make things both easier to learn and easier for experienced users. Occasionally decisions need to be made favouring one over the other, and in those situations it helps to be explicit which of the two you are referring to. There are many successful software tools that sacrifice learnability so that power-users can be more efficient. It seems likely that Moodle will continue to lean towards learnability in these cases, though again 99% of the time these goals are not in conflict.

Don't automatically suggest a new preference

In open source projects it is often easier (in the short term) to defuse any disagreement by 'adding a preference'. This means you end up with double (or triple..) the code to achieve the same thing.

Every time you provide an option, you're asking the user to make a decision. - Joel on Software: Choices

  1. That's more code to write, debug, maintain etc. And once you end up with preferences interacting the potential combinations become astronomical and you end up in the situation that no two people are actually running the same program.
  2. Each new preference wastes user attention span and time. If you think you really need to add a preference, consider applying progressive disclosure.

This can, over time lead to a profusion of preferences, each of which has a cost that needs to be weighed against its benefit. Sometimes finding a solution that pleases everyone (to some degree) is preferable to adding preferences for each idea. Learn to know what your users really need. Instead of pleasing everyone separately, make opinionated software.

This is explained far better by Havoc Pennington in his piece on Open Source and User Interface, in particular the "Question of Preferences " section about half way through: http://www106.pair.com/rhp/free-software-ui.html

Is Moodle a website?

The somewhat tricky thing with regard to Moodle's usability is that Moodle is a web application, not a web site (though the line between the two is sometimes blurry) and few, if any, books have been written for that class of software. Therefore many applicable pieces of advice (from web, software or product usability guides) need to be reassessed with Moodle's nature in mind.

Additional Resources

Websites

Books

Web specific

A really good book, full of good info yet brief, well written and accessible. A sample chapter is made available on his site, as well as 3 complete chapters from the 1st edition in pdf format, covering a complete script for usability testing.

Moodle specific


Computer specific

A usability classic: a thought-stimulating, yet an entertaining higher-level perspective on the friction between user-centered thinking and software engineering thinking, and on solutions to start really designing for the actual goals of the users using Personas, Goals and Scenarios.
Jef, who sadly passed away recently, has been more and more research focused for the last 15 years, since his days helping to create the first Macintosh. This led to a discarding all practical considerations to concieve of the 'perfect' UI, rather than attending to the pragmatic, checklist-style "improve your site in 15 minutes" genre. However his writing is excellent in consistently laying the blame for problems with the computer and its software, not the user. It is often easy to fall into the trap of thinking 'stupid' users are the problem, rather than simply a design parameter. It is however worth remembering that (unless you are a research fellow) many of these technical faults must be worked with to a certain degree, and that "perfection can often be the enemy of the good".

General

It's a classic, so some of the examples are a bit dated, but the basic message that it is fundamentally hard for a designer (no matter how smart) to place themselves mentally in the position of a user is put across well. I think about this book's simple message every time I push a door I was supposed to pull and vice versa.

See also:

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