Recently we have posted a number of useful tips on creating effective registration forms on the site, and today we want to talk about the login/login block. Recently there have been quite a few annoying and too "abstruse" implementations of it on the web. It's good when designers are trying to make unusual and beautiful login forms (see our selection), fitting them into the overall concept of the web project, but it's quite another matter - when they go overboard with functionality. Sometimes it comes to the point where popular password managers (in Chrome or from 1Password) simply don't work.
In this article, you'll see examples of login forms with usability problems. This is good food for thought for web developers who don't really understand how their audience uses the login tool on the site. In the second part of this article we will show and tell how to best implement this problem and create simple, linkable, recognizable elements that visitors understand and work well with different "password memorizers". The text is an adaptation of this post.
WHAT NOT TO DO
Here are a few approaches that are far from the most ideal and convenient solutions. They are best avoided.
LOGINS IN MODAL WINDOWS
Login form in a modal window
A person has to perform additional actions: click a button in the menu, select a login option, fill out a form. Instead of this you could just go to the login page manually (through a link, from bookmarks) or add a handling action directly in the site header. In addition, the modal pop-up mechanism creates additional difficulties for programs like 1Password - the "open and fill in" function that allows you to quickly enter your credentials when visiting the site is likely to fail. The inability to directly redirect the user to authorization. This will be a headache for customer support, because they will have to give the user a bunch of instructions, instead of just providing a link.
DON'T HIDE FIELDS
Hiding fields in the login form
The mandatory Last Name field on Delta's site is originally hidden, probably to offload the user interface by disclosing the data in stages. The trick is that when the mandatory element in the login form becomes invisible, password managers have no way to pre-fill it. A person has to leave one field in order to access another "super secret" one that will immediately appear. As a result, you get one more (extra) step in your algorithm of actions.
By the way, on the MacOS welcome screen the password line is also invisible, probably to "clean up" the interface (or to encourage logging in via TouchID). However, in the end, such "cleanliness" only leads to more confusion (especially for newcomers).