11 Expert Tips For Enhancing The User Login Process

Tweet

You and your team have worked hard on your web application—it’s your pride and joy. Plus the users that you tested it with are all happy. They just love all the community-building features that you’ve added. Great!
Yet six months after launch, the site just isn’t gaining any traction with the community. People just seem to be drifting away. Why? Everything seemed perfect, so what could be wrong?

This situation is all too common, and the root cause often lies in the basics. Even a very small component of the site can have a dramatic effect on the user experience!

For example, if the login process itself is delivering a poor experience, then people will be reluctant to use it, and all of those killer features you added will be in vain. In the worst case, it could be discouraging people from logging back into the site at all, which means no community, no repeat sales … all of this adds up to a failed site.

So What Went Wrong?

Most of the time the problems in a web site or web application are very simple things. Still, even small problems can equate to a negative experience. And you really don’t want any negative experience if you can help it. Users are sensitive, you know!

It’s true that some people will buckle down and try to work around any usability issues they’re encountering—we all love problem solving, right? It’s in our nature. But don’t forget that as the Web becomes easier to use, people are becoming less tolerant of bad interaction design and will often seek out an alternative service if it offers a better experience, depending on how much they have invested in your site.

It’s Simple … Yet It’s Not

Login interaction design is simple on the surface. There are, however, quite a number of elements that contribute to the final design considerations for a user login page. When they’re all combined, things can quickly get complicated. Here’s a sample of the factors to consider:

  • Security
  • Previous user experience
  • Site legacy procedures
  • Internal business processes
  • Page interface design
  • Audience platform considerations

You can probably think of a few more factors to add to that list. Regardless, there are still some simple things that we can focus on to ensure that the experience is a good one. Here’s my list of tips for making sure your users keep coming back and logging in.

1. Use email addresses for usernames

Studies have shown that people have enough trouble remembering their passwords, without them having to recall a username as well. Using a string that people are more likely to remember, like an email address, reduces the chance of the user forgetting their login details even further.

The convention for a web site’s username to take the form of an email address nominated by the user is becoming more and more established. Sure, there can be issues with the approach of using an email address as a username, such as:

  • Some service providers recycling email addresses
  • Users changing their name, and their email address as a result
  • Email addresses taking different formats

However, none of these issues are insurmountable—just be sure to allow (and test) for the different scenarios listed above.

The common alternative of forcing users to log in using a membership number (or some other username that is allocated to them) does not help at all. If you must use something other than an email address for your web site’s usernames, at least let your users personalise their account somewhat by creating their own username to use on your site.

2. Let Your Users Use Long Passwords

In this new age, we are constantly being reminded to use passwords that are secure. You know the drill—the longer the better; the more special characters the better …

With the advent of password-memorising plugins and browsers that automatically fill in usernames and passwords, one might expect that the average length of a password fields on today’s web applications would be getting longer and able to accept passwords that are 64, 128, even 256 characters long. One might even hope that the days of eight-character passwords were rapidly disappearing!

And indeed this shift to accepting long passwords is occurring. However we’re not there yet, and seem to be in a transition period.

Note that there can be problems when the text field for accepting a username or password is not the same length as the corresponding database field in which it is stored. This can result in the truncation of the password that the user entered, or even worse, in the entire record being completely unaccessible. If you offer long passwords, be sure to test them!

As an interesting side note, banks in general refrain from allowing passwords that contain special characters or passwords that are over 12 characters in length. This limitation is usually due to the limitations of the legacy systems with which they interact, not their web services. Most web services are not bound by such restraints—don’t follow the old model.

The solution is simple—plan to allow long passwords from the start. By getting it right in the design documentation, ensuring you define the length of the passwords, and testing for this upper limit, you should be able avoid any hurdles related to your password length.

Also be sure to inform user, at least during the registration process, exactly what the minimum and maximum password length is that your system allows. This should be implemented using a text message located next to the field in question. Users will not be aware of details like this unless you tell them about it!

3. Add some Ajax to your Form Validation

We are not all perfect—sometimes we mistype usernames and passwords. So do our users.

Of course, a password entered by a user needs to match exactly before we grant that user access, for security reasons.

However, let’s ease up a bit on the usernames. For instance, if the username was an email address, it would be nice as a user to know if I’ve accidentally typed “.con” instead of “.com”. It would even be nicer if this warning was provided before the form was submitted!

