We plan to implement a basic version of the new quiz UI by August. This version will probably not have enough functionality to replace the current UI, but will help novice teachers to create their quizes to the system, and reduce need for educating them. After that basic implementation, plans are still open. I have experience in coding PHP for several years, and for one year in Moodle. I will probably ask quite a few questions from you during the following months though
. Especially I need to learn more about how Moodle handles its data structures.
I was a bit overwhelmed by the negative comments. It seems that our interpretations about even the problems are dramatically different. Please tell me what exactly you see problematic in the new UI, or alternatively, which of the problems I have stated do you not see in the old UI?
It simply isn't much a question of "opinion" . The two usability tests i have made show that novices can use the new ui, with minimal explaining of basic concepts. Years of experience shows that they can't do that with the old one. The new ui surely needs more testing, but the basic solutions are based on just making the UI conform better to widely-accepted heuristics
, so I am quite confident that the ideas work. There will surely be changes, though, since usability work is iterative by nature.
I have now put the questions of the translated usability test
online, so that if you really have basis for your doubt, you are encouraged to test it
. I will be more than grateful if you do, and more so if you find issues, so we can work this out together! To find results with the test, you will need to produce proper screens and run the test according to paper prototyping guidelines, as you probably know. I have some screenshots specially prepared for running the test with these questions, and I can post them as well if someone wants to use them.It does, in several places, break common user-interface idioms that are used throughout Moodle. Breaking consistency just in the quiz seems to me to be a very bad idea, usability wise.
I have asked and meant to ask for any background documentation related to the Quiz ui a couple of times in the previos
thread, but it seems I've failed since I haven't been told about (or perceived myself in the UI) any "common user-interface idioms" that I would have broken or the work of Jamie Pratt before. I tried to search, but didn't really find anything now. Please provide some links if there is any? I don't have a server
to install 1.9 right now since I'm on holiday, but I will definitely check his work out.
Granted, my experience on moodle development is only one year, so I might not see the idioms, but then, I don't see how users will if all of the developers don't. If there are such idioms and you expect others than non-insiders to follow them, they should be stated explicitly somewhere as a guideline, like some of the well-known ones
. Are they? If not, please at least tell me what I'm breaking, it's not at all too late to fix
As important as internal concistency is, it seems to me that it would be important to first ensure that basic usability heuristics are followed. In addition, when considering all the user interfaces a given user can be assumed to have used, moodle is still small: It does not help if moodle is consistent with itself, if it is inconsistent with UI's people have gotten used to. (Breadcrumbs in Windows Vista
are good news in this sense: as long as Windows is in wide use, we can expect people to know how to use breadcrumb trails in Moodle, too. We just have to make sure they function in Moodle consistently with the rest of the world.)
This is of course not to say we can not innovate, but innovation must be tested carefully. An example of inconsistency with the rest of the world is the use of tabs
, which in the old Quiz aren't views of the same data, the default tab is the last one, tabs aren't hilighted sufficiently to easily see the status, the tabs are links but don't always react to clicks except by reloading the page, and the user doesn't get feedback about why this happens (no questions added). Are there justifications to these design choices to contradict common heuristics and practical standards?
The solutions I'm proposing here are based on the perceived problems our teachers have had with the user-interface. I'm not claiming it solves all of the problems of quiz (even what I've done so far is too big for anyone to attempt to fix at once, that's why I'm talking to you
). However, there is no question about whether the problems are real: I thought this was so obvious there was no need to go through them one by one, since there's not that much time in my hands. I've tested the new approach with two teachers with no previous experience of Moodle, and the results have been good (essay-based quizes were finished quite independently, after having taught the ideas about a quiz having pages and how random questions work), and further development has been made based on the feedback.
The large-scale problems of the old UI are
- the convoluted nature of the quiz building screen (since it tries to achieve too many tasks at once), and
- the lack of communicating the actual (data and action) models, which the user is expected to follow.
These problems have been addressed with the bigger structural changes in the new UI. I'm happy that you state you agree to what Nielsen thinks about usability: that would suggest we have common ground for discussion. The problems themselves can be mapped directly to Nielsen's heuristics, like I've done in a small degree in the previous thread. These main problems are related to (at least) the following:
- Match between system and the real world
- The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
- Visibility of system status
- The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
I understand that power users will want direct ways of working with the quiz, so the new quiz supports both the old way and the obvious one: One can start from the Category/Question views, adding questions to the quiz after organizing them. However, novices will prefer using the concepts they already have, possibly after being taught the most essential concepts of paging and random questions. With the new UI, they can make the exam quite directly. Only if
they need more advanced structures, such as more versatile question types, they would need to study more. The key here is to make the barrier as low as possible: once they find they can do something
, it is much easier for them to start learning more.
The other tactic of keeping quiz consistent with the real world behaviour is making clear to the user what their exam contains (that is, the system status). For example: In the old quiz, understanding what questions a random question has requires understanding categories and knowing how to navigate in the system to see what they contain (it doesn't help to click the edit button of the question, since that is a dead end pointing to the random question properties). In the new UI, there is no need to start wondering about whether or not the user knows how to go about in different parts of the navigation, since all they need for most operations is in the same view.
- Recognition rather than recall
- Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Also related to the previous issues: when the system status is visible, users don't need to wonder what they saw in the previous screen. In a sense splitting the functionality into different views (in the new UI) is problematic because of this: however, as the tasks, which the different screens are used are separate, and on the other hand, the information from the other screens that is relevant is provided also in the screens where it may be needed, this is a smaller issue.
There is plenty of argumentation for the design solutions I've made, but as I'm not sure which parts are not obvious to you, I'm stopping now and will answer any further questions with more.
I see now that my approach of proposing a lot of changes to the entire UI at once was not optimal. It seems really sad to me that it does not look like you have actually read most of the argumentation I have stated since so far, you're not actually answering it at all.
I'm hoping that you evaluate at least some of the listed changes (which all address very separate issues) individually, so that we can get to some kind of a meaningful conversation. For me it is all fine if things are fixed in a different way than suggested, as long as the problems themselves get acknowledged and addressed.
I will be available in these forums again on Monday, and after Monday on June 12th