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

From MoodleDocs
Revision as of 22:16, 21 March 2009 by Olli Savolainen (talk | contribs) (New page: 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 p...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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, this shows. 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.

I also consider this an important learning experience about the whole of Moodle for myself.

The Ultimate Goal

Moodle is a web application. Web applications do not, in general, have strict consistency rules. However, Moodle is starting to be a big application. Different parts of it share similar interactions, and they should work similarly across different components, or modules.

The goal is thus to create a framework for developers to think about and document the user experience (UX) of Moodle. The knowledge of what has been verified – typically with usability testing – to work for users, needs to be available. A Human Interface Guideline (HIG) is one way of thinking about it. However, there is rigidity and vastness to a typical HIG that we want to avoid: it is paramount that what is documented is both easily accessible and maintainable.

Developers should be capable of searching the documentation for topics such as “selecting a group of users” or “opening a file” and find a concice explanation describing what the user experience should look like and possibly how to implement it.

Summer 2009: Practice and Outcomes

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.

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. Based on the usage scenarios and use cases of each component, necessary improvements will be made 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.

My competences

TODO.

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.