Moodle Quiz UI for creating quizzes

As a result of a change of plans, I started to implement the reordering tab last week. That is: I decided to implement all the functionality before doing usability testing with the actual application. This was due to the fact that it was not easy enough to get teachers as usability test subjects during July. Instead of hunting, I decided to put my energy into implementation.

Thus, the question ordering/paging tab is well underway and will, if all goes well, be finished by next week.

The feedback from the Moodle community about the demo published last week has been very positive, though I have gotten some very interesting development ideas, too. So that is something to be glad about! :)

This week:

• Question bank layout (major CSS rework) finished
• Status bar of quiz etc added
• Setting grades for questions finished
• Fixed several small bugs

Published the demo version of the new UI yesterday (link: no user id? login as guest). Today I tested it with IE and the issues seemed less catastrofic than I expected. YUI javascript stuff does not work in IE yet, though.

Completed:

• Adding single questions directly to quiz
• Adding random questions directly to quiz (both AJAX-style/lightbox, and without javascript)
• Single questions CSS layout in quiz
• Properly resizing the quiz contents (column width) when showing/hiding question bank
• Taking javascript out of the PHP file in a separate javascript file
• Separate ‘add description’ button

Started:

• CSS layout for random questions

In short, the quiz display is very near complete. Next up: question bank window display. Also considering some negative margins to make the document flow order more sensible. I have not tested anythin in Ye Mighty Internet Exploder yet. I think of that moment in slight feelings of angst. Something amusing about browsers and users

Contacted some usability test persons I recruited earlier. No reply yet.

Released version 0.21 to tracker. I am planning to put a demo moodle here, once most other features will have been completed. For now, you can look at the static HTML demo and if you wish, download the version in the tracker for testing.

There were a couple of issues with the current quiz/questions. The most pressing one is that the Edit/Add Questions page seems to absolutely require a question category as a parameter. It would fit the workflow much better if a category could be unspecified once entering the question editing page with a new question. Then, the user would have to think about categories at least as much as to select the default category from the list. The changes required to do this seemed too dramatic so they should probably be discussed with Tim Hunt/the community. For now, we are preselecting the default category for the user.

Some highlights: To get quiz work as designed, I added a new GET parameter to the question editing page, which allows specifying the name of a GET parameter to return a newly created question’s id to the page in returnurl. Also, the quiz editing page got a new get parameter, addonpage, for specifying the page on which to add a new question.

It is somehow frustrating to use precious coding time in project management, but today I did and I am glad. Found many gems from my notes that I would have been sorry if I had found out them too late when actual development would have been done too far.

Last Saturday, I published the final spec with screenshots of the tested UI. Though everybody seems to be on holiday, I got some comments about it, too. Implementation is going on in the tracker, which is the main means of following development at this point, as well as the development section of the project portal for the bleeding edge developments.

Also the prototype testing report and details have been online for about a week now.

Created an 0.(0)1 version of the functional UI; added it to the new issue in the tracker.

Just finished the last OOo Impress prototype test, I have now done eight of them in total with different subjects from four different educational institutions. I will publish the results on Friday (and boy, is there a lot to talk about or what).

Tomorrow I will try to code together the first bits of actual code, in order to put them into the tracker, in order to gain Moodle CVS access, in order to start seriously developing :).

The discussion about scenarios has gotten into a nice-ish start. I also published some details about how the scenarios interviews were done. Although I will try to take into account all the feedback from that background data, it does seem quite far from concrete use cases or the UI. The work I am doing just on two - although quite complex - screens, still mostly seems too simple to be affected much by the high-level differences between the personas, though some changes have been made based on them, too.

Nevertheless, I have been working on the prototype again, for the most part making fixes based on the usability tests done on May 28th and 29th. I will probably do some rather quick&spontaneous prototype testing with basically anybody I can get my hands on, not to prove anymore the UI suits the tasks of teachers, but more trying to make sure the functionality is understandable, in accordance with the ideas presented about discount usability testing in Don’t make me think by Steve Krug. After that I will publish the final OOo Impress prototype.

