Note:

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

Major usability issues in Moodle: Difference between revisions

From MoodleDocs
(This page will not be migrated to new devdocs)
 
(17 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{Template:WillNotMigrate}}
[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Major usability issues in Moodle'''
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}
Moodle UIs that have such serious flaws that in practice they require redesign.
Moodle UIs that have such serious flaws that in practice they require redesign.
== User data always (Always) safe ==
See: [[User_Data_Always_Safe]]
This is the single most serious usability flaw in Moodle. It also requires some UI design work, and then a lot of software engineering work, to get right.


== The user-to-user messaging system ==
== The user-to-user messaging system ==
This should be thought through together with the jabber messaging/notification/forum subscription system with a holistic approach.
* Popups everywhere
* Popups everywhere
* Links point to unexpected locations
* Links point to unexpected locations
* Getting trapped in a popup with the normal Moodle navigation
* Getting trapped in a popup with the normal Moodle navigation
* Designers open new browser windows (popups) on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user's machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don't notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button. [http://www.useit.com/alertbox/990530.html http://www.useit.com/alertbox/990530.html] http://www.humanfactors.com/downloads/keytips.asp
Ideas:
* A frame on the right side of the screen for messaging?<br/> Page peel / backside of the page? Not covering the current page but something you can QUICKLY turn to and from which you can quickly turn back (big return control for turning the UI back to normal state)
* Inbox/dashboard: A personal communications centre that keeps me up-to-date of all my moodle messaging: private messages,threads I have taken part in(replies to my message(s), replies to entire thread), threads I have started


== Wizards ==
== Wizards ==
Line 19: Line 37:


== Visual hierarchy ==
== Visual hierarchy ==
One big issue is visual hierarchy of screens, i.e. even if there is not as much content on a screen as there was in the old quiz editing UI, in many places there seems to be no organization of the content, and as things are centered by default understanding the structure of some pages can be pretty bothersome - instead of "letting your eyes do the work", you have to really think about what is where and try to solve the puzzle, as it were. Includes things like conveying semantics and relationships of elements through usage of visual elements, like usage of headings and the usage of those funny grey partially rounded boxes.
'''To have this as a guideline would require defining the various [[Page_structure_and_types#Page_types|page types]] of Moodle, so that different pages with the same sort of functionality could have some of the same visual characteristics. ''' (But I am not sure if this is the best approach overall, or would just designing screens individually for a start do us more good at this stage. --[[User:Olli Savolainen|Olli Savolainen]] 08:46, 10 August 2009 (UTC))
 
Whenever we attempt to make sense of information visually,
we first observe similarities and differences in what we are
seeing. These relationships allow us to not only distinguish
objects but to give them meaning. For example, a difference
in color implies two distinct objects (or different parts of
the same object), [...]
Once we have an understanding of the relationships between
elements, we can piece together the whole story and understand
what we are seeing. --[http://www.uie.com/articles/visible_narratives/ Visible Narratives]
One big issue is visual hierarchy of screens. Even if there is not much content on the screen, often there seems to be no organization of the content. As elements are centered by default, understanding the structure of some pages can be pretty bothersome. Instead of "letting your eyes do the work", you have to really think about what is where and try to solve the puzzle, as it were.  
 
Taking care of the design of visual hierarchy includes things like conveying semantics and relationships of elements through usage of visual elements, like usage of headings and the usage of those funny grey partially rounded boxes.


In a sense this should be a guideline but I really cannot think of much to say, except something could probably be extracted from the web: http://www.google.fi/search?q=usability+visual+hierarchy . Also, perhaps if we define certain page types several moodle pages would fit in then most pages would have some common factors. Then again, this also risks restricting design too much.
In a sense this should be a guideline but I really cannot think of much to say, except something could probably be extracted from the web: http://www.google.fi/search?q=usability+visual+hierarchy . Also, perhaps if we define certain page types several moodle pages would fit in then most pages would have some common factors. Then again, this also risks restricting design too much.
Line 25: Line 56:
There are lots of problematic UIs like this in Moodle, but to name just a few:
There are lots of problematic UIs like this in Moodle, but to name just a few:


* Chat
* Groups (managing the groups of a course and the users in them )
* Groups (managing the groups of a course and the users in them )


'''Note: This is not graphic design as such, but  usage of UI elements in a way that communicates their relationships clearly, facilitating users' preconscious scanning of the UI to make sense of it quickly: more information: [http://www.cofc.edu/~learning/visualhier.html] '''
'''Note: This is not graphic design as such, but  usage of UI elements in a way that communicates their relationships clearly, facilitating users' preconscious scanning of the UI to make sense of it quickly: more information: [http://www.cofc.edu/~learning/visualhier.html] '''
=== Related: create Moodle style of visual and a verbal expression ===
A higher abstraction level goal would be to give Moodle a consistent style in the way things are communicated. On a verbal level, this means emotional communication, i.e. it makes a difference if we tell the user
* "Error: Database communication failed (SQL: SELECT...)" or
* "''Well, this is embarrassing''... There seems to be a problem communicating with the database. Try again later, I bet we'll get this fixed soon enough!"
== Making Moodle more fluid with javascript/YUI controls/AJAX ==
Among others, converting dropdowns for adding items into YUI dialogs (quiz editing: add question / type selection vs. course: add activity module)
== The workflow of adding items ==
[[Add_element]]
The workflow of adding items such as activity modules in courses, questions in quizzes, posts in forums
== The roles system ==
Since Moodle has a specialized rights management system which does not naturally fit the domain knowledge of Moodle's users, there are two key approaches that could be taken:
* [http://moodle.org/mod/forum/discuss.php?d=129715 Improvement of the documentation to be less system-centric]]. Carefully thinking through the conceptual system (seemingly created as a byproduct of the roles system), and deciding what in it is the most fruitful in meeting actual user needs
* [http://www.pilpi.net/software/moodle/2009/06/16/finding-main-scenarios/ A central UI for taking control over the permissions/capabilities of an entire Moodle site], for seeing what is going on and the interdependencies of different roles and permissions. Currently this is scattered around Moodle and a holistic view is hard to gain.
http://tracker.moodle.org/browse/MDL-19659
== Forms: display of default values ==
See: http://tracker.moodle.org/browse/MDL-19659
== Course content editing ==
See: http://moodle.org/mod/forum/discuss.php?d=128436 and http://www.pilpi.net/software/moodle/2009/07/18/course-editing/
== Guidance ==
Moodle is an application that [[Pedagogy#Progression|can be used very superficially or very profoundly]]. Reportedly most users use Moodle as a content management system - something for posting stuff on the web. It is possible to build in guidance to the UI so that when users are ready to learn more about the capabilities of the software and the opportunities they  can grasp, they always know how to proceed. This is called guidance.

Latest revision as of 14:55, 27 May 2022


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


Moodle User Interface Guidelines > Major usability issues in Moodle

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.

This is a guideline template for a Moodle Interface Guideline. Comments: developer forum thread


Moodle UIs that have such serious flaws that in practice they require redesign.

User data always (Always) safe

See: User_Data_Always_Safe

This is the single most serious usability flaw in Moodle. It also requires some UI design work, and then a lot of software engineering work, to get right.

The user-to-user messaging system

This should be thought through together with the jabber messaging/notification/forum subscription system with a holistic approach.

  • Popups everywhere
  • Links point to unexpected locations
  • Getting trapped in a popup with the normal Moodle navigation
  • Designers open new browser windows (popups) on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user's machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don't notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button. http://www.useit.com/alertbox/990530.html http://www.humanfactors.com/downloads/keytips.asp

Ideas:

  • A frame on the right side of the screen for messaging?
    Page peel / backside of the page? Not covering the current page but something you can QUICKLY turn to and from which you can quickly turn back (big return control for turning the UI back to normal state)
  • Inbox/dashboard: A personal communications centre that keeps me up-to-date of all my moodle messaging: private messages,threads I have taken part in(replies to my message(s), replies to entire thread), threads I have started

Wizards

Processes in Moodle that resemble wizards should either be redesigned to be less sequential, or have all the elements that help users navigate, of wizards.

  • Installation
  • Backup
  • There is no proper navigation between the two steps/modes, and it is not even communicated explicitly what is the relationship between the two screens!
    • Two-step roles UIs (assign roles in course)
    • Two-step groups UIs (add users to groups in course: select group -> add users to group)
      • Lack of any visual hierarchy or distiction between navigation and commands
      • It is not communicated that some of the commands work on the selected item in the list.
      • Create group should be separate.
      • Add/remove users should be a link with the group name “Add remove users of group [groupname]”.

Visual hierarchy

To have this as a guideline would require defining the various page types of Moodle, so that different pages with the same sort of functionality could have some of the same visual characteristics. (But I am not sure if this is the best approach overall, or would just designing screens individually for a start do us more good at this stage. --Olli Savolainen 08:46, 10 August 2009 (UTC))

Whenever we attempt to make sense of information visually, 
we first observe similarities and differences in what we are 
seeing. These relationships allow us to not only distinguish 
objects but to give them meaning. For example, a difference 
in color implies two distinct objects (or different parts of 
the same object), [...]
Once we have an understanding of the relationships between 
elements, we can piece together the whole story and understand 
what we are seeing. --Visible Narratives

One big issue is visual hierarchy of screens. Even if there is not much content on the screen, often there seems to be no organization of the content. As elements are centered by default, understanding the structure of some pages can be pretty bothersome. Instead of "letting your eyes do the work", you have to really think about what is where and try to solve the puzzle, as it were.

Taking care of the design of visual hierarchy includes things like conveying semantics and relationships of elements through usage of visual elements, like usage of headings and the usage of those funny grey partially rounded boxes.

In a sense this should be a guideline but I really cannot think of much to say, except something could probably be extracted from the web: http://www.google.fi/search?q=usability+visual+hierarchy . Also, perhaps if we define certain page types several moodle pages would fit in then most pages would have some common factors. Then again, this also risks restricting design too much.

There are lots of problematic UIs like this in Moodle, but to name just a few:

  • Groups (managing the groups of a course and the users in them )

Note: This is not graphic design as such, but usage of UI elements in a way that communicates their relationships clearly, facilitating users' preconscious scanning of the UI to make sense of it quickly: more information: [1]


Related: create Moodle style of visual and a verbal expression

A higher abstraction level goal would be to give Moodle a consistent style in the way things are communicated. On a verbal level, this means emotional communication, i.e. it makes a difference if we tell the user

  • "Error: Database communication failed (SQL: SELECT...)" or
  • "Well, this is embarrassing... There seems to be a problem communicating with the database. Try again later, I bet we'll get this fixed soon enough!"

Making Moodle more fluid with javascript/YUI controls/AJAX

Among others, converting dropdowns for adding items into YUI dialogs (quiz editing: add question / type selection vs. course: add activity module)

The workflow of adding items

Add_element

The workflow of adding items such as activity modules in courses, questions in quizzes, posts in forums

The roles system

Since Moodle has a specialized rights management system which does not naturally fit the domain knowledge of Moodle's users, there are two key approaches that could be taken:

http://tracker.moodle.org/browse/MDL-19659

Forms: display of default values

See: http://tracker.moodle.org/browse/MDL-19659

Course content editing

See: http://moodle.org/mod/forum/discuss.php?d=128436 and http://www.pilpi.net/software/moodle/2009/07/18/course-editing/

Guidance

Moodle is an application that can be used very superficially or very profoundly. Reportedly most users use Moodle as a content management system - something for posting stuff on the web. It is possible to build in guidance to the UI so that when users are ready to learn more about the capabilities of the software and the opportunities they can grasp, they always know how to proceed. This is called guidance.