There have been some threads in this forum recently about particular aspects of usability, and one of the proposed projects for Google Summer of Code is to produce some usability guidelines for Moodle: http://docs.moodle.org/en/Student_projects#Moodle_Usability_Guidelines. Which has got me thinking about this.
Meanwhile, at work, Niall Sclater, head of the OU's VLE programme has been going around saying to anyone who will listen: "Any student who can order a book from Amazon should not have any trouble using the OU's VLE".
This seems like a really good way of summarising what Moodle's usability goal for students should be. So I was wondering if it was worth trying to come up a few other statements like this to summarise our usability aspirations for for other roles, so when we are discussing the details of how to improve usability, we have a common understanding of what the target is.
Of course, this is quite ambitious, because Moodle has users from all around the world; and of ages from K-12 to university students to commercial training; and users who just touch Moodle occasionally, to users who work with it every day. The good thing about Niall's statement is that it related Moodle usability to some other common task, so applies across age groups and many cultures.
I invite you to try to come up with your statements. I'll give my own attempts in a separate post.
* Any student who can order a book from Amazon should not have any trouble using Moodle.
* A Teacher who is an experienced computer user should be able to work out how to set up any part of a Moodle course, after reading only a brief description of the available features in the built-in help or MoodleDocs.
* A Teacher who is not confident using computers should still be able to learn enough to create and use a basic Moodle course in a one-day workshop.
* Someone who has previously installed Drupal, Wordpress, or another popular PHP web system should be able to install Moodle for their own use, just by following the instructions on MoodleDocs.
* No one feature of Moodle should be so complicated that you cannot describe 90% of the functionality in that area in a chapter of a book like "Using Moodle" by Cole and Foster.
* An experienced PHP developer who has not previously worked on Moodle should be able to create a new Block that something simple but useful in under a week, using the documentation new block template and help from the forums.
[I think we should limit this to 6 statements, so if you want to try, as well as writing each statement, you will also have to decide which categories of people it is most important to have a statement about.]
* A Teacher who is an experienced computer user should be able to work out how to set up any part of a Moodle course, after reading only a brief description of the available features in the built-in help or MoodleDocs.
* A Teacher who is not confident using computers should still be able to learn enough to create and use a basic Moodle course in a one-day workshop.
* Someone who has previously installed Drupal, Wordpress, or another popular PHP web system should be able to install Moodle for their own use, just by following the instructions on MoodleDocs.
* No one feature of Moodle should be so complicated that you cannot describe 90% of the functionality in that area in a chapter of a book like "Using Moodle" by Cole and Foster.
* An experienced PHP developer who has not previously worked on Moodle should be able to create a new Block that something simple but useful in under a week, using the documentation new block template and help from the forums.
[I think we should limit this to 6 statements, so if you want to try, as well as writing each statement, you will also have to decide which categories of people it is most important to have a statement about.]
Hi Tim,
this is a good starting point. There will be one problem we often see in trainings for teachers. Their minds are no white papers. They are thinking in different terms, means and processes. Thats good , but its also a problem.
If you are free to think really newly about a new product, its easy to understand the philosophy and processes behind. If you are experienced you think in other philosophies and processes: why doesn't it make the things like...? Is it done in the same way like...?
Usability is the awareness of a user. And this is different for each person.
Explaining processes in Moodle often I ask the teachers that I'm teaching how they do the things on paper. For example a quiz. Creating a quiz is a process with a lot of different steps they have to do. But they don't make this steps systematically. Some of the steps are made intuitive. Some teacher create grades and points during the correction of a quiz.
Discussing the process of quiz editing in Moodle they say there are to much steps. It will be easier to make it on paper. In the terms of usability they say me, its no good usability.
Problems of usability definition will be that user make comparisons with other tools (ICT tools and paper based) and their own habits.
In reply to Ralf Hilgenstock
Re: Usability: Moodle usability - general principles
by Ger Tielemans -
Talking in metaphors.. Colorblind does not ring a bell in the heads of webdesigners, call it webblind does..
In reply to Ralf Hilgenstock
Re: Usability: Moodle usability - general principles
by Pierre Pichet -
"they say there are to much steps"
This is perhaps why the Cloze multiquestion question type or the GiFT format are so popular
and also why I work some projects on these formats altough I am not using them in my own courses.
Testing the new multianswer(cloze) question
Instant Cloze (Gift?) decoding and importing interface
Pierre
This is perhaps why the Cloze multiquestion question type or the GiFT format are so popular
and also why I work some projects on these formats altough I am not using them in my own courses.
Testing the new multianswer(cloze) question
Instant Cloze (Gift?) decoding and importing interface
Pierre
I think there must be also a statements concerning the number of page loadings to do something, and the time it takes (or their size, since time depends on many things). And if it really must take a big time to load, it can at least show user some useful info in the process, not wait while most of the data will be loaded (as many pages do right now). These statements are harder to formulate, but that's most common usability concerns for the teachers of our university now, and I think not only our...
Often many reloading of big pages may render unusable even quite good things. The worst thing there for now is course/cm editing, especially with AJAX on (it may be even faster to do many things without AJAX 
).
Page load time rules like that can't really be specified, because it depends so much on the server hardware.
We already have the rule that any page should be produced with a fixed number of database queries, not matter how big the site is, and mostly we achieve that. (If you find somewhere that we don't, that is a bug, and should be filed in the tracker.)
Number of clicks to achieve something is just one usability heuristic. Again I don't think hard rules are very useful. I would rather that the coding guidelines encourage developers to think properly about usability. (Rewriting the coding guidelines, including more user interface guidelines is on Martin's to do list.)
I went to a talk comparing Moodle and Blackboard at the Brisbane Moodle Moot last October. That compared click counts for common operations, and Moodle was a clear winner.
We already have the rule that any page should be produced with a fixed number of database queries, not matter how big the site is, and mostly we achieve that. (If you find somewhere that we don't, that is a bug, and should be filed in the tracker.)
Number of clicks to achieve something is just one usability heuristic. Again I don't think hard rules are very useful. I would rather that the coding guidelines encourage developers to think properly about usability. (Rewriting the coding guidelines, including more user interface guidelines is on Martin's to do list.)
I went to a talk comparing Moodle and Blackboard at the Brisbane Moodle Moot last October. That compared click counts for common operations, and Moodle was a clear winner.
I found one rule - not so general, but something - about page reloads (click is far cheaper than reload):
* If a page give you a list (table) of something (i.e. questions, cms or something else), along with possibilities of add/edit/delete it, than any additional add/edit/delete pages should be opened in popup window, that will update main window as necessary without full reloading.
Example of using this in edit situation is assignment grading popup, which updates grading table. However this is not so easy in implementation. It would be actually good to get some functions to help implement it in core libs.
As for page loading time, it also depends on page size (and size of accompanying scripts). Useful rule there would be to let big/slow pages show parts of them in the process of downloading. Right now many moodle pages show header, than nothing more before all page get loaded (this is probably caused by html layout they are used). This is easy visible on course editing page with AJAX on.
I wonder if it would be useful to distinguish "usability by role." Here's what makes me think of it:
One thing I've always admired most about Moodle is its clean and user-friendly and uncomplicated interface. In fact, what I admire about Moodle is what some faculty at my college despised when they looked at it some years ago ("We can't use that - it's obviously made for children"). Ignoring that type of ignorance and moving on, I think Moodle's designers have an intuitive sense of clean and uncomplicated design, which makes Moodle really easy to pick up and use, whether you are a teacher, K-12 student, or college student. The only time I've ever experienced a "MEGO moment" with Moodle (MEGO = "My eyes glaze over") was when I took a formal Moodle class for admins and was introduced to the role-setting matrix in Moodle 1.9. It was truly mind-boggling - maybe still is (I haven't visited it in 2.x).
Now, what is usable and straightforward for a teacher or student might be partly the result of an administrator who is working behind the scenes, making everything work smoothly. So is there a level of usability (a high or easy level) that is right for the novice user, while the Moodle admin is left to struggle with controls that are much harder to figure out? (like Tig Notaro's comment, after her mom died and she was diagnosed with cancer, "God doesn't give you more than you can handle"??). Or is there one level of usability that is right for *all* Moodle users?
One reason I think it might be useful to consider this question is that I'd wager a high percentage of Moodle admins are actually novice admins - teachers who are running their own Moodle installations, corporate trainers who downloaded Moodle b/c their small companies needed an e-learning solution, and the like. They are amateur admins, not professional admins, and I wonder if Moodle's designers have striven to make Moodle's admin interface as easy to use as the teacher's or student's interface. Anyway, I'm glad we are having this discussion, and when I read Tim's points, I immediately started parsing the issues according to roles. Thanks. - Peter
Hi,
some thoughts then:
Any student who can order a book from Amazon should not have any trouble using Moodle.
Yes,
but the interface between teacher and learner for engagement with an LMS such
as Moodle needs to include a shared understanding about the purpose of such engagement....so,
navigation is one thing...a shared understanding about outcomes is quite
another
* A Teacher who is
an experienced computer user should be able to work out how to set up any part
of a Moodle course, after reading only a brief description of the available
features in the built-in help orMoodleDocs.
And
if a teacher is not an experienced computer user, there needs to be
liaison/collab with admins/LTs and a structured CPD pathway
* A Teacher who is
not confident using computers should still be able to learn enough to create
and use a basic Moodle course in a one-day workshop.
mmmm.......in
theory, but I like to think teachers have questions and before executing a
course as an outcome of a workshop....they may wish for a one-to-one session to
feel confident about application and affordances of the tools....to do what
they write on the tin eh!
* Someone who has
previously installed Drupal, Wordpress, or another popular PHP web system
should be able to install Moodle for their own use, just by following the
instructions on MoodleDocs.
Yes, and to be fair
the docs are crystal clear and helpful in terms of this
* No one feature of
Moodle should be so complicated that you cannot describe 90% of the
functionality in that area in a chapter of a book like "Using Moodle"
by Cole and Foster.
Yes-agree,
but functionality in isolation doesn't go far enough....functionality bridged
with application vignettes is a winner in any text about moodle....given it's inherent
creative possibilities for innovative practice-and I have not been overly
generous there-now you know me...Mrs Criticality!
* An experienced
PHP developer who has not previously worked on Moodle should be able to create
a new Block that something simple but useful in under a week, using the
documentation new block template and help from the forums.
Possibly,
but building on previous code is one thing-what one wants to do is another in
terms of linkages with Moodle Version....now I could be wrong of course...
[I think we should
limit this to 6 statements, so if you want to try, as well as writing each
statement, you will also have to decide which categories of people it is most
important to have a statement about.]
I don't need to make 6 J just one:
There needs to be more joined up thinking in terms of linkages across Moodle's interface/UI and resources/activities etc for teachers and admins to pick up on such connections in order to support the learner....so, I am not saying nothing new- right?
Cheers,
Dawn