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’?

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 :)

@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.

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…

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.

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.

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.

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.

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.

#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!