[QTI] More questions about stringInteractions

[Daniel Cassidy]

Hi List,

Sorry to bombard this normally very quiet list with two questions in
one day :).

I have a couple of questions/issues regarding stringInteractions:

1) Regarding the placeholderText attribute, the spec says:

     "In visual environments, string interactions are typically
      represented by empty boxes into which the candidate writes
      or types. However, in speech based environments it is
      helpful to have some placeholder text that can be used to
      vocalize the interaction. Delivery engines should use the
      value of this attribute (if provided) instead of their
      default placeholder text when this is required. Implementors
      should be aware of the issues concerning the use of default
      values described in the section on responseVariables."

   The expected behaviour here isn't terribly clear. For example,
   for an empty text box, normally a screenreader will read
   something like:

     "BEGIN INPUT FIELD END INPUT FIELD"

   Assuming placeholderText="bananas", the spec suggests that this
   should become one of:

     "BEGIN INPUT FIELD bananas END INPUT FIELD"

     "bananas"

   The first case doesn't seem terribly useful. In the second case
   it becomes unclear how to read a text box which does contain an
   answer while still making it clear to the candidate that that
   answer may be changed.

   Furthermore, the phrase "should use the value of this attribute
   (if provided) instead of their default placeholder text when this
   is required" is highly ambiguous:

    * If the environment is visual, should the delivery engine
      place placeholderText in the input box initially?

    * If the environment is aural, should the delivery engine ignore
      the placeholderText if it has some other mechanism for
      representing an input field (such as that described above)?

   Some examples of correct usage would be appreciated.

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.

   Some possible implementations I've thought of:

    * The delivery engine prevents the candidate from entering input
      which isn't valid by ignoring keystrokes. This isn't very
      user-friendly since the candidate may not understand why their
      keystrokes are being ignored.

      It also can't guarantee valid input. For example, if
      patternMask="^(ab|c)$", the delivery engine doesn't know whether
      to initially accept a keystroke of "a", since an entry of just
      "a" is invalid and the delivery engine can't know if the user
      intends to type "b" next. Therefore this method must always be
      combined with some other method.

    * The delivery engine allows any input but informs the user if
      their input is not valid. Unfortunately, the user may not
      understand why the input is not valid, and it is difficult for
      the delivery engine to provide useful feedback.

      Some mechanism to provide a custom message to display to the
      user in the case of invalid input would be immensely helpful
      here. Even better would be if it were possible to provide
      several messages, selected based on which part of the input is
      invalid.

    * The delivery engine allows any input, but highlights individual
      characters from the input which are invalid. A message is
      displayed to the user to the effect that their input is not
      valid.

      This is better from a usability point of view than the other
      options, but is not always feasible. For example, if
      patternMask="^(adc|dbc|abd)$" and the user's input is "abc",
      which character(s) should we highlight?

   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."

   However, in my view, this really isn't sufficient. It is a
   principle of usable interface design that (human) memory load
   should be minimised. Each requirement that a candidate must
   memorize in order to successfully input their response represents
   additional memory load.

   Similarly, it is a principle that recognition is easier than
   recall. A generic message indicating that a user's input is
   invalid is not helpful because it requires the user to recall (or
   reread) all the relevant validation rules, and work out which
   apply to their input to make it invalid.

   A message relating specifically to the input entered by the user,
   informing them *why* it is invalid, is much more helpful, since
   the user is likely to immediately recognise the relevant rule and
   fix their input accordingly. Unfortunately this is nearly
   impossible to achieve with QTI as described above.

   Finally, I don't believe that patternMask is usable in practice:

    * It is nearly impossible to design an authoring tool which can
      be used by a non-technical person (except in the case where
      the user simply selects from a set of predefined patterns).

    * It is highly inadvisable for a patternMask to be defined by
      anyone without an extensive understanding of software
      usability.

   These facts make me wonder why it is included in QTI at all?


Thanks,
Dan.