[QTI] More questions about stringInteractions

[Daniel Cassidy]

Hi Steve,

On Wed, Nov 12, 2008 at 9:49 AM, Steve Lay <steve.w.lay at googlemail.com> wrote:
> The purpose of the QTI having a placeholder text attribute was to allow
> authors to override the default placeholder text with their own *in these
> cases*.  It was only ever envisaged that it would be used in situations
> where the (assessment) application is taking control of the access issue and
> supplying the placeholder text in the first place.  If your system relies on
> a reliable lower level mechanism to meet this particular access requirement
> then it seems perfectly acceptable to ignore the placeholder text given in
> the QTI.

Ah. I understand where this is coming from now. Thanks.

> On the other
> hand, if an empty box is voiced with a phrase like "empty box" then you
> might want to consider using the placeholder text instead.
>
> I don't have a great example but a question for which the possible answers
> might be confused with the default voicing might provide one.

I would hope that most screenreaders would voice "begin input field"
or similar with different intonation, minimising the chance of
confusion, but my experience is not extensive.


> Daniel Cassidy wrote:
>> 2) Regarding the patternMask attribute, there doesn't seem to be any
>>   user-friendly way to feed back to the candidate that their input
>>   is not valid.
>
> This is quite a general UI problem as you suggest.  I'll leave it to others
> to suggest implementation solutions here.

I meant to say that I don't believe it _can_ be implemented well
against the current spec, but I've been surprised before and perhaps
someone will surprise me again :).


>>   I notice that the QTI 2.1 draft has introduced additional guidance
>>   as follows:
>>
>>     "Care is needed to ensure that the format of the required input
>>      is clear to the candidate, especially when validity checking of
>>      responses is required for progression through a test. This
>>      could be done by providing an illustrative sample response in
>>      the prompt, for example."
>
> It was envisaged that this prompt would enable the user to recognize the
> form of input required.  For example, you might ask for a credit card number
> in the form "1234 4567 8901 2345" requiring spaces (I've still found some
> forms that request this) as per the layout on the card.
>
> A more complex pattern that is not easily recognized by the candidate would
> create the problems you envisage I'm sure.

Part of my concern arises from the fact that regular expressions are
used to specify validation requirements, rather than some much simpler
pattern.

It's quite easy to conceive of a usable interface for entering credit
card numbers in the above form. Roughly, I would ignore all keypresses
that aren't digits and insert the required spaces automatically at the
appropriate points. If the user presses a key that is neither a space
nor a digit, I would show an unobtrusive reminder beside the input
field that the input should consist only of digits.

I don't think it would be too much work for a delivery engine to
determine that it should behave in this way based on a regular
expression such as "([0-9]{4} ){3}[0-9]{4}". The danger is that for a
more complicated expression, it's difficult for the delivery engine to
do anything helpful and it may end up doing something quite
undesirable.


>>   These facts make me wonder why it is included in QTI at all?
>
> It is common in surveys (more than tests) to use form validation prior to
> progression.  Simple patterns can be shared for common tasks and specialist
> authoring tools might hide them from authors completely!

Yes, I suppose it is. As you've probably guessed, I am focused on the
use of QTI for tests. The fact it is also used for surveys does tend
to slip my mind.


Thanks again for your helpful responses,
Dan.