[QTI] Questions about extendedTextInteraction

[Daniel Cassidy]

Hi Steve,

On Wed, Nov 12, 2008 at 9:55 AM, Steve Lay <steve.w.lay at googlemail.com> wrote:
> Daniel Cassidy wrote:
>>   Assuming both expectedLines and expectedLength are both
>>   specified, would it be reasonable to interpret an
>>   extendedTextInteraction as roughly equivalent to the following
>>   HTML element?
>>
>>       <textarea rows="expectedLines"
>>           cols="ceil(expectedLength / expectedLines)"
>
> Yes, this is what was envisaged.

OK, fair enough.


>>   What about in the case where expectedLines is specified but
>>   expectedLength is not? In this case I cannot determine any
>>   sensible way to interpret expectedLines.
>
> What about the case where expectedLength isn't specified either?  If you
> have to choose a size for the box I assume you would choose based on a
> default value, or perhaps by looking at the correct answer (dangerous in
> that it gives the candidate a clue).

The case where expectedLength isn't specified is the one I described ;).

Anyway, my point is that expectedLength is meaningful even in the
absence of expectedLines: I can pick a default width, and then base
the height on expectedLength/width. This gives the candidate a cue as
to the expected length of the answer which matches the test author's
intentions.

Conversely, expectedLines doesn't mean much in the absence of
expectedLength. Certainly, it defines the height of the input field,
but as a cue to the candidate that isn't much help if the width is
implementation defined.

To my mind the most sensible way to size an extendedTextField is as
follows (pseudocode):

   if (!defined(expectedLength)) {
       width = MAX_WIDTH;
       height = DEFAULT_HEIGHT;
   } else if (expectedLength < MAX_WIDTH) {
       width = expectedLength;
       height = 1;
   } else {
       width = MAX_WIDTH;
       height = ceil(MAX_WIDTH / expectedLength);
   }

But this implementation ignores expectedLines altogether. I just
wonder what expectedLines was intended to add to this -- am I missing
something?


>> 3) The specification seems to fall short of allowing the test author
>>   to clearly specify their intentions when using the maxStrings
>>   attribute. That is, if the author specifies maxStrings="5", they
>>   could mean one of two things:
>>
>>    * A correct answer consists of exactly five strings. A candidate
>>      entering less than five strings cannot expect to get full
>>      marks.
>
> Use minStrings for this.

I see that minStrings is being introduced by QTI 2.1. I didn't think
to check, sorry.

For the moment I am implementing only QTI 2.0 on the basis that 2.1 is
in draft. Should I reconsider this decision?


>>   Presumably if maxStrings is unspecified the delivery engine must
>>   always provide some interface to provide an additional response
>>   if the candidate wishes?
>
> Yes, I have seen implementation where the next box appears when you type in
> the last one (if you see what I mean).

That sounds ideal, I may just borrow that idea :).


Thanks for your quick response, it was very helpful.

Dan.