Login interface to display password

In 2012, I introduced why you should be able to see passwords when logging in, especially when using mobile devices. Now, two years later, a lot of large-scale new design also appeared, below I will summarize the significance and methods of display password, as well as the follow-up development trend.

What does it mean to display a password?

Passwords want to be filled with practical questions. Because of overly complex security requirements (minimum number of characters, punctuation, and so on) and the use of input boxes is not easy, password input often makes the customer disgusted or even leave.

About 82% of people have had the experience of forgetting their passwords. The most frequently received request from the Intranet service desk is to recover the password, while browsing the E-commerce site, if you need to restore the password first, there will be about 75% people can not complete the purchase process. In other words, the password is a jerk! And for mobile devices with small screens and finger-pointing, things are even worse.

Masking passwords makes it harder for the input to become difficult, at the same time, the benefits of improving security is very small, especially on mobile devices, the input box is just below the visible keyboard, the finger which button, which key will be highlighted, such a touch feedback display password font size is more than most of the input box can display larger. So to be honest, masking passwords doesn't actually prevent people from peeping. Also, if you're really aware that someone is peeking at your screen, just change the screen position so that he can't see it.

Hide/Show Password

In view of the above and the various reasons not mentioned, we chose the polar login interface to display the password as visible text. At the same time we provide a hidden option next to the Password box, so that people need to choose, this option can quickly turn the password into a string "."

Although I am confident that this can effectively improve the practicality and ease of operation, but also not without worry, afraid that everyone will feel that despite the choice of masking, but so naked to display the password is still uncomfortable. In any case, the pattern of landing over the years has given people the mindset that "shielding passwords equals security".

As a result, many people who have used the visual cryptography design software and have been successful have given me surprising feedback. Steven Hoober told me that he had removed the password mask for 20M Sprint customers, and the result was completely out of the question. Mike Lee told us that Yahoo! The default display password, resulting in a two-digit increment (and, of course, a contribution to other functional changes), without creating any security issues.

So it didn't take long for me to think of password masking as an outdated stereotype. This design pattern has been around for so long that no one has ever considered its meaning. All of us are accustomed to adding password masking by default when designing the login interface. And the attendant, is to lose business, practical problems.

Design a solution

Recently, many companies have begun to delve into the problem of password masking and have started a number of different solutions to deal with it. PayPal and Foursquare use a polar-like hidden/displayed text interaction pattern.

LinkedIn, Adobe, and Twitter allow users to choose whether the password is the same by clicking on an open/closed icon. While this type of visual notation may not be as straightforward as text, it has localized benefits for companies operating on a global scale without having to translate into multilingual copywriting of varying lengths.

Microsoft has taken a rather strange approach in hiding/displaying password patterns. In Windows8, the user needs to hold the eye icon to display the password. Once you move your finger away from the icon, the password continues to be obscured. Can only say embarrassed.

Amazon has been changing its login mode over and over again. Its past history includes: from the inability to view the password to allow explicit operation (click CheckBox) to display the password, and then to the default display password and allow click to hide.

While these design solutions have their pros and cons, it's more important that companies like Microsoft, Adobe, Twitter, LinkedIn, PayPal, Amazon, and so on, are beginning to realize the problems with the landing interface and start addressing them accordingly.

Design in detail

However, although many companies now allow users to see the password when landing, this is not to say that everyone should swarmed blindly imitation. It is this swarmed thinking that obscures passwords, and even many other problematic design "patterns" (such as security issues) have prevailed for so many years.

Instead, we should take the time to study the most appropriate solution. You know, the smallest design details can sometimes affect success or failure. To make this clear, let's take a look at Jack Holmes's analysis of a study on discarding password masking.

In Jack's Test, a 60% of respondents said they would be suspicious of the site, and only 45% thought it would help to improve usability, if the default was to display the password explicitly on an E-commerce site. By contrast, if you add a simple check box stating that the display password setting is currently turned on, 100% of respondents will notice that the check box exists and that the display password is considered a feature.

From 60% of people who suspect web site security, to 100% of people see it as a practical function, the difference is just a simple check box. Design is really about the details. So it's no wonder that Amazon added this checkbox to its landing interface.

Web Vs Native

As the example above shows, many companies now allow users to see passwords when they log on to mobile apps. There are also a handful of companies that implement the same functionality on the Web. People who log on to native apps are comfortable, so why not users who use the service in a Web browser?

This question once again mentions the height of security. In detail, if:

1. Someone's got my equipment.

2. and can unlock

3. Then navigate to a website

4. And I saved the password for this website automatically in the browser.

5. This site also allows you to view the password in the login interface

6. So, this person will be able to see my password.

The combination of the browser's password saving, automatic filling and password visible features poses a serious security problem. One way to alleviate this problem is to hide the password box when the browser automatically fills in the password. This way, if someone wants to see the password, the browser deletes the contents of the Password box and asks to re-enter it.

Unfortunately, given the design and development work required to implement this solution, this approach is somewhat less than worth the effort, rather than focusing on how to simplify the login problem as a whole.

Beyond the password

Amazon continues to update the mobile landing interface in its latest release of iOS, which simply doesn't require users to enter a password. When users need to log in to their accounts, they can directly touch the phone's main button and verify the fingerprint through Apple's contact ID.

And the Uber service is a higher level. Users do not need to register accounts, create passwords and enter payment information, just put the finger on the mobile phone Touch ID sensor can complete the vehicle to pay the entire flow of orders. You do not need to fill out any forms and passwords.

While the Touch ID feature is limited to Apple's latest iOS device, the solution simplifies the complex process into a simple one-time approach, creating a new perspective for the design of the login process. If you have a choice, how do you choose to log in and out? Is it through complex forms and troublesome passwords? or a simple touch?

From this point of view ... The future of the login form and password box is clear.