I refuse to bow down to Dr. Nielsen's suggestion to do away with the masking of passwords. This is why!

My colleague Danny says "Password masking is more of an emotional aspect in the design. When I see my password masked, I feel its secured / safe." Completely agree.

The bullets/asterisks/stars brings out the “ostrich” in humans.
If I can’t see the password no one else can. Very comforting emotionally. Kidding.

A few observations:

  1. Most users type slower and many a times look at the keyboard when typing passwords.
    True, this is because of the lack of feedback. But most users are adapted to it.
    It’s natural human response to be more careful when doing something important and secretive!

  2. Its relatively difficult to watch keys as you type them and remember the sequence.
    Its lot easier to see the entire word on screen and memorise it. (Of course intelligent password thieves hell bent of stealing your password have better ways)

  3. Users copy-paste passwords not because they can’t see it on-screen. It’s because of a zillion different password rules (including rules to change passwords every certain number of days) on different sites and applications.
    There are more things to remember than the variation of my “usual” password I was forced to create to confirm to the rules on "xyz" site/ application/ intranet.

  4. 99% of times you would have seen people’s password because on many web pages
    (probably because of loading time) the focus automatically shifted from the password field to some other unmasked field. That is if they were not deliberately looking away from your screen (sometimes at the ceiling) when you were typing your password. Danny points out this very correctly, most conscientious individuals do that)
    My suggestion, the password field should be enabled only after the entire page has loaded.

  5. The partial masking works for small screens only. People have to be real close to read it

  6. On-screen keyboards while saving you from key-loggers expose your on-screen keystrokes! Remember monitor sizes are increasing!

  7. Having a check-uncheck option for passwords is not a great idea. This may only work for sites and services where we don’t care about security much.

  8. Most login failures happen because we do not remember passwords and not because we can’t see what we typed.

  9. It’s very difficult to edit passwords because it’s difficult to locate the character position among a row of "un-differentiated bullets".

  10. It’s easier to remember a password when it forms a logical (either dictionary or local language/ jargon) word. It’s extremely difficult when it’s a mix of alphabets, numbers and special characters that do not make a dictionary word.

My humble suggestion.



A few good things about the suggestion.

  1. Allows checking of passwords one character at a time. One character at a time may not make a sense to an onlooker. A quick glance of the sequence would make sense only to the user who know the password.Alternately colouring the bullets ( or anything similar) can make locating the position for an edit easy!

  2. This assists people who have problems with passwords. The experts can keep doing what they are good at!

  3. Can support keyboard navigation too. Guess (ctrl + k) is not used for most browsers. Else some alternative can be found, I believe.

Please feel free to blow this into bits and pieces with your heuristic evaluation.


With inputs from my colleagues at work!)


All of us have seen many innovative ways of searching, filtering and browsing data from a list. While working on this dialogue I encountered this problem. I call it a problem because the list of users may vary anywhere in between 2 (for an entry level executive) to 50,000 for a CTO. And every level of users would use it frequently.

For an entry level executive, the browse model suits the best. Easy to use and prevents errors. However, for a senior executive, the search model would be the best.

PROBLEM

  • These are 2 fields that need to be filled up in order to assign a user to a task.
  • Each field can have any number of possible values (I get to choose between 2-10 if I am a junior executive; 50,000 for a CTO!)
  • All users are uniquely identified only by a combination of Area Code and ID.
  • Data selected / entered in a field needs to be validated. Validation queries the database. Narrower the search , less is the system load.
  • This selection has to be made on a Task Assignment dialogue that contains other fields as well.

CONSTRAINTS

  • Development on Eclipse RCP using native SWT components only. Custom components can be developed only if “really required”.
  • No AJAX (or any similar technology). To populate fields with data, we need to explicitly query the database.
  • Keyboard navigation should not be affected
  • This form/ dialogue is already a pop-up on the main screen
  • Efficiency is crucial, so a Wizard interface is ruled out. (the development teams are not so happy with Wizard interfaces)

SOLUTION

  • Users know how many users they supervise. So they make a choice between Browse and Search.
  • Fields are dynamically displayed on the dialogue.
  • On selecting ‘Browse’, the user gets a drop-down for Area Codes. On making a selection, the ID dropdown is populated.
  • On selecting ‘Search’, users gets to input Area Code and query database.
  • Data is validated and the IDs populated.
  • Less than 30 IDs, dropdown shows.
    More than 30 IDs, need to type 2-3 numbers to allow data to be filtered.