Usability/Improve Moodle User Experience Consistency: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 13: | Line 13: | ||
=== Catalogue of interaction styles === | === Catalogue of interaction styles === | ||
=== Later: Documented user descriptions and scenarios === | === Later: Documented user descriptions and scenarios === | ||
| Line 23: | Line 20: | ||
The basic requirement of usability work is to "Know Your Users". This knowledge is often expressed in terms of Personas, scenarios and use cases. Some work was done in the Quiz UI Redesign project but the format this was communicated was not sufficiently easy to access. 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. | The basic requirement of usability work is to "Know Your Users". This knowledge is often expressed in terms of Personas, scenarios and use cases. Some work was done in the Quiz UI Redesign project but the format this was communicated was not sufficiently easy to access. 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. | ||
== Summer 2009: | == 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. | |||
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. | 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. | ||
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. To facilitate usability testing, the intended use of the main core modules will be studied. | 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. To facilitate usability testing, 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 to build on. | ||
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 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. | |||
# | === Outcomes === | ||
# | # Catalog the current interaction styles(patterns) and elements (HIG style) in a manageable way (rather links to examples and screenshots than lengthy explanations) | ||
# Define what to do in a given situation where the app does X and needs to communicate Y to the user? | |||
# Secondary: find and gather typical use cases of core UIs/modules | |||
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. | === Challenges === | ||
The main 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. | |||
== My competences == | == My competences == | ||
In Summer 2008 I implemented Quiz editing UI. Interviews, testing, community discussions. Included in HEAD. | In Summer 2008 I implemented Quiz editing UI. Interviews, testing, community discussions. Included in HEAD. | ||
Describe studies (Interactive Technology) and work experience (usability, previous work with Moodle in University of Tampere, PHP, HTML, CSS) briefly. | Describe studies (Interactive Technology) and work experience (usability, previous work with Moodle in University of Tampere, PHP, HTML, CSS) briefly. | ||
Revision as of 19:46, 23 March 2009
Google Summer of Code 2009 Olli Savolainen
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 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.
The Ultimate Goals
Catalogue of interaction styles
Later: Documented user descriptions and scenarios
The cornerstone of usability and UX is knowing the 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.
The basic requirement of usability work is to "Know Your Users". This knowledge is often expressed in terms of Personas, scenarios and use cases. Some work was done in the Quiz UI Redesign project but the format this was communicated was not sufficiently easy to access. 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.
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.
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.
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. To facilitate usability testing, 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 to build on.
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 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.
Outcomes
- Catalog the current interaction styles(patterns) and elements (HIG style) in a manageable way (rather links to examples and screenshots than lengthy explanations)
- Define what to do in a given situation where the app does X and needs to communicate Y to the user?
- Secondary: find and gather typical use cases of core UIs/modules
Challenges
The main 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.
My competences
In Summer 2008 I implemented Quiz editing UI. Interviews, testing, community discussions. Included in HEAD.
Describe studies (Interactive Technology) and work experience (usability, previous work with Moodle in University of Tampere, PHP, HTML, CSS) briefly.
