Quiz UI redesign prototype presumptions
This page is related to the discussion in the forums.
Quiz UI redesign prototype presumptions
The basic presumptions of the new UI are as follows.
Firstly, as is quite obvious, the improvement will mainly benefit those users who actually use the web UI for creating and managing quiz content. There is also a group of users who generate their questions in a format they can import into quiz, and while clarifying the UI and making it communicate its data structures better will also aid those users, they are not the main focus of this work.
Secondly: The problems addressed by the proposition cannot be solved simply by making small enhancements to the current UI, one by one. Thus, a new UI needed to be designed: The current conceptual model of the Quiz UI assumes a process, where the user first adds questions to the question bank, and from there on to the Quiz, either as single questions or categories as random questions. This is in wild contradiction with the conceptual model teachers have, with experience from traditional exams. The only way you to get less committed novice users to create quizzes, is by making the UI structure communicate using their concepts, their language, and their process. You cannot (gradually or not) add the natural conceptual model to an UI that already uses a different model altogether, since this way you will confuse all users who try to use either of those models.
An example is in place. As an attempt to let a novice user add questions directly to a quiz, you could add an "Add this question directly to the quiz" tick box to all the screens for creating a question. However, this would not help the novice users, since according to their model, "OF COURSE the question goes into the quiz, where in the world else would it go?" Alas, that tick box actually would take the UI further away from the user's conceptual model, since there would be yet another option which does not make sense to them.
Novice users see the quiz itself as the fundamental unit, since that is how exam making works in the real world. They need not bother with the idea that questions also exist in another dimension, the question bank. The best we can do for these users is allowing them to just create the quiz and ideally to give meaningful category names for their questions. They do not yet need to have a concrete understanding of the fact that the questions in the categories are somewhat separate entities from the ones in their quiz. Also, allowing them to create random questions directly into the quiz is feasible by creating the necessary category - transparently to the user - when creating the random question.
Categories or hierarchies are not difficult concepts in themselves. What takes time to learn are the relationships between categories and questions and random questions and quizzes, and so on, and then mapping all that understanding to the UI (which itself currently does not clearly communicate those underlying relationships). The user who just wants to create a quiz, does not need to and cannot be forced to understand all this, just to make an one-time quiz. (Of course, this does not stop us from encouraging users to organize their questions in meaningful categories, but that’s as far as we can go.)
However, in Quiz, the eventual full model is that which also includes also categories etc., in addition to just the Quiz content. For use cases that involve exporting importing questions or keeping them organized, users will need to understand the full set of concepts. Still, we cannot shove the full set of concepts, foreign to the novices, down their throats by force. The solution is progressive disclosure (http://www.useit.com/alertbox/progressive-disclosure.html), which we can have to a degree even if the new interface is a separate module: users first use the UI that mostly speaks to them with only the concepts they already know (with the exception of random question) but manipulates the same data structures as actual Quiz. In this UI users may gain "conceptual handles" (such as a category), which they can use if they choose to learn the concepts required when using the more advanced UI.
