Re: Action Item: Additional Examples Guideline 2.5 (user error)

Hi Gian and Group -

I just went to Microsoft's site (http://www.microsoft.com/worldwide) and if
I counted the countries correctly from the pull down menu, there were 76
countries listed.  So, I am not sure where the number 75 came from - maybe a
connection, I am not sure.

Doyle

On 5/12/04 8:18 PM, "Gian Sampson-Wild (PurpleTop)" <gian@purpletop.com.au>
wrote:

> I have a few comments on the user error guidelines- thanks Doyle for
> doing the hard work!
> Gian
> 
> <snip>
> Guideline 2.5 Help users avoid mistakes and make it easy to correct
> them.
> [level 2 guideline]
> </snip>
> <gian>
> - how about a level 1 success criteria is to provide a "Reset" button -
> so users can easily correct and mistakes
> </gian>
> 
> <snip>
> Level 3 Success Criteria for Guideline 2.5
> 1.         Where the input options are known, there are less than 75 of
> them, and they can be provided without jeopardizing security, test
> validity, etc, users are allowed to select from a list of options as
> well as to enter text directly.
> </snip>
> <gian>
> - Is 75 an arbitrary number?  What about those fields that specify
> Country (such as: http://www.microsoft.com/worldwide/) or very complex
> forms (such as:
> http://www.microsoft.com/Usability/enrollment.htm)</gian>
> </gian>
> 
> <snip>
> 1.         If a user error is detected, the error is identified and
> provided
> to the user in text
> </snip>
> <gian>
> - does this success criteria allow this information to be provided via a
> dialog box - if so, what about accessibility concerns re popup windows
> etc? (such as:
> http://www.liveinvictoria.vic.gov.au/web13/Site.nsf/contactUs?OpenForm)
> Do we want to allow this?
> </gian>
> 
> <snip>
> 2.         If a user error is detected, and suggestions for correction
> are
> known and can be provided without jeopardizing security or purpose (for
> example, test validity), they are provided (in an accessible form that
> meets
> Level 1 success criteria).
> </snip>
> <gian>
> Suggested rewrite:
> If a user error is detected, suggestions for correction are provided in
> an accessible manner, where:
> - valid entries are known
> - security is not jeopardised
> - purpose is not undermined
> </gian>
> 
> <snip>
> Allowing users to select an option from a list instead of having to
> enter
> text directly helps individuals with speech disabilities because they
> might
> not be recognized properly in voice input applications.
> </snip>
> <gian>
> Also assists people with physical disabilities, dyslexia etc who may
> spell a word incorrectly.
> </gian>
> 
> <snip>
> An airline web site offers a special promotion on discounted flights.
> The
> user is asked to fill out a simple form that asks for personal
> information
> such as name, address, phone number, seating preference and e-mail
> address.
> When the user submits the form with a form field not filled in, the user
> is
> notified there is an error but all correct information from the previous
> form stays unchanged.  This prevents the user from having to re-enter
> all of
> the previous information.
> </snip>
> <gian>
> should we specify *how* the user is notified (ie with dialog box, text,
> HTML page etc)
> </gian>
> 
> <snip>
> Example 3: online form (same form but a different scenario)
> An airline web site offers a special promotion on discounted flights.
> The
> user is asked to fill out a simple form that asks for personal
> information
> such as name, address, phone number, seating preference and e-mail
> address.
> If any of the fields of the form are either not filled out or filled out
> incorrectly, the user is warned of the input error.  The user is now
> presented with the same form, all previously and correctly entered
> information is still available.  The user is asked to make corrections
> to
> any form field marked with a red arrow or two asterisks ³**².  Note ­
> color
> alone is not used to indicate errors.
> </snip>
> <gian>
> I don't really understand the difference between this example and
> example 2.
> </gian>
> 
> <snip>
> Example 4: pull-down selections
> A web retailer offers online shopping for customers interested in fly
> fishing gear.  When the user is asked for his/her country, a pull down
> list
> of countries is offered instead of having the user fill in the
> information
> by typing. To possibly make things easier, the user is informed that
> countries are listed in alphabetical order.
> </snip>
> <gian>
> but this may invalidate the 75 input rule (see above)
> </gian>
> 
> <end of message>
> 
>

Received on Thursday, 13 May 2004 15:51:08 UTC