Development:Usability/Improve Moodle User Experience Consistency/Detailed project plan
Parent page:Usability > Improve Moodle User Experience Consistency
See also: The higher-level dimensions (goals) of this project in the project blog.
Goal of this document: comprehensiveness, in order to ensure that we take into account everything that needs to be taken into account while designing the guidelines and their format. The primary goal of this document is not, contrary to the guidelines themselves, to be optimized for an easy/light read.
(Chart created in OpenOffice.org with the help of this tip: Charting: Creating a Gantt chart. Not the ideal UI for this, but worked swell after figuring out what in the OOo UI has changed since the tip was written.)
Community discussion; learning about developer conventions (constant)
Throughout the whole project, I will look for ways for usability people to communicate with various groups of developers.
Involving developers
The main objective is to understand the processes developers go through when planning, designing and implementing UIs: to plug into the phases of the work where usability considerations would be fruitful. Ask everybody (in one form or another): What is a appropriate way/mode/phase of involvement/usage of the guidelines for you? In what way would you think that User Experience (UX) design and development would ideally cooperate?
How to ideally have this discussion?
Also helping developers understand the special nature of usability work and its relationship to development processes will help developers take use of both the guidelines of this project and the services usability practitioners can provide.
- Take part in Moodle developer course in dev.moodle.org
Involve developers to take part as soon as possible. (See http://moodle.org/mod/forum/discuss.php?d=119507 for Thomas Hanley's willingness to cooperate.) For each module, let the ones responsible for different parts of moodle:
- document which of the elements listed in the guidelines are included in the module/part of moodle they are responsible for?
- Document the preferred way to implement the interaction in question in Moodle (some of these ideals could be presented as an API)
Involving other stakeholders
How to involve other stakeholders, such as other usability practitioners? Thomas Hanley has expressed his interest for a framework for evaluating user interfaces, that any usability practitioner or a developer (?) could use to help complete the guidelines, since it is obvious that in one summer I will not catalogue all of Moodle. Though the goal is to gather only the interaction styles that are common to various parts of Moodle, there is still a lot of work.
Planning (week 22)
Determine the different phases of the project and keep track of relevant information related to each phase (this document). Narrow down target audiences and types of documents to create. Define terminology for the project:
- Usability practitioner vs. UX professional etc.
- Human Interface Guidelines vs. UI guidelines vs. UI patterns etc.
What should be communicated throughout the project about the project status?
Which parts of the project can be delegated in as early a phase in the project as possible?
Start gathering a sketch of a guidelines document, but make it clear it is a sketch: Something very simple that people can comment on already at this stage. (Thanks, Helen for the idea.)
TODO:
- consider studying the existing guidelines earlier than currently planned, so that developers and all of the community could have something to comment on as soon as possible.
- Read through discussion with Helen on May 26th.
- Respond to any unfinished discussions in forums, noted in task management/gtd
- Make the entire process lighter, lighter, lighter, and transparent.
Examine/prioritise different components (week 23)
There are a lot of UIs and intricate functionality in Moodle that I simply do not know yet. Like in the Drupal 7 UX project it was for Leisa and Mark, this can be a benefit for me as a usability practitioner: I have a fresh pair of eyes to look at things with. However, it is still an additional workload: I really need to narrow down what is relevant for this project, at this point in time of the Moodle community's development towards usability issues.
Go through Moodle in a variety of ways. Take Moodle courses, read Moodle books, use modules like the book writers think I should be using them.
Priority on the use cases of teachers and students and less on those of admins. Further determine based on https://docs.moodle.org/en/Pedagogy#Progression and observations of the modules/course views themselves (https://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency#UIs_to_examine), and on discussions with various stakeholders (Community/teachers? Tim Hunt? Helen Foster?).
Strive to understand the goals of the Navigation 2.0 project. Derive the new interaction styles and elements interaction styles introduced by the project into the documentation. Further reflect on the relationship of such projects that affect the entire Moodle UI and UI guidelines.
Examine pattern libraries and guidelines for content and information architecture (week 26)
https://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency#HIGs (Especially determine the current relationship to Fluid)
Go through different HIGs (domain term: Human Interface Guidelines) and pattern libraries with two goals in mind:
- Determine the information architecture (IA) used in each HIG (the way the guidelines/patterns are organized and the way information is organized within the patterns);
- Compare different IAs and discuss with community which aspects would be optimal for Moodle. Also find out with what different categories/kinds of tags (taxonomies) should be created for each element, to be searchable.
- Find relevant recommendations for inclusion also in the Moodle guidelines
Also, determine the relationship of the new guidelines to Development:Interface_guidelines. That name is actually appropriate for the current contents of that page, dealing mostly with the ways to implement certain aspects of UIs. But comparing usability work to interface (i.e. API) design is comparing apples to oranges - at a minimum, the commonly-known term User Interface, though still misleading, should be used?
- Current content as a subpage of the new guidelines
- Current content merged into the implementation instructions (of specific interaction styles/elements, and of more general usability guidelines)
Catalogue high-level UI elements, interaction styles, preliminary use case descriptions (week 26)
Based on the work done in previous phases, create the first iteration of the guidelines in Moodle Docs. Document core use cases to be used in usability testing. If I have mental space left, compare UIs to UI heuristics (http://www.useit.com/papers/heuristic/heuristic_list.html).
A preliminary list of styles to include: https://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency#Interaction_styles.2Felements_to_examine
Joel on software http://www.joelonsoftware.com/articles/fog0000000036.html gives plenty of useful advice about writing readably.
Study MediaWiki and use its templating etc. systems to enable tagging each element on multiple dimensions.
Goals (to be considered):
- Relatively high-level rules, instead of too constraining rules. Or should the rules be exact to make it really straightforward to follow them (potentially to the UIs doom if done too literally)? Discuss this with the community with examples.
- lightness: searchability, tagged according to various taxonomies
- simple language: usability and UI (User Interface) are generally understood terms amongst developers, I suppose. (Consider having a section (or a link to somewhere else) that explains the various terms used: Human-Computer Interaction, HIG, User Experience (UX), Information Architecture (IA), ... but then, this is not really relevant for the goals of this project.)
- links to examples of each interaction style or element (links to screenshots or a to a demo of Moodle that remains on a specified version?)
- Links to: controls that selve the same purpose better; controls that should be replaced with this;controls with a similar purpose for a different context?
- Use cases: 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. Required for usability testing. Related: I wonder what is the status of this https://docs.moodle.org/en/Talk:Developer_meeting_September_2008
- 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.
- Index of the current screen types, interaction styles and elements, with their intended uses.
- The most standard i.e. common and mundane tasks need to be the most easy-to-find, keeping at least them standard across Moodle.
- Screen types: Course pages, functional pages, content pages, settings pages?
- index of usage information for different parts of moodle (index that which is hidden in chapters of design documents)?
Determining and prioritizing delta between guidelines and current Moodle (week 28)
Figure out the level of consistency in Moodle 2.0 HEAD. Find similar functionality with similar UIs. Document all occurences of different interaction styles/elements which were documented in step 6, and if necessary, create new entries in the guidelines. Create tickets in the tracker for consistency issues.
Planning usability testing; implementation of prototypes (week 29)
Determine the principal changes to be proposed to the community.
Determine a suitable public venue or an educational institution to get test subjects from.
Write test tasks for usability tests.
