Beautiful identifiers
In the vast area of mistreated design elements, there is one which is implemented consistently wrong: the identifiers.
In IT, identifiers are everywhere. Make a purchase on Amazon, and your order gets an identifier. Once the package is shipped, the shipment gets an identifier too. Identifiers which remain internal to the system could be of any format; even a GUID—for non-technical readers of this blog, GUID is a specific format which looks like this: df1c2f07-fecc-46f1-b5e4-71bc3f460b6e—is perfectly fine. However, there are identifiers which escape: they are shown to end users, and sometimes users have to type them, spell them, or even remember them. It's about those identifiers I will talk now.
Spaces
Try to type the following identifier: 5409913558592374. It's pretty hard, since there are eight meaningless digits to remember. The same number written slightly differently becomes slightly easier to type: 5409 9135 5859 2374.
For the same reason, phone numbers have spaces in them. It is for the very same reason that your credit card number is formatted as a series of, usually, four digits.
Most identifiers don't use spaces as a valid character internally. This makes it a perfect opportunity to use this character to simplify the life of your users:
Do display spaces in identifiers. This applies even for short identifiers: 45034 could be displayed as 450 34; although, identifiers shorter than five characters don't benefit from spaces.
Don't forbid spaces in input fields corresponding to identifiers. Typing an identifier involves potentially two tasks: writing the identifier and checking that what you wrote is actually correct. When spaces are forbidden in fields such as credit card numbers, the second task becomes unnecessarily complex.
It happens that the identifiers have to be copied to a third-party which doesn't handle spaces well. In this case, instead of actually displaying spaces, the blocks which have to be visually separated can be placed in <span> blocks which have a specific margin. If there are no spaces between the <span> elements, the identifier will be copy-pasted with no spaces.
Leading zeroes
Imagine you're on a phone call with a support person who is asking for the tracking number which is 008291. Depending on the language you use and your proficiency in this language, the leading zeroes could represent a real problem. “Doubly-zero”? “Double zero”? “Zero zero”? Or maybe “Two zeroes”, which could be understood as “20”?
There are also slightly more technical aspects. Displaying those zeroes usually requires additional code, which translates into a few edge cases. For instance, if five digits should be displayed, what about numbers bigger than 99.999? Also, making an arbitrary length limit will haunt you sooner or later when the project you work on will start to scale really fast.
Last but not least is the semantic problem: a number is a number; “0027” and “27” may be two different entries for a programmer, but for an ordinary user, they are the same numbers, and zeroes make little sense (and look ugly).
- Don't display leading zeroes.
Control key
For long identifiers, having a control key could enhance the user experience a lot. A control key is one or two digits which make it possible to tell in most cases that the identifier is invalid through a simple computation, without doing a lookup: the benefit is to be able to give a hint to the user before the user submits the form.
Unfortunately, this doesn't show to the user the location of a mistake. The only benefit is to have an immediate response, avoiding a few seconds roundtrip to the server.
- Use a control key for long identifiers if their lookup takes too much time.
Encoding
Similarly to the well-known xkcd suggestion, an interesting alternative is to encode the identifiers as a series of words in a circumstance where those identifiers have to be communicated by phone. As with passwords, what is important here is entropy; in other words, with a small dictionary, one can encode really large identifiers, and I would rather prefer telling “Correct Horse Battery Staple” than “6Z00148794199” by phone.
Note that shorter identifiers aren't necessarily better. I'd rather prefer using an ID such as “53 93 87 64 20” than a shorter “fM:8_k$.” With words, you get the best of two worlds: worlds are easy to communicate by phone, and the identifier such as “Correct Horse Battery Staple” contains only four of them.
This, however, has its limit: many users, when asked for an identifier, will search for something which looks as the identifiers they know. A set of words doesn't look at all like this, and could easily be dismissed. However, in circumstances where the confusion may be avoided, such identifiers could present a very interesting alternative to the usual ones.
- Get the encoding right to achieve shorter identifiers composed of easily recognizable entries.