view printer-friendly version (opens in new window)
Suite of QTI development tools completed
The CETIS assessment SIG has coordinated the development of a set of three tools that helps developers implement IMS' Question and Test Interoperability specification.
The suite of tools consists of a full set of documents about interoperability issues around the current version of QTI, a set of working examples of all the sample quizes and tests that come with the spec, and an online QTI renderer that allows developers to test their QTI XML.
The documentation is in the form of a spreadsheet and linked documents that was compiled by Dr. Graham Smith. The crux of this tool is that it summarises extensive discussions of the major obstacles to interoperability between IMS QTI compliant quiz and test tools. The majority of these issues are commonly agreed ways to present particular types of questions. With hotspot-type questions, for example, learners can pick an answer by clicking on a particular region of an image. QTI can encode the learner's answer as either a named part of an image, or else as a coordinate within one single image; the documentation will show the pros and cons of either solution, and an agreed solution (in this case: tools should support both named parts and coordinates, but named parts are preferred).
But the technicalities of rendering questions are not the only issues that are dealt with. Pedagogic and feedback questions like the desirability of having multiple levels of hints to help learners fins the right answers are also discussed.
For developers who are just starting their implementation, the set of online working examples are probably the most directly useful. The examples are derived from mock questions in QTI XML that are part of the best practices guide that comes with every IMS spec. But the assessment SIG example site does more than simply allow you to view the question in both raw XML and as the rendered result: it also provides extensive commentary about why the example is rendered as it is, and what kinds of things were changed or improved over the original IMS XML.
The deeper issue there is that a lot of QTI implementors have relied on the illustrative examples rather than the normative, official information model, which led to a catch 22 that's familiar to most spec developers: the spec needs examples to get implemented, but in order to make examples, you need an implementation. The developers of QTI could only work around the catch by hand rolling their own XML, which means that there's a few bugs and ambiguities. Dr Smith's example site flags all of those, and presents agreed solutions and workarounds.
The example site is open to anyone, but a simple, free registration is needed to be able to upload and render your own QTI XML. For developers who have already made some tools, this offers the possibility to check their program's QTI XML against a reference implementation, see relevant and annotated documentation on the spec and tap into a community of fellow implementors, all at the same time. No excuses for not interoperating, in other words.
All the QTI development tools are available from Niall Barr's CETIS QTItalk site.
No responses have been posted