Note:

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

Quiz UI redesign - related use cases

From MoodleDocs
Revision as of 13:33, 17 July 2008 by Olli Savolainen (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Back to Quiz_UI_redesign

OBSOLETE, no estimate for updating set.

Below, I have briefly described the main related use cases, the issues currently associated with them and how the proposition[1] will solve those issues.

TODO: Make sure all of the scenarios are covered here. If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application. There may be branching or multiple ways to complete the task, and this is a good way to document it.

Various options are available to adjust the behaviour of the quiz and how the quiz is graded:. My proposition is however focused on improving the UI for building and managing the content in the actual quizzes.

Related use cases; the ones directly affected by this project are in bold:

  • User adds a plain question into a quiz
  • User adds a random question into a quiz
  • User organizes the content of a quiz into pages and sets the order of the questions
  • User managing their quiz (returning to edit content)
  • User sets the grades for individual questions and the quiz
  • User adds questions from the question bank to the quiz
  • User configures the quiz-wide options
  • User manages their questions outside the context of the original quiz
  • User imports questions into a category

The problems with the old UI are mostly related to the internal conceptual model of Quiz, which does not correspond with the model of users coming from the world of pen and paper exams.

Novice users’ model: The main entity is the quiz/exam itself and that is what the user is prepared to manipulate.

In Quiz’ current model, questions are first created into a question category, from where they can then be added into a quiz. The benefit from this is that users are forced to organize their questions in categories, thus assumably staying organized at all times. The reality is however, that since the old UI doesn’t correctly communicate the conceptual model it uses, novices get lost in it, and are likely to try to cut corners to just get their questions into the quiz itself as quickly as possible.

Use case 1: User adds a plain question into a quiz

In the old UI, It is impossible to add a question directly in the quiz and thus the novice user’s expectations are not met.

If completely unguided, a less dedicated user may give up before having both created a question into a category and adding that question from the category to the actual quiz. However, with some instruction the user may be capable of adding “plain” questions into their quiz, since all of the controls required for the task are in fact visible in somewhere in the single Quiz -> Edit screen.

In the new UI, the process is as follows (starting point: the user is in the quiz editing view):

  • The user selects the type of the question to create and presses 'Create'.
  • The user fills out the form corresponding to the question type in question. (Note that the usability of the actual question forms are beyond the scope of this project.)
  • The user is returned to the quiz editing view they came from and can immediately see the results and the contents of the question they entered.

Use case 2: User adds a random question into a quiz

Since there is no perfect equivalent for a “random question” in the world of pen & paper exams, the user needs some introduction to the concept itself, and this is not purely a problem solvable by making the UI suitable for the task. In both the old and the models, users need to realize how random questions work: one question of the ones provided for the random question will be selected each time a student attempts the quiz in question.

However, the old UI focuses more on its own conceptual model than on the actual content: only the names of questions and none of the actual question content are shown in the quiz editing view. The process of adding a random question and confirming the action has been successful in the old UI is as follows:

  • Create a new question category
  • Add the questions, from which to select a question, to the category
  • Add the category as a random question to the quiz.
  • Preview the quiz

Concrete results can be confirmed by the user only when they preview the exam, and even then they can only confirm that one of the questions, which they added, is in fact showing in the exam. Confirming that what they see in the preview is not an instance of just that single question, is a more complicated task, which involves finding out the actual question category a random question is related, and then navigating in the question bank to see the contents of that category.

The improvements are most clearly visible in this use case, as the UI now focuses on the content the user is manipulating, instead of the application’s internal structure. Instead of having to understand the whole conceptual system of question bank containing categories (containing questions) from which a random question can be generated, the user simply adds a random question directly into the quiz. The necessary question category for the random question is created in the background, and is viewable by the user if they later need to.

In the proposed UI, the user’s process is as follows:

  • The user adds a ‘random question’ to the quiz
  • The user adds new questions to the random question
  • The contents of the random question are shown directly in the editing view and thus using the preview or doing anything else is no longer necessary.

A process already familiar to users from pen & paper exams is used, and thus the user can accomplish their task without extra training.

Use case 3: User organizes the content of a quiz into pages and sets the order of the questions

Problems related to this use case are simpler in nature and though they are separate from the main conceptual confusion, which most of the work aims to solve, they are still closely related and need to be solved in order to clear up room from the actual quiz content management screen for that task.

In the old UI, the user may control the pagination and the order of the questions after toggling a mode intended for either of the tasks. Toggling the mode is done by clicking an nonstandard implementation of a check box, which brings up related controls into the same view, adding complexity of the UI.

In the new UI, the mode is still there, but moved into a separate tab. In addition, whereas in the old UI the user had to move the questions one by one, refreshing the page at every step, in the new UI users can use either drag and drop or simply type the desired position of a question in its textbox.

Use case 4: User managing their quiz (returning to edit content)

In the old Quiz UI, an user had to go through several screens to find out what is the actual content in their quiz. Thus managing a quiz, possibly a long time after creating it, became troublesome, since it was not easy to see what the actual content of a quiz is in the quiz editing screen.

As the new UI concentrates on the actual quiz content more than the old one and displays more of the actual question content, it reduces strain on the user's memory. Thus, if a user returns to a quiz they've made, they instantly see what is in the quiz and can operate on it directly.

Use case 5: User sets the grades for individual questions and the quiz

The user interface for this use case has been left largely unmodified, supporting what users have gotten accustomed to in the old UI. The text fields are in the quiz editing view like they used to be in the old UI.

Use case 6: Adding questions from the question bank to the quiz

These use cases will most likely not be addressed during Kesäkoodi. In other words, I will first focus on making an UI that enables creating a quiz from scratch. In the future this can be extended to include a hideable palette for the question bank, from which to add already existing questions to the quiz. This is the main feature required, before the new UI can replace the old one in Moodle.

Use cases 7, 8, and 9: User configures the quiz-wide options, User manages their questions outside the context of the original quiz, User imports questions from a file into a category

This use case is not specifically catered for during Kesäkoodi 2008, but for future development, and before being able to replace the old Quiz UI, it has to be ensured that the overall UI of Quiz is also pruned to correctly express the relationships between the concepts, mainly between quizzes and the question bank categories.