In this situation, a little Ajax-style validation can go a long way. Checking the username to determine whether it is unique or in the right format makes things a little easier.

Another factor to consider when it comes to validation is what might happen should the user enter an extra space or two after their username. You see, this whitespace is not going to be obvious on the screen to the user, but in reality they have entered an invalid username, as it contains extra spaces at the end.

This hurdle is simple to overcome—just trim the username field. You can perform this trim either on the client side or the server side (both is better). The important thing is to build some intelligence into your form validation, and make some simple, educated guesses at what the user intended their username to be.

4. Maintain Persistent Logins

There used to be a time when you could log in to a web application and remain logged in until you logged out! Remember those days? Isn’t that what the “Remember me” or “Keep me signed in” checkboxes were for? Sure, those web apps that offered this feature were not critical services like online banking or share trading sites. But boy was it convenient!

That feature seems to have gone out the window lately. These days the “Remember me” checkbox only means “remember me for a short period of time”. There is a distinct trend developing lately whereby web applications require you to log in again after one week, two weeks, or some other arbitrary time period.

Persistent Login Example

These time-limited persistent logins are of course a security measure, but they only apply to the computer being used. So if the computer is in fact located in a secure environment, the time-limitation offers no benefit to the user, and is inconvenient. It becomes annoying having to login again and again to a web application that you‘d rather use seamlessly.

Informing users how long their login will last for certainly helps manage expectations in this situation, but it doesn’t make the process of having to log in again every two weeks any less convenient.

A better approach would be to allow the user to control the period of time that the persistent login is good for. By giving the user control over this setting, we can keep everyone happy. A user who only ever access the web site from their home computer might set their login to “forever”, whereas another user who accesses the same service from a library or internet café might set it to “never”. After all, the login details belong to the user (as does the data that they access with it), so surely our users are intelligent enough to make this decision?

5. Keep your Text Fields Close Together

Placing a username field and its associated password field on a separate page is a practice that I encourage—having a dedicated “login” page is much less confusing than integrating the login process into another page, especially if that page contains other forms and text fields.

But how should our username and password fields be aligned? There are two main schools of thought—side-by-side and on top of each other.

The important thing is to ensure that the two fields are within close proximity of each other—remember, they are related in terms of information and functionality, after all. They should therefore be related spatially as well.

Login Layout Examples

Login pages can be problematic when the username and password are not located next to each other on the screen (believe it or not, I’ve seen this happen by up to a third of the page!) The area between a username field and a password field is no place for a big banner ad! Keep these two fields next to each other to reduce confusion.

It’s a minor problem, but making your user hunt around for the fields they need to use to log in, and raising doubts in their mind over whether they’ve entered their login information into the correct field—especially if they’re already further down the page—doesn’t really fill a user with much confidence about the web application.

6. Keep your Login Link at the Top

Just as users have come to expect that clicking a web site’s logo will lead them back to home page of the site, many users these days expect to see a link to the login page located at the top of the page (often on the right hand side).

Placing your login link elsewhere can result in visitors playing the “hunt for the login” game, which won’t help your cause. Sure, users of your application will become accustomed to where it is. however, when a new user is most vulnerable to frustrations (and will often make a lasting opinion of your site) is based on their first few experiences with your site, before they learn where various features reside. You only have a short window, so you want these experiences to be positive.

7. Label your Login Links

As you may have noticed, there are many established conventions when it comes to the login process, and the login label is no exception. The exact text that many visitors are likely to be looking for is either “login” or “sign in”. There are multiple variations, but these two words are almost universally understood, so are pretty safe options to use.

Unfortunately, there are web sites out there today (not naming any names!) that see fit to use unique labels to mean “log in”. In the worst cases, the link is given a label like “opportunity” or “recommendations” or even “new features”—none of which have anything to do with logging in. When users see a link in the location where they expect the login to be they begin questioning whether the link is an advert, and what the page behind that link might be selling.

Login Link Example

It can be difficult arguing the case when the marketing department are insisting that the login link be labelled something new or different. If you can’t win that battle, one compromise might be to add the marketing link in addition to a more standard login link. The confusion created by two links pointing to the same page is going to be less than that created by messing with a more standard link that visitors are expecting to find.

8. Let users retrieve forgotten usernames and passwords

Another convention that has become standard to provide a link for users to reset or recover a forgotten password, and to list this functionality on the same page as the login form.

