0

Entering normal text in short text-boxes gives a visual feedback as

  1. You can actually see the letter you pressed
  2. The letters shift.

However, with password fields masked by dots/asterisks, there is no visual feedback if you pressed a key or pressed it down too long(sticky keyboards[sic]) as there is no visual change in the text-box.

Are there any solutions to giving users this feedback?

PS: I know the *nix command line password entry method which doesn't even show asterisks but IMO even that gives some feedback as the cursor blinks a bit when you press a key(It's a bit hard to describe.)

EDIT: I meant visual feedback when the password gets too long for the text-box. Once the password gets too long, the asterisks/dots do shift but since all are identical, it is not noticeable to the user.

  • However, with password fields masked by dots/asterisks, there is no visual feedback if you pressed a key or pressed it down too long(sticky keyboards[sic]) as there is no visual change in the text-box. - of course there is a visual change: you get another dot/asterisks, or a lot of them if you key sticks. – Evil Closet Monkey Jul 1 '14 at 20:52
  • @EvilClosetMonkey I meant when the password becomes longer than the text-box. When the box is already full of dots/asterisks, another dot/asterisk shifting the rest to the left is not noticeable. For example, in the search box on this page itself, if you press and hold the a key and the box gets filled up, pressing the a key again does not give you any visual feedback;s/a/*/ – user80551 Jul 2 '14 at 3:47
1

We need to look at the use case and environment. A few examples:

  1. ATM machine uses sound and asterisk/dot to provide feedback. This is pretty much everywhere.
  2. Normal web form for most desktop environment uses asterisk/dot. Here, the user is assumed to have good and stable control of he keyboard and knows what they are typing.
  3. Wifi password prompt in Windows and MAC OS X all has the option to should password as plain text. The assumption here is that it is a one time action. And the leak of wifi password is unlikely or does not bear serious consequence.
  4. On some mobile app recently, where keyboard error is more likely due to clicking space, there are actually some people who makes a plain password the default option. I'm typing this with my iPhone, so I'll have to look them up. To be uploaded. Here, maybe the app is just for some casual usage and does not require that much security.
  5. Provide alternatives to password. Perhaps this should be the first thing we need to think about before even considering how to solve this problem. Is password required at all for user's purpose? Can we make the users life easier? For example, Mint app let's user set up a 4-digit PIN. A lot other apps use Facebook/google login. For a lot if apps, there is no need for user sign up or login in the first place. Yet, it is often for product owner's benefit to collect user information rather than make user's life easier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.