Usability clanger in one-time token

(Oliver Moran) #1

One of our users was confused by the following message in the sign-up process:

To log in again, click the following link to choose a password: [URL to one time token]

What happened was that the next time they tried to use the site, they clicked on this link expecting it to allow them to “log in again” (or to “choose a new password”). However, the site said:

Sorry, your token has expired. Please try resetting your password again.

They didn’t know how to proceed.

(Jeff Atwood) #2

Hmm, yeah, I’ll edit to improve that text, so now it reads

Click this link to choose a password now:

If you don’t remember your password, or don’t have one yet, choose “I forgot my password” when logging in with your email address.

Not sure how else to improve this at the moment, but that seems like a good start?

(Oliver Moran) #3

I’d suggest adding clarity that the link will expire. Example:

Click this link to choose a password:

You will only be able to use this link once and it will expire
automatically in 24 hours.

(Jeff Atwood) #4

I think that’s Too Much Information personally. If it’s expired, they can find out at the time they click, and we should improve the

Sorry, your token has expired. Please try resetting your password again.

message instead. I think

Sorry, that password change link is too old. Log in again and select “I forgot my password” to get a new link.

Is better reading for humans.

(I am a big believer in the Just In Time principle.)

(Oliver Moran) #5

Yes, that sounds good - except that they can’t “Log in again” if they’ve forgotten their password … but I get what you mean :slight_smile: I presume it’s possible to detect that the link has already been used, and to say that too, if it was the case?

The reason I suggest a note explaining the expiration rule is for transparency of the system state and behavior. I think you’re right that the system can better help the user recognise and recover from this particular “error state” when it happens. But preventing the error state to begin with would surely be more desirable?

The only way I can think of doing that simply is by exposing the system state and mechanism in the email through relevant documentation.

Imagine a real world equivalent: someone gives you the key code to access a door in a basement.

They say, “Use this key code open the door,” but they don’t tell you that the key code is valid for one time use and only good for today. Now, if you ever try to use that key code a second time or wait until tomorrow, the door could give you a nice error message telling you that they code has expired - but wouldn’t you be left thinking, “Why didn’t that ahole tell me it was a one-time code when he gave it to me?”

The more human thing is to tell the person that they key code is one-time only and only good for today when giving it to them so that they avoid making the mistake in future.

(Oliver Moran) #6

By the way, this is my paradigm for thinking about usability:

(Robert) #7

I set up twitter and google login and I would like to suggest new users to take advantage of that. So far it works like this:

  1. user gets invited and accepts link (to edit topic)
  2. user receives an invitation to create a pw (quoted mail)
  3. user ignores this mail
  4. user tries to login using twitter/facebook account based on the known mail address

Step 3 & 4 are not obvious at all and I would like to see this opportunity promoted. What do you think?