However it can be a little distracting displaying this feature on the login page before a user has entered any information at all. It’s almost like taunting them by saying “Come on—I just know you’re going to make an error!”
It’s easy to fix—only display the link to your password recovery solution after a user makes an error logging in.. A little JavaScript that alters the text-indent property of the paragraph containing this link is all that is needed.
Another scenario to account for is when a user can’t even recall the email address that they used as a username. What should you do in this case?

This is easy enough to deal with—you already have that information available already, via your forgotten password functionality.

The error message displayed by the password recovery process is usually sufficient information for the user to determine whether he has entered the right username or not. For example, if the error reads, “No users have registered with that email address,” then your user will immediately know that the email he entered was not the right one.

There are, of course, other fallbacks that you can offer—secret questions, personal information about the user, and more. However, for most sites, a simple password recovery process is sufficient.

9. Display Helpful Error Messages

Error messages are notoriously problematic on the web—and in software in general. Yes, it’s important to inform your users when an error has occurred, but there’s no need to bamboozle them with technical jargon (nor should you be giving away more information than is necessary, in case the person reading the error message is a malicious hacker attempting to compromise your system).

Of course, there is the other end of the spectrum too—not giving the user enough information. Suppose you just wanted to log in to your favourite social bookmarking service. It’s not Fort Knox—people are not going to live or die based on your user knowing that they entered their email address incorrectly, so let them know. They’ll appreciate it much more than a terse message that tells them nothing and leaves them in the dark.

There is an art to writing helpful error messages—it sounds like I’m stating the obvious, but make them as clear as possible. Depending on the content delivery style, and the amount of freedom you have with the brand, you should try and engage with the user on a personal level.

For example, “Invalid authorisation” is robotic and confusing. “You seem to have typed in the wrong password” is a much more friendly way of saying the same thing.

For non-mission critical, low volume applications, you might even consider improving the user experience by going the extra mile and letting the user know which part of the username/password pair they entered incorrectly.
Finally (and this is really Usability 101), don’t insult people. Matthew Magain wrote about this on SitePoint previously, in relation to Reddit’s error messages. Remember: users aren’t stupid, they’re just human. Just like you and me, they make mistakes, and they’re often in a hurry. Allow for that the human errors that will inevitably occur.

10. Use Extra Questions with Caution

Including an additional question to authenticate a web user has become a popular method for applications that require higher levels of security, such as internet banking sites.

The question of whether this extra level of authentication is really necessary must be asked though—it may be possible to obtain this degree of confidence in the user’s authenticity another way (using an approach that requires additional server-side development).

Some examples include SMS code conformation, smart tokens and smart card confirmation (for extranet connections), enforcement of a stricter password policy, or the activation of extra questions only when an account is being accessed from a different computer to the user’s designated machine.

If you must ask your users additional questions, please consider using a question/answer format that is accessibile via a keyboard (i.e. doesn’t rely solely on a mouse).

Which brings me to CAPTCHAs. There is no shortage of people with personal hatreds for CAPTCHA systems. If you must use a CAPTCHA, do everything you can to make it as accessible as possible. CAPTCHAs are the exception to the rule in that they are better off located on the same page as the username and password fields.

11. Keep your Page Weight Down

Does your web application login page really need to have all those buttons and graphics that exist across the rest of your site? Think about it—the core function of your login page is as a transition to the main site. Your user wants to make use of the page, and then move away from it again as quickly as possible. Adding anything but the very basics in navigation and branding is going to slow the page down for your users.

Remember, not everyone is using a T1 connection to surf the Web. If a page simply takes too long to load, the user will start to ask questions like “Should I just do this later?” or “Is this worth doing at all?” If that user has a similar experience several times then she’ll start looking for alternative sites to visit instead.

Reducing page weight can often be very simple to do (just don’t tell the marketing guys!) Look at the page, and identify what can be classified as core to the use of the page on the site and still makes the page looks like it belongs. Remove the rest—sometimes this may even include part of the extended navigation system.
Of course this advice is irrelevant if your login process uses a JavaScript popup window.

12. A Word on OpenID

Hang on—what’s with this Number 12? Well, kids, think of it as a Christmas bonus for the holidays. Seriously though, the topic of logins would be incomplete without a little discussion on OpenID.
Many of you have no doubt been thinking while reading through this list that a good deal of these issues could be solved by using OpenID.

