Since your users don't have email, it sounds like the plan is to use
the hint (and response) to directly gain access to the account. So
really you're creating two paths to sign in, and you're asking your
users to come up with two passwords instead of one.
First, consider dropping one of the two sign-in paths (i.e., just have
the main password, don't put any strength requirements on it like
minimum length, etc. OR just have the hint/response to sign in). The
path you're down has a lot of cognitive load to sign up (remember
username, create & remember password, create & remember hint and
answer).
Second, if showing the second password in plain text during sign up
isn't a concern, why not show the main password that way too (or
instead)? This should reduce the worry that you can't check if it was
mistyped during sign up by not having that "confirm password" entry.
Finally, if there's really not that much at stake, is a password even
necessary? This may be too drastic, but maybe not.
-Adam
On Jul 10, 2008, at 12:29 PM, Steven Chalmers wrote:
@ Jeremy White - Regarding availability of e-mail.
Jeremy, you guessed correctly that these users do not have e-mail.
I believe that the best way to justify my design is to consider the
following design criteria (which I should have included in my first
post):
1) This is a low security risk application
2) The users do not have e-mail
3) We want to lessen the load on our internal help desk for password
resets.
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
