Interesting suggestions about the password reveal. I was thinking
along the same lines. Perhaps a reveal button that must be held
down and when released, the password is again asterisks.
Good luck! I'd be happy to know what your final product uses as some
of my clients seem very similar.
. . .
Jeremy, Yes, I was thinking of a momentary button too. It is a
nice design because it requires that the user conciously engages it.
I think the only negative is the addition of another UI control to
the form.
Steven
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted
And then i was thinking about the #2 option i have mentioned above.
Thought why not keep only one field. Encrypt the password in the one
single password field. But... Display a talk balloon simultaneously
as the user types the password in for a brief moment so that he/she
will know if the password
I'm intrigued by the idea of letting the user turn off password masking
with a radio button or a checkbox, but one concern -- is there a likelihood
that a lot of users will be tabbing through this form?
Unless your users are savvy enough to know to use the space bar
on checkboxes/radio buttons,
If this is a low security application, does it make sence
to simply display the password when they create it?
Even for a low security application the password a user chooses can be
high security. Many people have only a small number of passwords,
which they re-use across applications. For such
Password field: Momentary reveal.
The users are corporate users at call centers where they are not
allowed to be distracted by such things as e-mail and internet
access.
The application is being developed in Silverlight so we have a lot of
functionality flexibility. My development team and I
There are two ways to look at this and before that i would like to say
that the confirm password is essential at the current stage that it
is. By this i mean it is important to verify user key strokes even if
means that most of the users do pay attention or are concentrating the
most while typing
What do you think about putting a checkbox labeled Show password
or Unmask right next to or below the password field, like so:
Password: []
[ ] Show password
when you check the Show password checkbox, it unmasks the password
and shows what you typed in. Uncheck the
I believe there's more to password masking than protecting against an
onlooker. The HTML password field is handled uniquely by your
browser: after you submit the form, any return visits to the page
using the back button will clear out the password field. A regular
text field, however, will have
Erin Yu said:
Another idea is to show the password as the user types it, and put a
timer on it, so when they pause for, say 1 second, it then masks the
password. I can see there could be some privacy concerns with this,
but might be worth user testing it. :)
It's funny that you mention that
Hey Steven
I personally hate the hint question and answer and can never imagine
a useful scenario for it. I've put in a user name, thought of a
password, now I need to think of a hint question and answer as
well??! That alone would stall me significantly!! Retyping a
password? Easy! Obviously I'm
Why not let the user decide!
Make the confirm password field optional and label it thusly.
Only validate against it if it is not null!
Cheers,
Jacob
Welcome to the Interaction Design Association (IxDA)!
To post to this list
Message-
Subject: Re: [IxDA Discuss] Confirm password field - Superfluous?
Should you need support as ammunition against your resistence:
Steven Chalmers wrote:
ii) Since we are only showing asterisks or dots for each character
the user doesn't know if they have typed the correct password
Hi Stephen,
I definitely vote for keeping the confirm password box.
Especially if you are keen on lessening the load on your internal
help desk for password resets. If you're allowing users to create
blind-typed passwords then the rate of mis-typed passwords (without
the user even realising
I've always disliked double fields of any kind, especially double email
fields which I just copy and paste. I always think, can we please not
assume I'm stupid enough to mess this up?
I've always felt the asterisks were unnecessary on sign up forms. How often
do I sign up for a service with
If you want to lessen the load on internal help desk for password
resets then I think you should keep the confirm password box or put
something in for them to confirm that they entered the correct
password. If this is a low security application, does it make sence
to simply display the password
If the users don't necessarily have email, then I don't think we can
assume that these users have become accustomed to having to retype
their password. After all, there are still people who hardly ever use
computers, especially people without email.
If the security risk is low, then I'll change
are confirmed that it's right decision to drop confirm
password
regards
suman
Steven Chalmers [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
07/10/2008 04:27 AM
Please respond to
[EMAIL PROTECTED]
To
IxDA [EMAIL PROTECTED]
cc
Subject
[IxDA Discuss] Confirm password field - Superfluous?
I have
The user can visually verify correct data entry in all the fields except
the password field (because it is masked). Requiring the user re-type the
password is the only way they can verify they typed the correct password.
I would vote to keep the re-type password field. I have seen some systems
Should you need support as ammunition against your resistence:
Steven Chalmers wrote:
i) It is convention to enter passwords twice.
- My response: I need a better reason than that.
It's not such ingrained convention that any user will wonder why it's
not there.
ii) Since we
From a user's point of view, I know that I tend to type rather
quickly. If anything, I probably mistype my password on registration
forms more than anyone else because I'm doing it quickly and assuming
I got it right. I think it would make me feel uneasy if there's no
field to confirm.
Especially
Steven,
We had a form like that for several years where we only asked for the
password once.
For a username we required an email address. I had it changed to include a
second box for confirmation, but the reason had nothing to do with typing it
incorrectly.
I observed multiple instances in
How much easier is it to guess someone's hint question than it is
their password? I'm guessing it's a lot, considering you're given
a hint and the answers are usually given as simple words, not random
characters as good passwords could be.
I would consider if is the security risk was worth it.
I think the terminology you use is confusing two separate concepts out there.
First is the password hint. This is typically a phrase that will
jog one's memory of one's actual password, like my first dog's name
with a hyphen in the middle.
Second is a secret question and answer. This is
I personally love the confirm password field. When I'm entering a
highly complex and secure password such as fr5^n(!QD#asdf, it's
really easy to mess up. Without the confirm field I can think of
many instances when my password would have been wrong.
So please count me as one user who votes no
The way it's written, it doesn't look like an email is part of the
plan; just answer the question and you're logged in and allowed to
change your password.
Sending the person an email is definitely not going to be such a
security risk (such as the way IxDA.org handles log-ins).
This won't work
@ Jeremy regarding: How much easier is it to guess someone's hint
question than it is their password? I'm guessing it's a lot,
considering you're given a hint and the answers are usually given as
simple words, not random characters as good passwords could be.
My apologies for not giving enough
@ Jonathan Abbett regarding: I think the terminology you use is
confusing two separate concepts out there.
Sorry you didn't find my terminology clear. I'm not proposing a
Password hint, nor did I call it that.
The proposal is to have a back-up, automated mechanism for allowing
users access to
@ Loren Baxter regarding: I personally love the confirm password
field. When I'm entering a highly complex and secure password such
as fr5^n(!QD# asdf, it's really easy to mess up. Without the confirm
field I can think of many instances when my password would have been
wrong.
While I respect
The difference between the password being simple and the answer being
simple is the fact that the answer, is well an answer to a question.
The password has endless possibilities of simple answers.
Not that my users are the same as yours, but we did a survey to find
out if our users prefer to
@ 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
I have a design for a new user registration form in which I am proposing to
not use a Confirm password field and would like your feedback on this
decision.
The form will have 4 fields, all of which are required:
1: User name (This will be supplied to the user prior to their using this
form)
2:
I have a design for a new user registration form in which I am proposing to
not use a Confirm password field and would like your feedback on this
decision.
The form will have 4 fields, all of which are required:
1. User name (This will be supplied to the user prior to their using this
33 matches
Mail list logo
