Tuesday, 21 August 2012

Uniqurate - the final thrust (ooer)

Following the recent RSC workshop, there was a release of Uniqurate that included quite a few bug fixes and a few feature requests. Most of the bugs should have been fixed (and I've probably introduced a whole bunch of new ones, but hey :-) and I've added some of the new features. However, there were a number of ideas for new components that emerged.

We've been fortunate in that around the CAA conference onwards I've been available to work on UQ more or less full time, and as a result we've made a lot of progress in July and August. However, the bad news is that my involvement in Uniqurate ends in November, and along with the fact that once we get into September and teaching commitments rear their ugly head, this quick burn development is going to be curtailed. Short version: there is probably enough time remaining to get test authoring done and perhaps one other component.

So I'm going to put the possible other component to a vote. Feedback from the RSC workshop, plus components that have been mooted in the past, leads us to the following list - numbered for reference, but not in any particular order:
  1. An "Excel" component - essentially a grid of (random) numbers, some of which will be blank, and the student has to fill in the blanks. The blank values would be derived from the non-blank values.
  2. A Medicine Component for questions where you have a list of medicines and a list of "strengths" for each - the question would choose randomly a drug and a strength to set up a calculation (but I'd need a little more explanation here :)
  3. "Fill in the blanks" within text - "blanks" could be either a text field into which the student types, or a pull down menu of choices
  4. Diagram labelling - drag labels onto the right place of a diagram. Potentially, drag bits of a diagram into the right place of a diagram.
These aren't components, but feature requests, any one of which would probably use up the non-test development time:
  1. Option to place feedback alongside the input it refers to
  2. Confidence-based marking
  3. A random wrapper - i.e. you define a group of components, and at question run time it chooses a random component within this wrapper to show. Thus you could set up a variety of different components but with related content - e.g. several maths components with slightly different variations of a concept, MCQs with different but related distractors, etc.
To help you decide, here's some thoughts about these from my perspective:

3 and 4 are eminently doable. Although questions with graphical interactions seem to get good responses from students, the scope of the sister QTIDI project means that we're probably stuck with the legacy Java applet-based graphics for now at the renderer end of things. So if it came down to 3 or 4 my vote would be 3, to concentrate on the component that would result in the best experience when it was finally rendered.

I understand the utility of 5, but it would mean a fundamental change in how the "friendly" mode composes its content, so it would be very complex to do and would burn up a lot of development time for something that is basically aesthetic.

1 and 2 would need to be fleshed out a lot more, and I think there are others with greater cross disciplinary utility - but I'm game if people vote them highest!

6 is often brought up as a popular choice - again, game if people vote it highest.

However, my own vote would be 7. I think it would be relatively easy to implement both from a UI and QTI perspective, yet add a new dimension of flexibility to questions. You could specify a whole raft of similar but subtly different components around a given subject, and really put a student through their paces (although, arguably, one could do this at test level).

Over to you, guys - what do you think?

1 comment:

  1. The reason for putting the feedback by the input is essentially pedagogic – so that the student knows exactly which feedback refers to the inputs they have given. In the Dick Bacon questions on which the original UQ components were based, there is just one input (as in many of my maths questions), but when we have several components in one question, it gets harder to relate the variants on “OK”, “Yes, that’s right”, “Correct”, etc., and their counterparts like “You seem to have...” with whatever it was that they put in. It’s not aesthetic, it’s a matter of reducing mental load. That’s the reason behind the feedback from the workshops – and since the multi-component model is coming out as perhaps the most popular feature with users, it makes sense to go for this change.

    Aside from that, which I'd put at the top of my list, I think item 3 is the best choice, with the widest application.

    There's a fair amount of interest in confidence-based marking, but I don't think it's as high up the list as fill in the blanks, so 6 is my next choice.

    7 is already available through the test interface; it makes more sense to have the questions available separately and combine them into a pick-and-mix in a test.

    We are intending to look at diagrams more closely in a future project; some work has already been done on SVG diagrams which could be incorporated into QTI questions via the extension mechanisms. So I think 4 waits a little while (keen as I am to get going with it!).

    1 and 2 are not quite so widely applicable, so lower down the list. However, 1 might be a special case of 3...

    We have also had a request for "pairing" - matching from one list of choices to another - from an online delegate from one of the RSCs, who points out that this is used in a wide variety of disciplines for relating, for example, scientists with their theories, plants with growing conditions, etc. It might be a quick one to do, based on the MCQ component.

    There's also the solution or model answer idea, not particularly difficult in terms of component design, I suspect, but the question has to become "adaptive" to accommodate it, and so it's a "for later" in my book.