Now a debate about OpenID is off topic, but basically my point of view is that OpenID is just too hard for the non-tech community to use.

There I said it. It’s out. Whew, that feels better!

The paradigm of using a URL for a login is just too far removed from the expected behaviour experienced bv the general majority of people. Given a choice, most folks will fall back on the traditional method of providing a username/password pair—even if it does meaning that they will have more logins.

This will change over time. My hope is that one day OpenID will indeed become mainstream. But until some of the bigger players jump on board and allow interchangeable OpenID use, I would recommend against making OpenID the only way that users can access your web application.

Keep it Simple

Improving the login experience comes down to making the entire process simple for the user. Granted, achieving this goal means more work for the design specification, implementation and development of your web application. But what is building web sites really all about? The sweat and tears of the design/development team, or the satisfaction of the customer?

At the end of the day, it’s the customer who is paying the bills.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Gubbi

    OpenID could be much simpler if Blogger and wordpress supported it natively. And all the sites just ask users to enter their blog/website URL.

    Users pretty much understand what “enter your blog URL” means.

    Everyone has blogs these days like they have email IDs… if they don’t then sites can fall back to older methods of authentication.

  • http://www.doeswhat.com DoesWhat

    Completely agree with 12. OpenID is too complicated for anyone who only uses a few services, its not easy to remember which web 2.0 named OpenID provider you used (was it MyVidoop, Sxipper, IDtail, ClaimID, etc?) and how you protected your account (some use images as passswords and so forth) or sometimes even the ID you used.

  • toresteen

    Check out RPX at http://rpxnow.com which is offered by JanRain. This makes OpenID simple for any website operator. With a cool UI, it also makes it very easy for a user to understand what to do — they simply click on the icon for which provider they want to use (AOL, Yahoo, Google, MySpace, and even Facebook). To see it in action check out the login at uservoice.com.

  • http://manwithnoblog.com tuna

    @Gubbi problem is not everyone has a blog. There would I bet be more people knowing what a Facebook Page (account) was than a blog. So you need to engage all the players to adopt it.

    You have to allow for people outside the computer literate community that only use a computer to view a restrict list of web sites they are interested or interact with.

  • QMonkey

    A note on #9. Detailed error messages can give an edge to those trying to break in. If every failed login attempt was met with the same message, they won’t know if they’re getting closer. Of course, your real users won’t get that insight either but then they have the “forgot my info” link.

  • http://www.cemerson.co.uk Stormrider

    #2 shouldn’t be an issue, you should be hashing passwords anyway. As long as the database field can take the hash, it shouldn’t matter what string, special characters or whatever create that hash.

  • http://www.csskarma.com timwright

    Personally, I’m not a fan of the login thickbox/splash screen that’s been all of the internet lately. I much prefer the inline login like hulu and digg have in their header.

    • http://manwithnoblog.com tuna

      @timwright tend to agree with you on the thickbox login screens, they do disrupt the flow. But the biggest issue is that the login process often doesn’t work at all from the thickbox on certain browsers. Which really just indicates a lack of compliance testing. Personally not a fan of the inline login, yes it saves space, but I know from my own usability testing that some users have a lot of problems with using them.

  • Shantra

    I don’t agree regarding using email addresses as usernames. Today, it’s not unusual to change email addresses, for many reasons (like to avoid spam). I am quite sure that many users use the same usernames at many sites (Like “JohnDoe69″). These usernames is not that difficult to remember when used many times. And, it’s quite common to get a email copy of the username when registering to a site, so if one should forget the username, all you need is searh for this email.

    If an email username is used, it can be quite difficult to change it (if confirmation is needed). Example: If for some reason the old email addres has been closed, confirmation is impossible.

    In other words, I never use email addresses as usernames, and I have never had any complaints. OK, what if the user forgets the username, the registered email address (not username) has been closed, and they can’t find the confirmation email sent to them? Then their screwed, I admit that. But, what are the ods?

  • philmcdonnell

    I agree with Tuna about Facebook as it is all the rage lately, has anyone thought about and implemented the Facebook connect which allows your users to login to your site using their Facebook credentials?

    Phil

  • http://www.tyssendesign.com.au Tyssen

    About #11, a login page should be one of the lightest pages on your site already (it’s only a couple of labels/text inputs and a button after all), so I would’ve thought that if people are going to get put off waiting for your login page to download that they’re not likely to have that much better an experience with other pages that have more in-depth content on them.

    • http://manwithnoblog.com tuna

      @Tyssen Yes agree. However consider people are going to bookmark that page if they like your site and are going to return directly to the login page. There maybe no caching from a home page load of images and such as well.

      Making it as light as possible will reduce the load time. For example things like secondary navigation, links back to the login page, even general eye candy can be removed. This makes the page very streamlined for it’s sole function of the login process.

      It is marketing wise also very tempting to put banners on this page, but in reality you are just shunting the user off away from where they want to be if they click on the banner. So it is best to keep the login page simple and uncluttered.

      Place the banners on the post login page.

  • Anonymous

    Great article, and worth implementing – all interfaces should be polished to a shine, and login screens are as important as your application’s main function.

    I disagree with the last paragraph under number four, though. Preferences are evil, per Getting Real. Let your users tell you whether they are on a public or private computer, then just choose how long your users should stay logged in for them.

    Adding a drop-down box or any other sort of multiple or open-ended “remember me for x amount of time” will just complicate the login process and frustate your users.

    • http://manwithnoblog.com tuna

      @Anonymous Not really a fan of the the 37signals guys. Their processes tend to work for them and their company. That doesn’t mean they will for the rest of the world.

      These types of login preferences could be implemented with the general account preferences. In such a way that you get to nominate how long you want to be remembered for various login environments, such as home, office, public library and so on. I do loath however to even put anything else on the login page but the bare minimum.

  • roosevelt

    I really like this post, and the insights you’ve given are very useful. I completely agree with your view on OpenId, because very few of my clients even know how simple authentication system works, let alone openid :p

  • http://www.mikehealy.com.au cranial-bore

    passwords should be stored in a hashed form, so the DB field really only needs to allow 32 or 40 characters (depending on the hash used). Then it doesn’t matter if the user has a 20 or 200 character password or what characters it contains.

  • http://www.olsenportfolio.com/ nrg_alpha

    Very valid points. I would like to comment on tip #3 and #5

    #3:
    “For instance, if the username was an email address, it would be nice as a user to know if I’ve accidentally typed “.con” instead of “.com”. It would even be nicer if this warning was provided before the form was submitted!”

    If the user has javascript disabled, then this system would not work (granted, I realise most people probably do have it enabled). Point being, if you are coding a page using say PHP by example, one could code extra ‘error’ corrections even once the form is submitted. This negates any need for Ajax.
    #5:

    “Placing a username field and its associated password field on a separate page is a practice that I encourage—having a dedicated “login” page is much less confusing than integrating the login process into another page”

    I can’t say I agree here.. as a creature of lazy habit (I am not alone), I find it better to integrate a streamlined login field set along the top of a site GUI (which would be in itself a modular piece of code which can be revamped and have those changes propogate on every page site wide). I ask “Why make the user jump through an extra hoop of having to go to a login page if you can design a site that handles all this at the top of any page to begin with? Less hassle from the user’s stand point, the better. Integrate/streamline extra functionality (such as login systems) into an intelligent and well designed/built GUI makes life just a tad easier for someone wishing to login without extra clicks.

    Great article overall though!

    • http://manwithnoblog.com tuna

      @nrg_alpha Good points, thanks for the comment.

      With the Ajax error handling you could use a Hiajax type method or just retest (as you should anyway) with PHP at the backend.

      The main issue with the login fields at the top of the GUI is that this then needs to be replicated across all pages (as long as the user it not logged in). That’s a fair size of screen real estate. This also means you have the login fields, and the search fields all within a close proximity of each other. To avoid user confusion between these two functional elements you need to then place a good deal of design space between them or have distinct visual functional zoning of that section of the page. Combine this with a lot of navigational elements and you can end up with visual overload for the user if you are not careful.

  • Ben

    Third paragraph:

    all of those killer features you added will be in vein

    should be

    all of those killer features you added will be in vain

    unless you mean to refer to something that transports blood throughout the body.

  • http://www.olsenportfolio.com/ nrg_alpha

    @tuna

    Thanks for the feedback!

    With regards to integrating a login system within the header, have a look at this site as an example. Notice the header’s right-hand side built in login fields? It is clean, doesn’t occupy much space (even with the join / forgotten your password links). As a member (and assuming I don’t always have myself logged in), it is nice to know that these streamlined fields are always present at the top..so no matter which page I am on, I can easily log in without the need to go to a special login page. (I know this section isn’t based off the same exact exact code page to page, as the results slightly vary.. but the idea is there) It simply saves the need to go one extra step (which is to visit a designated login page).

    You are right on all counts.. this would mean that this system would have to be present on all pages (but this would not be a problem if every page within a site shares a well coded, modular template (for elements such as the header and footer by example).
    And indeed, you are correct that this would all have to be carefully designed and implemented. Not all (nor many) site do this well. But as an user, I personally prefer to have certain site functionalities (such as logins) upfront and accessable without the need to go to a specific page (this is of course, my personal opinion on this.. others may or may not agree). The least amount of clicks (browsing actions) on behalf of the user, the better.

  • Stevie D

    It becomes annoying having to login again and again to a web application that you‘d rather use seamlessly.

    Most websites I use that have that kind of time-limited login start the clock again every time you visit the site – so if the login remains valid for two weeks, and you visit the site every week, it will never log you out.

    Only display the link to your password recovery solution after a user makes an error logging in.

    That’s unhelpful for people who know they have forgotten their password, and/or the email address they used. I agree that, on a content page with a login form, providing these options is unnecessary, but I would definitely want to see them on a login page. A lot of people will be reluctant to enter a username and password that they know is wrong, because at that stage there is no indication they will be able to recover their password once they have logged in.

    Gubbi:

    Everyone has blogs these days like they have email IDs…

    No they don’t. A small proportion of net-savvy people (the sort who are least likely to forget their passwords or have any difficulty in logging into a site) do, but the majority of web users don’t have a blog and a high proportion have never knowingly read a blog.

  • http://www.patricksamphire.com/ PatrickSamphire

    Most websites I use that have that kind of time-limited login start the clock again every time you visit the site – so if the login remains valid for two weeks, and you visit the site every week, it will never log you out.

    Which is fine until you come back from a relaxing vacation and find that you’re logged out from every single site you normally use. It’s a pain. Leave me logged in forever.

  • http://www.aarontgrogg.com aarontgrogg

    3. Add some Ajax to your Form Validation

    For instance, if the username was an email address, it would be nice as a user to know if I’ve accidentally typed “.con” instead of “.com”. It would even be nicer if this warning was provided before the form was submitted!

    In this situation, a little Ajax-style validation can go a long way. Checking the username to determine whether it is unique or in the right format makes things a little easier.

    Why would you need Ajax to check for “.com”? JavaScript, yes; Ajax, no…

  • http://manwithnoblog.com tuna

    @nrg_alpha – thanks for the example, this does then bring up the screen real estate problem if you include the search field as well in it’s expect location of the top right hand corner. It usually does however come down to the login or search. For the sake of findability search will usually win. Of course this is really determined by the core function of the site and the audience as you would expect.

    @aarontgrogg – you can extend your simple javascript validation as you have pointed out, to full a full ajax call to the server. Depending on your server specs you could use server side validation to fully query the username etc, not saying that you have to display the full error or confirmation, but at least you would know the outcome. Save exposing what you are testing for client side. However the method is not that important the thing to remember here is just to help out the user a little, make the experience a pleasant one, after all you really do want them to return and login again and again.

  • Schmoo

    Re #8: When I’m on a site I have a login for but can’t remember my password, I want to see the forgotten password link on the login page. I have a new password for every site, and I could be there forever trying to guess which one it is, so trying the login form even just once is unlikely.

    I, as a developer, know that there’ll probably be a link appear when I try to login and fail, but I wouldn’t expect Joe Average to know that. I’d expect Joe Average to be swearing at the login page, poking around the menus wondering why the site is dumb enough not to have the forgotten password feature I’m looking for.

    I’m confident in predicting that this scenario is far more common than people feeling patronised by a forgotten password link. I’m also perfectly comfortable in branding those that feel patronised as over-sensitive, and in need of a little tough love by way of patronising :)

  • http://www.fiveminuteargument.com 5minuteargument

    Excellent advice, except for one point with which I’d like to respectfully disagree:

    only display the link to your password recovery solution after a user makes an error logging in

    Are you really suggesting a user should try to login first before they have this option? What if they come to the site and know right away that they’ve forgotten their password? Is ‘hunt the password recovery link’ really any different from ‘hunt the login link’?