3

A user recently inquired (OK, complained) as to why a 19-digit account number on our web site was broken up into 4 individual text boxes of length [5,5,5,4]. Not being the original designer, I couldn't answer the question, but I'd always it assumed that it was done in order to preserve data quality and possibly to provide a better user experience also.

Other more generic examples include Phone with Area Code (10 consecutive digits versus [3,3,4]) and of course SSN (9 digits versus [3,2,4])

It got me wondering whether there are any known standards out there on the topic? When do you split up your ID#? Specifically with regards to user experience and minimizing data entry errors.

LesterDove
  • 3,014
  • 1
  • 23
  • 24
  • I'm not sure about the usability, but it's a good way to help client to remember account numbers. In France phone numbers are on 10 digits too, we separe them two by two, because it's easier to remember 5 numbers between 00 and 99 than a number between 0100000000 and 0599999999. It's just a mnemonic help. – Colin Hebert Aug 23 '10 at 21:23
  • Do users have to remember and type in that 19-digit number every time they login? If so, OUCH!!! The best pseudo-standards I've seen involve letting the user use his email address, OpenID or an alphanumeric username of their own design. – Bob Kaufman Aug 23 '10 at 21:23
  • @BobK, agreed on all those approaches. But I'm looking for insight on the long ID number issue in particular. Let's say it's an ISBN Number or Airline Reservation Number or whatnot, if you don't want to tolerate the idea of a long Account Number :-) – LesterDove Aug 23 '10 at 21:28

3 Answers3

4

I know there was some research into this, the most I can find at the moment is the Wikipedia article on Short-term memory, specifically chunking. There's also The Magical Number Seven, Plus or Minus Two.

When I'm providing ID's to end users I, personally like to break it up into blocks of 5 which appears to be the same convention the original designer of your system used. I've got no logical reason that I can give you for having picked this number other than it "feels right". Short of being able to spend a lot of money on carrying out a study, "gut instinct" and following contentions from other systems is probably the way to go.

That said, if you can make the UI more usable to the user by:

  • Automatically moving from the end of one field to the start of another when it's complete
  • Automatically moving from the start of one field to the prior field and deleting the last character when the user presses delete in an empty field that isn't the first one

OR

  • Replacing it with one long field that has some form of "input mask" on it (not sure if this is doable in plain HTML, but it may be feasible using one of the UI frameworks) so it appears like "_____ - _____ - _____ - ____" and ends up looking like "1235 - 54321 - 12345 - 1234"

It would almost certainly make them happier!

Rob
  • 45,296
  • 24
  • 122
  • 150
2

Don't know about standards, but from a personal point of view:

  • If there are multiple fields, make sure the cursor moves to the next field once a field is full.
  • If there's only one field, allow spaces/dashes/whatever to be used in that field because you can filter them out. It's really annoying when sites/programs force you to enter dates in "dd/mm/yyyy" format, for example, meaning the day/month must be padded with zeroes. "23/8/2010" should be acceptable.
Richard Fearn
  • 25,073
  • 7
  • 56
  • 55
  • Totally disagree on the first point. AT&T used to this when entering the phone number. The problem with this is that if you mistype one of the numbers it auto jumps you to the nest box. Then when you go back to correct your mistake you are jumped back to the next box (because the first one is already full). There is nothing more annoying. Pressing tab is totally acceptable and, IMO generally more standard than auto advancing the cursor. – Brad Cunningham Aug 23 '10 at 21:54
  • 1
    In that case, it shouldn't have automatically gone back to the empty box when you went back to correct a mistake in the full one. Jumping to the next box should be done following a keypress, not whenever the full box has focus, for precisely this reason. – Richard Fearn Aug 24 '10 at 09:41
  • As for tab being standard, I'm always amazed at how many people *don't* know that pressing tab advances to the next box, and grab the mouse to move to the next one. For me that makes automatic jumping the better option. – Richard Fearn Aug 24 '10 at 09:43
1

You need to consider the wider context of your particular application. There are always pros and cons of any design decision, but their impact changes depending on the situation, so you have to think every time.

Splitting the long number into several fields makes it easier to read, especially if you choose to divide the number the same way as most of your users. You can also often validate the input as soon as the user goes to the next field, so you indicate errors earlier.

On the other hand, users rarely type long numbers like that nowadays: most of the time they just copy-paste them from whatever note-keeping solution they have chosen, in whatever format they have it there. That means that a single field, without any limit on lenght or allowed characters suddenly makes a lot of sense -- you can filter the characters out anyways (just make sure you display the final form of the number to the user at some point). There are also issues with moving the focus between fields, with browsers remembering previous values (you just have to select one number, not 4 parts of the same number then), etc.

In general, I would say that as browsers slowly become more and more usable, you should take advantage of the mechanisms they provide by using the stock solutions, and not inventing complex solutions on your own. You may be a step before them today, but in two years the browsers will catch up and your site will suck.

Radomir Dopieralski
  • 2,557
  • 17
  • 14