Note:

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

Usability/Improve Moodle User Experience Consistency/Detailed project plan: Difference between revisions

From MoodleDocs
mNo edit summary
mNo edit summary
Line 28: Line 28:
Which parts of the project can be delegated in as early a phase in the project as possible?
Which parts of the project can be delegated in as early a phase in the project as possible?


== Examine/prioritise of different components (week 23) ==
== Examine/prioritise different components (week 23) ==
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.  
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.  



Revision as of 13:49, 26 May 2009

Development-Usability Improve Moodle User Experience Consistency Detailed project plan.png

(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.

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 viable way/mode/phase of involvement/usage of the HIG 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 HIG 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)

Planning (week 22)

Determine the different phases of the project and keep track of relevant information related to each phase (this document). 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?

Examine/prioritise different components (week 23)

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?).

Navigation 2.0: which interaction styles and elements are introduced (week 25)

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 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 HIG

Also, determine the relationship of the new guidelines to https://docs.moodle.org/en/Development:Interface_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
  • 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.


Usability testing with prototypes (week 30)

Implement of the most important changes (week 32)