Note:

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

Quiz UI redesign - Design specification: Difference between revisions

From MoodleDocs
No edit summary
 
(43 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Back to [[Quiz_UI_redesign]]
Back to [[Quiz_UI_redesign]]


'''I will let the mockups speak for themselves :)'''
==The  user interface of Quiz for creating and managing quizzes ==
'''[[Image:quiz-ui-redesign_2008-prototype-1.png|thumb|100px|right| [https://docs.moodle.org/en/images_en/b/b8/quiz-ui-redesign_2008-prototype-1.png Question bank closed] ]]'''
'''[[Image:quiz-ui-redesign_2008-prototype-2qbank.png|thumb|100px|right| [https://docs.moodle.org/en/images_en/1/17/quiz-ui-redesign_2008-prototype-2qbank.png Question bank open] ]]'''
'''I will let the mockups speak for themselves :).''' They were made with Openoffice.Org Impress to mimic, in the [[Quiz_UI_redesign#Prototype_testing|prototype tests]],  the behaviour of the actual application. '''Please comment on anything found here in the [http://moodle.org/mod/forum/discuss.php?d=100367 quiz forum thread]'''
* '''[https://docs.moodle.org/en/images_en/b/b8/quiz-ui-redesign_2008-prototype-1.png Question bank closed]'''
* '''[https://docs.moodle.org/en/images_en/1/17/quiz-ui-redesign_2008-prototype-2qbank.png Question bank open]'''
* [[Quiz_UI_redesign - Help text: Basic ideas of creating quizzes|Help text: Basic ideas of quiz creating]]
* The reordering tool was tested in a previous iteration (https://docs.moodle.org/en/Image:NewQuizUI-Order.png), but has not been included in the new one yet. It is planned that it will be similar to that , but futher accommodation to this iteration of the UI will follow.
* For further details, see the tested [https://docs.moodle.org/en/Development:Quiz_UI_redesign#Prototype_testing Openoffice.org Impress prototype] (unfortunately only in Finnish, but since most information is graphical, it may serve a purpose for non-Finnish-speaking users, too)


* '''[https://docs.moodle.org/en/images_en/b/b8/quiz-ui-redesign_2008-prototype-1.png Question bank closed]'''
----
* '''[https://docs.moodle.org/en/images_en/1/17/quiz-ui-redesign_2008-prototype-2qbank.png Question bank open]
 
'''
'''Some notes about the prototype:'''
** When the user hovers over a question, a tooltip-style box shows that describes in more detail all the relevant information about that question.
** Although this is not visible in the mockup, the random question specifies the question type of its questions on the bottom line "Total of 3 questions" -> "Total of 3 essay questions and 2 multiple choice questions"
** Selecting the edit icon or the title link of  random question opens that random question's category in the question bank window on the right.
** The user interface uses dialogs extensively. These will have to be implemented using greybox/dialog with graceful degradation to a separate dialog page. http://developer.yahoo.com/yui/examples/container/dialog-quickstart.html
* Notify the user in the editing UI
** If there are too few questions in a category for the amount of random questions in the quiz from that category - a more subtle warning if it is close or if there is only one question for one random question
** If the user is about to leave the view with nonfunctional questions in the quiz (for example, too few questions in random question category)
** Subtle: If a random question category contains different types of questions?
* Tooltips for all elements which do not have labels


== Background ==
== Background ==


In the end, I decided to take rather more of a conservative approach with the presentation of random questions, compared to the original prototype. That is, random questions are not edited in-place in the quiz, but instead a quick link is provided to display the questions in the question bank window.
In the end, I decided to take rather more of a conservative approach with the presentation of random questions, compared to the [[Quiz_UI_redesign_prototype|original prototype]]. That is, random questions are not edited in-place in the quiz, but instead a quick link is provided to display the questions in the question bank window.
* The actual prototype to add a random question from the page tab does not handle this way. It is use to create a category !!! [[User:Pierre Pichet|Pierre Pichet]] 22:00, 12 October 2008 (CDT)
** I am afraid there is a misunderstanding here, you are talking about different functionality than this point in the spec. This point discusses editing of a random question that is already in a quiz. In contrast, you are talking about creating random questions. Creating a fresh, new random question effectively means creating a new category and adding a random question from that. This is to give progressive disclosure to especially more novice users. Adding random questions from existing categories works just like it used to, using the question bank window. If the edit tab is too verbose for you, you can always use the reorder/paging tab which contains roughly the same things as the old edit tab, and is more compact than the edit tab. The reasoning behind all this is at [[Quiz_UI_redesign_prototype_presumptions]]. This is just a quick reply, I will go deeper into your recent comments in the forums as soon as I get a chance. --[[User:Olli Savolainen|Olli Savolainen]] 10:55, 13 October 2008 (CDT)


The main reason for this conclusion was the fact that with in-place editing of even random questions, there was no  way of communicating the relationship for multiple random questions from the same category in a quiz. That is, it would not be obvious enough to the user, whether or not when they edited something in a random question, the other random question would also change.  
The main reason for this conclusion was the fact that with in-place editing of even random questions, there was no  way of communicating the relationship for multiple random questions from the same category in a quiz. That is, it would not be obvious enough to the user, whether or not when they edited something in a random question, the other random question would also change.  


I am not completely satisfied with all the choices. Namely, there is still too much clutter, especially in the question bank window. Nevertheless, I decided that concistency with the old interface is important to the degree that all the old functionality should be preserved. There are two exceptions to this. Deleting questions, as well as moving question to another context or another category, have been removed in the exam view, since these are not directly related to exam editing, but are question bank operations.
I am not completely satisfied with it yet, and it will most likely develop further during the actual coding. Namely, there is still too much clutter, especially in the question bank window. Nevertheless, I decided that concistency with the old interface is important to the degree that all the old functionality should be preserved. There are two exceptions to this. Deleting questions, as well as moving question to another context or another category, have been removed in the exam view, since these are not directly related to exam editing, but are question bank operations.


This also will mean that the question bank view of the exam editing screen is separated from the independent question bank editing screen. In terms of communicating the information structures of the application to the user, I see this as a positive thing. While we preserve the functionality of the question bank that is needed when editing a quiz, we still use a minimal question bank contents -'''window''' that communicates the fact that the question bank is not an equal citizen when editing a quiz but a tool - albeit an important one - used for building the quiz. This is a clear enhancement compared to the old Quiz UI.
This also will mean that in terms of programming/architecture design, the question bank view of the exam editing screen is separated from the independent question bank editing screen. In terms of communicating the information structures of the application to the user, I see this as a positive thing. While we preserve the functionality of the question bank that is needed when editing a quiz, we still use a minimal question bank contents -'''window''' that communicates the fact that the question bank is not an equal citizen when editing a quiz but a tool - albeit an important one - used for building the quiz. This is a clear enhancement compared to the old Quiz UI.


The design decision of whether or not to allow more direct, in-place editing of single question right in the quiz was a hard one. However, I did not see direct editing a crucial feature of the user interface, although it would make the interaction more seamless. Since it would introduce another mode in the UI and
The design decision of whether or not to allow more direct, in-place editing of single question right in the quiz was a hard one. However, I did not see direct editing a crucial feature of the user interface, although it would make the interaction more seamless. Since it would introduce another mode in the UI and
would potentially make editing of single questions inconsistent with editing random questions, I dropped that plan at this point. It will be however, if seen beneficial enough, straightforward to add it at a later point.
would potentially make editing of single questions inconsistent with editing random questions, I dropped that plan at this point. It will be however, if seen beneficial enough, straightforward to add it at a later point. [http://fluidproject.org/index.php/downloads#_features Fluid seems to allow this: # Allow users to edit content within the context of their work - try it out?]


=== Roles ===
For all parts of Moodle, including Quiz, the UI for roles, and how to communicate the effects of existing roles and possibilities of roles that can be created, still remains a challenge. However, I believe that the new Quiz UI can be built to communicate the hopefully forthcoming innovative UI thinking about roles.


== Work based on prototype testing ==
== Work based on prototype testing ==
You can view the discovered issues, based on which UI conclusions were made, here: [[Quiz_UI_redesign_-_prototype_testing_report]]
You can view the discovered issues, based on which UI conclusions were made, here: [[Quiz_UI_redesign_-_prototype_testing_report]]


== Work based on scenarios ==


The scenarios that were gathered during April and May have been taken into account in the new user interface to the extent I saw applicable. However, most of it turned out to be higher-level understanding that would onl be applicable after the functional requirement specs of the software were first changed; an excellent example of this is the various needs of different levels of metadata various users showed.  
== Tabs ==
 
The subtabs of the edit tab were dropped. This was seen absolutely necessary since that was the single biggest factor causing users confusion about the conceptual system of quiz. That is: All but the edit quiz tab itself were unrelated to editing quiz. The implication in the old UI is that the question bank is subordinate to the current quiz, and this is in direct contradiction with the actual conceptual system. For example, the "Questions" tab under "Edit" tells the user that the quiz's questions are here - before s/he learns that the tab contains something else than its title communicates, namely the question bank's questions. Links were added above the tabs to the related parts of the question bank.
 
The order of the tabs was untested, but I have seen people struggle with it. However, it was not changed before some concrete testing results show up, allowing to think about /how/ it should be changed. Facilitating the order of a most-often workflow of a user (create exam -> set order -> info (+ edit info) -> preview -> grade ) probably would not be a bad idea, but so far it is just guesses.  


The status bar is one important addition I made which was supported by the scenarios interviews. It turned out that when a teacher creates exams/quizzes, it is for many a task that requires rather intense concentration. On the other hand, it also became clear that today's teaching world does not make it very easy for teachers to isolate long periods of concentrating just on quiz/exam creating.  
Also related to tabs, one of the test subjects had visible problems recognizing which tab is active, and s/he was frustrated since in the prototype it was impossible to swicth between tabs to find out. This is why in the prototypes, the background colour of the active tab is clear white, like the background of the rest of the page, and the backgrounds of the other tabs have been made significantly darker.


Thus, the UI should support the teacher's memory: '''when''' a teacher gets interrupted, it should be as easy as possible to continue where they left of. That is, it needs to be visible at a glance what the exam's/quiz's current status is, and showing at least whether the exam is open and if not, when it will be (ans possibly, when it will close) is the bare minimum to reach for this. Ideas about what else might be wise to show in the status display, are welcomed.
== Work based on scenarios ==


What is interesting about the OOo-prototype tests is that although the instructions gave the users the idea that they need to create the questions into a category first and then add that category as a random question into an exam, all of them  successfully created a random question with the "create random question" button.
See [[Quiz_UI_redesign_scenarios_-_conclusions]].


== Implementation ==
== Implementation ==


The dialogs require a greybox-style dialog. This amount of modality is widely accepted as the best way to do modal dialogs on the web, since they do not lock the entire browser window. Without javascript, the same dialog can be used as a new page, which, when submitted, is returned to the page from which the modal dialog was launched.
The dialogs require a greybox-style dialog. This amount of modality is widely accepted as the best way to do modal dialogs on the web, since they do not lock the entire browser window. Without javascript, the same dialog can be used as a new page, which, when submitted, is returned to the page from which the modal dialog was launched.
[[Category:Usability]]

Latest revision as of 15:55, 13 October 2008

Back to Quiz_UI_redesign

The user interface of Quiz for creating and managing quizzes

I will let the mockups speak for themselves :). They were made with Openoffice.Org Impress to mimic, in the prototype tests, the behaviour of the actual application. Please comment on anything found here in the quiz forum thread


Some notes about the prototype:

    • When the user hovers over a question, a tooltip-style box shows that describes in more detail all the relevant information about that question.
    • Although this is not visible in the mockup, the random question specifies the question type of its questions on the bottom line "Total of 3 questions" -> "Total of 3 essay questions and 2 multiple choice questions"
    • Selecting the edit icon or the title link of random question opens that random question's category in the question bank window on the right.
    • The user interface uses dialogs extensively. These will have to be implemented using greybox/dialog with graceful degradation to a separate dialog page. http://developer.yahoo.com/yui/examples/container/dialog-quickstart.html
  • Notify the user in the editing UI
    • If there are too few questions in a category for the amount of random questions in the quiz from that category - a more subtle warning if it is close or if there is only one question for one random question
    • If the user is about to leave the view with nonfunctional questions in the quiz (for example, too few questions in random question category)
    • Subtle: If a random question category contains different types of questions?
  • Tooltips for all elements which do not have labels

Background

In the end, I decided to take rather more of a conservative approach with the presentation of random questions, compared to the original prototype. That is, random questions are not edited in-place in the quiz, but instead a quick link is provided to display the questions in the question bank window.

  • The actual prototype to add a random question from the page tab does not handle this way. It is use to create a category !!! Pierre Pichet 22:00, 12 October 2008 (CDT)
    • I am afraid there is a misunderstanding here, you are talking about different functionality than this point in the spec. This point discusses editing of a random question that is already in a quiz. In contrast, you are talking about creating random questions. Creating a fresh, new random question effectively means creating a new category and adding a random question from that. This is to give progressive disclosure to especially more novice users. Adding random questions from existing categories works just like it used to, using the question bank window. If the edit tab is too verbose for you, you can always use the reorder/paging tab which contains roughly the same things as the old edit tab, and is more compact than the edit tab. The reasoning behind all this is at Quiz_UI_redesign_prototype_presumptions. This is just a quick reply, I will go deeper into your recent comments in the forums as soon as I get a chance. --Olli Savolainen 10:55, 13 October 2008 (CDT)

The main reason for this conclusion was the fact that with in-place editing of even random questions, there was no way of communicating the relationship for multiple random questions from the same category in a quiz. That is, it would not be obvious enough to the user, whether or not when they edited something in a random question, the other random question would also change.

I am not completely satisfied with it yet, and it will most likely develop further during the actual coding. Namely, there is still too much clutter, especially in the question bank window. Nevertheless, I decided that concistency with the old interface is important to the degree that all the old functionality should be preserved. There are two exceptions to this. Deleting questions, as well as moving question to another context or another category, have been removed in the exam view, since these are not directly related to exam editing, but are question bank operations.

This also will mean that in terms of programming/architecture design, the question bank view of the exam editing screen is separated from the independent question bank editing screen. In terms of communicating the information structures of the application to the user, I see this as a positive thing. While we preserve the functionality of the question bank that is needed when editing a quiz, we still use a minimal question bank contents -window that communicates the fact that the question bank is not an equal citizen when editing a quiz but a tool - albeit an important one - used for building the quiz. This is a clear enhancement compared to the old Quiz UI.

The design decision of whether or not to allow more direct, in-place editing of single question right in the quiz was a hard one. However, I did not see direct editing a crucial feature of the user interface, although it would make the interaction more seamless. Since it would introduce another mode in the UI and would potentially make editing of single questions inconsistent with editing random questions, I dropped that plan at this point. It will be however, if seen beneficial enough, straightforward to add it at a later point. Fluid seems to allow this: # Allow users to edit content within the context of their work - try it out?

Roles

For all parts of Moodle, including Quiz, the UI for roles, and how to communicate the effects of existing roles and possibilities of roles that can be created, still remains a challenge. However, I believe that the new Quiz UI can be built to communicate the hopefully forthcoming innovative UI thinking about roles.

Work based on prototype testing

You can view the discovered issues, based on which UI conclusions were made, here: Quiz_UI_redesign_-_prototype_testing_report


Tabs

The subtabs of the edit tab were dropped. This was seen absolutely necessary since that was the single biggest factor causing users confusion about the conceptual system of quiz. That is: All but the edit quiz tab itself were unrelated to editing quiz. The implication in the old UI is that the question bank is subordinate to the current quiz, and this is in direct contradiction with the actual conceptual system. For example, the "Questions" tab under "Edit" tells the user that the quiz's questions are here - before s/he learns that the tab contains something else than its title communicates, namely the question bank's questions. Links were added above the tabs to the related parts of the question bank.

The order of the tabs was untested, but I have seen people struggle with it. However, it was not changed before some concrete testing results show up, allowing to think about /how/ it should be changed. Facilitating the order of a most-often workflow of a user (create exam -> set order -> info (+ edit info) -> preview -> grade ) probably would not be a bad idea, but so far it is just guesses.

Also related to tabs, one of the test subjects had visible problems recognizing which tab is active, and s/he was frustrated since in the prototype it was impossible to swicth between tabs to find out. This is why in the prototypes, the background colour of the active tab is clear white, like the background of the rest of the page, and the backgrounds of the other tabs have been made significantly darker.

Work based on scenarios

See Quiz_UI_redesign_scenarios_-_conclusions.

Implementation

The dialogs require a greybox-style dialog. This amount of modality is widely accepted as the best way to do modal dialogs on the web, since they do not lock the entire browser window. Without javascript, the same dialog can be used as a new page, which, when submitted, is returned to the page from which the modal dialog was launched.