The different areas of focus in the actual implementation and coding work are envisioned to be as follows. Note that most functionality is already present in the current Quiz - this is UI work, after all.

(What was here was moved to the Implementation plan page.)

Published this on Saturday in the Quiz forum.

• Youtube: Moodle Quiz UI: Call for help: In pursuit of scenarios
• The forum thread for discussion
• The scenarios

For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task independent of how they would complete it within the application.

Yesterday, I started to grasp more comprehensively the relationship between personas, use cases and scenarios.

While trying to piece this together, I drew what used to be a simple diagram. But then it got a bit out of hand:

The reality and the dynamics a UI designer observes and manipulates

Download diagram: PDF, Openoffice ODG

First off, there’s reality. That is to say, this is not scientific research. In a small scale guerilla usability project, we do not pretend it is, much. Still, we observe reality and gather knowledge about the users. Iteration in testing and also in interviews must serve as our backup against which we check that our conclusions are hitting their target: we take the knowledge we find to the user interface and to our generalized conclusions, and then verify with our users.

Use cases

In a sense, modeling use cases equals doing actual UI design: the main difference is in the abstraction level. Use cases will be the actual hard ground when drawing prototypes, representing the idea or ideal about what the UI should be like. That is, what should be possible to accomplish with it, and how.

When designing the actual user interface, the designer takes all the use cases (=the goals), and merges them using his/her creativity and experience. As the use cases may conflict, the resulting user interface is usually some sort of a compromise between the different use cases. Also platform restrictions pose threats to the ideals: technology requirements (no dependency on Javascript in this case) and needing to conform to existing UI conventions would be examples of this.

In the case of this project, I have so far been thinking about the word “use cases” mainly from the point of view of the old user interface - I have understood it roughly as the functionality of the UI, which is to be transferred to the new UI, just better enabling the users’ scenarios (better enabling users to do their tasks). However, this is actually an overly computer-centric approach to use cases, and basically incorrect. More importantly, as is obvious in terms of the definition, use cases take the functionality of the program and model the user in interaction with that functionality.

There are several ways to see use cases. First, when we look at the current UI, you can see three different sets of use cases, from ideals to reality:

• ideal use cases: how the software developers think the software should be interacted with
• observed use cases: gathered by seeing real users (UI testing or otherwise) use the current UI. This is a subset of the next one:
• the real-world use cases of the interaction that is taking place with real users and the current UI

Scenarios

When we just have the use cases of existing software, we do not get very far. At best, with testing, we see the problems users are having with the current software. What we do not see, is whether or not we are even trying to solve the right problems.

Enter scenarios. That is: independent of the application and its UI, what is it that the user aims to achieve, and what is the way s/he does it best?

How do we find out? Talk to the users. It may be scary at first. They are people, after all! But go ahead and try - turns out that people are actually glad if someone wants to learn about what they need to make their lives easier.

Whenever you talk with actual users about their actual tasks and goals, you are in the sphere of scenarios. But the hard part is taking the scenarios and making them somehow digestible pieces. That is: you look at what the users tell you, and tear it in pieces until they are atomary, that is, single actions (you might want to observe this in terms of GTD’s Next Actions: visible, physical actions). It is not just the tasks you need to find out about, but what affects accomplishing those tasks: patterns, goals, skills, attitudes, and environment (as stated in Cooper’s article about personas, link below).

Getting somewhere

So now we have a set of use cases from the old software. Then we have a set of scenarios describing the actual environment, tasks and goals of the user. Now, we try to match them: scenario 1a fits with use case 1c, and actually, also with use case 1d (that is, the user can do the same thing in more than one way in the application). But then with scenario 1b, the user has to do a task in an unnatural order of subtasks or can’t do it at all because it is too hard for him/her or because it cannot be done at all.

And once we get that far, we can take those differences, and start writing new use cases. That is, designing the interaction that the application should facilitate. Once sufficient iteration has been achieved or the deadlines are too close, we can state: We know - well enough - the interaction and whatever affects what that interaction should be like - now let’s get to business, the actual UI.

Oh yeah, almost forgot - something brilliant: Perfecting Your Personas