RE: forms problem

At 04:04 AM 2002-01-15 , DPawson@rnib.org.uk wrote:
>> Wouldn't it be reasonable to open a new page with the help 
>> but to clearly
>> have as the first statement on the page instructions such 
>> as:"This helppage
>> has opened in a new browser window,when you wish to return to 
>> the page you
>> were on please close this window."
>> That way no one is annoyed much, the WAI Guideline in respect to not
>> changing focus without informing the user is satisfied and 
>> everyone should
>> be able to use it.
>
>Yes, that was in our plan. also as the last statement on the help window
>page.
>
>Our user testing has shown that to be a possible source of 
>navigational confusion. think of the new user, who has to 
>seek help on each field of a large form.
>
>I'm coming to the conclusion that there's no b/w answer to this.
>another compromise coming on?
>

Absolutely.  Covering the extremes in sensory function pulls you in the
direction of modal variation in the presentation which always costs in
confusion.  

There is one aspect of this scenario that hasn't been explored in this pass
through the topic, IIRC.

This is the relationship of the help function to error recovery.  Perhaps these
should be coordinated and/or integrated.

Consider for a moment Gregory Rosmaita's design for a follow-up form to be
produced [for example by server-side scripting] on the occasion that a
submitted form fails data validity checking.  [At the server for concreteness
only.]

In this design the error recovery page starts with [presents before the actual
form content[] a table of navigation for the fields that are failing.  That is
to say a summary list of these linked to them and by means of 'next failed
field' links through them as a tour.  In the error recovery page, verbose
explanations are expanded inline around the failing fields.  But the order of
all the fields is the same and the use can, if they wish, on understanding the
criteria for these fields go back and change the values of any of the other
fields.  It is important that the user can still to a tab-navigated review of
all field data before submitting, even on the second attempt.  This is a
partially-expanded form, with the help text expanded inline based on server
detected error conditions.

On possible approach is that the page serves initially in compact form, and
there is a button for "form with expanded instructions" or some such legend
that gets you served the long form.  You never need to go 'back' to the short
form, however.  If money is involved there should be a confirm transaction
summary (order summary) step which is presented in compact structure.

The initially-served compact structure can have the flyout branches built in,
which are suppressable.

Not that this isn't a compromise, but it may be as low as you can drive the
failure rate due to the different favorite failure modes of different
disability groups with readily available Web technology at this time.

One of the 'larger context' themes that this conundrum illustrates is a hunch
that help services would be more effective if better blended between
OS/Ap/page/form/etc. levels of scoping.  Not require the user to grok a context
stack to understand what help response they are getting.  In other words,
'hunh?' should be a globally scoped user verb and it should bring context-aware
(and modality-appropriate) help running.  But that's a research and standards
negotiation topic, not a site design.

Al

>Regards DaveP
>
>********* snip here ***************
>
>- 
>
>NOTICE: The information contained in this email and any attachments is 
>confidential and may be legally privileged. If you are not the 
>intended recipient you are hereby notified that you must not use, 
>disclose, distribute, copy, print or rely on this email's content. If 
>you are not the intended recipient, please notify the sender 
>immediately and then delete the email and any attachments from your 
>system.
>
>RNIB has made strenuous efforts to ensure that emails and any 
>attachments generated by its staff are free from viruses. However, it 
>cannot accept any responsibility for any viruses which are 
>transmitted. We therefore recommend you scan all attachments.
>
>Please note that the statements and views expressed in this email 
>and any attachments are those of the author and do not necessarily 
>represent those of RNIB.
>
>RNIB Registered Charity Number: 226227
>
>Website: <http://www.rnib.org.uk/>http://www.rnib.org.uk 
>

Received on Tuesday, 15 January 2002 09:37:47 UTC