3. Summary of solutions

See also: Presentation about the core ideas (ODT Impress 202kb)

Intro | Basic issues | Solutions


Below, I’m presenting the major changes in the UI model, and the reasoning behind them. In addition, there are several less critical problems, which require less fundamental changes to the UI. An example of this are the navigational tabs. In the current UI they behave in a non-standard manner, to the degree that novice users easily lose sight of where they are, or how they can get where they want using the navigation. This isn’t the primary focus of my work but will eventually be tackled in phase four of the project.

Problem: The main quiz editing screen (Edit -> Quiz) has three separate functionalities (category content management, quiz content management, quiz reordering/organizing), confusing users since the UI does not communicate what users are supposed to use it for.
Solution: Separate the functionality so that the user can concentrate on one task at a time. Do not overload the user’s cognitive space with unnecessary information for a given task. Category content management already has its own screen and thus the functionality can be removed from the Quiz content management screen. Reordering/organizing the content of the quiz is a central use case to managing a quiz, but since switching from and to is the reordering already a mode (triggered by a checkbox) in the old UI, we make that mode explicit by creating a separate, specially designed tab for managing the order and paging of the quiz.
Problem: In the main quiz editing screen, users are often unaware of the actual content of questions in the quiz or in the categories since they are not visible. They only see the question names. Alas, users are often unable to make the decisions they are in the screen for. It is not obvious for a novice, how to find out which question is where in the quiz.
Solution: Quiz content (the actual questions) is central to the task of creating or managing a quiz and this information needs to be readily available for that task. As we have above freed screen estate by moving unrelated functionality into screens of their own, we can fully concentrate on the quiz content in the main quiz editing screen. Also the content in the categories can be expanded at user request, for example using AJAX.

The core idea is thus dividing the UI into three simpler, separate parts, each having their own, clear function. Some concepts, such as a “random question” are fundamental to electronic exams, and as such possibly foreign to a novice user, so we provide quick help in the quiz editing screen explaining the concepts.

See also: diagram (PNG image 189 kb), the original UI design document

Challenges

If Jakob’s Law is “users spend most of their time on other websites,” then Jakob’s Second Law is even more critical: “Users have several thousand times more experience with standard GUI controls than with any individual new design.” - Jakob Nielsen in his Alertbox column

As a developer for several web application UIs before Moodle, I try to stay sensitive for what most users are already accustomed to in most web UIs. This is to keep users’ learning curve minimal. However, as Moodle also has its own practices (documented or not), some of my initially proposed solutions may clash with Moodle’s current conventions. I plan to take the new UI as close as possible to Moodle’s existing standards without sacrificing usability. I do not see this as a showstopper: now that recent versions of Moodle even have YUI AJAX library included, I expect the current UI practices to be flexible enough. If there still are contradictions, I will listen to the community’s input.

During the discussions about the UI we have had at the developer forums, we discovered that there actually are two major use cases, with different ways of accessing the same functionality:

  1. One of them involves importing all the questions of a quiz, in batch, from an external file created in some other application. The Quiz module’s UI is used mainly for management of the quiz - this is more applicable for quizzes that contain lots of multiple choice questions (quantitative testing). For this, the usability problems of the current UI aren’t as critical, since the web UI is used less extensively used.
  2. The other major use case is creating an exam from scratch using the web UI - this is especially needed for creating essay type exams (qualitative testing). These exams have relatively fewer questions than what is needed in quantitative testing. The process consists of mainly creating questions, placing them in categories, and adding them into the quiz, as well as tweaking several options to adjust the overall behaviour of the quiz. It is critical that the user has the information available needed at each stage of the process - no more, to avoid confusion - and no less, to avoid having to skip around different screens to find the information needed at some stage.

However, as the changes required to enable the latter major use case involve major changes in the UI model, it has to be made sure that the new UI still supports also the former major use case. Before getting feedback from the community about a functional prototype it is impossible to know for sure, but as far as I know the major use cases, my current proposition supports both of the major use cases fluently. As verified in paper prototype tests, it supports the latter one dramatically better than the old UI.

An additional challenge is to keep the user interface from cluttering up as new features arise. The current plan does not yet take into account the Roles system introduced in Moodle 1.7, for example. I consider the challenge an interesting one, and compared to the old UI significant progress to unclutter the UI has already been made.