To Dash or Not To Dash
February 23rd, 2006
If you’re a TiVo owner, the company will occasionally notify you of a new service or software upgrade available for your recorder. The TiVo folks, knowing that you may be very excited to get the new features, gives you a chance to sign up for the priority upgrade list, allowing you to be one of the first in your neighborhood to get the newest and greatest.
Signing up is straight forward. The only information you need is your TiVo Service Number:
What? You don’t have your number memorized? No problem. If you’re a TiVo Online User, the very same web site that is asking you for the number actually has it stored away for you to access:
All you need to do is write it down, go back to the type-in box, and type it back in. Or, if you’re a sophisticated, advanced, know-everything-about-the-web user, you can select the number, use the browser’s Copy function, and then paste it into the type-in field:
But wait, that doesn’t work. The damn dashes! To enter a valid number, you need to go back and remove them all:
There’s two things wrong here:
First, why not accept the number with dashes? How hard is it to write code to strip dashes or spaces out?
TiVo service numbers are not the only fields with this type of problem. Social security numbers, phone numbers, and credit card numbers all have dashes and spaces in the awkwardest of places. These are used as aids to help users remember their numbers and reduce mistakes.
Yet, in the place you most want to eliminate mistakes, the type-in field, we force users to eliminate these aids.
It’s always ironic to me when a site doesn’t accept data in the format it displays it in.
The second wrong thing is a bigger picture issue. The site already had the number. Why make the user type it in again? What value did that add?
This is a prime example of Tool Time. Tool Time is time a user spends futzing with a tool instead of getting their real work done. Tool time is something we try to eliminate. The time it takes to login, find the screen with the service number, copy it, return to the original field, paste it in, and remove the dashes, could all be eliminated with no reduction in the quality of the result. User wins. TiVo wins. Everybody wins.
Are you looking for places where tool time happens in your designs? Are you working to eliminate it?
[Gratuitous Plug: Christine & I will be talking about techniques to discover tool time in our upcoming UIE Roadshow, the first of which is taking place in Atlanta this week. A few seats still available for all six cities. More information is here.]
February 23rd, 2006 at 9:50 am
In the early ’90s I worked on a DOS-based DBMS which supported “pictured” fields in its forms, where the programmer could specify the format (e.g., “(###)###-####” for a North American phone number). The user was allowed to type format-specified delimiters to make the entry easy to check. If the user didn’t type the delimiters, they were put in automatically (sort of like cell phones today), making for fast data entry *and* easy checking. If the user typed a character not allowed by the format, the typing was merely ignored, as opposed to letting it be entered, then throwing a blame-the-user “invalid entry” error back when the data are submitted. It would seem the UI design practices of many web page forms remain stuck in the 1980s.
February 23rd, 2006 at 11:53 am
Nearly as bad are the inverse cases: the fields that require you to use a specific delimiter pattern, like 123-456-7890 when you’re rather type (123) 456-7890 or 123.456.7890 or even just 1234567890.
Whenever I see that kind of thing, I think to myself: a lazy programmer passed this way.
February 23rd, 2006 at 12:12 pm
First, why not accept the number with dashes? How hard is it to write code to strip dashes or spaces out?
The regular expression to remove dashes from a string, which can be used in javascript, java, perl, etc., etc., is
s/-//g
That’s it!
February 23rd, 2006 at 12:51 pm
It’s a constant problem we see when evaluating website usability. Even worse, when there is no clue upfront and you only find out what format is required AFTER submitting your information.
February 23rd, 2006 at 12:53 pm
PS. The most excellent book by 37 Signals, “Defensive Design for the Web” covers this topic really well, and is a must read for any design/usability professional.
February 23rd, 2006 at 4:44 pm
This has to be my #1 pet peeve in e-commerce. Soooo easy to fix, too.
I disagree with Ezra, though: the best way to get around this problem is to use whitelist stripping, in which you remove everything *but* the characters you know to be good.
In this case, we would want to remove everything that’s not a numeric digit or A-F (case insensitive):
s/[^0-9A-Fa-f]//gNot exactly rocket science.
February 23rd, 2006 at 4:52 pm
You should thank them that they didn’t provide you with handy-dandy 4 separate text fields (one for each part). That way you wouldn’t be able to past the entire number at all. Duhhh..
February 24th, 2006 at 6:18 am
Couldn’t agree more Vitaliy. While I’ve encountered the dashes problem a few times, I’ve tended to run into the 4 separate text fields problem more often, and it is sooooo annoying!
March 3rd, 2006 at 8:16 pm
That functionality saved a programmer at least 10 minutes of time: 30 seconds to find the example code on google 1.5 minutes to implement 4 rounds of testing at 2 minutes each Who cares if it aggravated every single user on the site? Those are REAL hours… Er, minutes… I can’t tell you how many times I’ve had this argument with a programmer and the argument usually ends up with me finding the example code for them. Not to mention the conversations involving you, the programmer, the project manager and two business analysts, the total bill for the conversation far exceeding the amount of time required to write the World’s Greatest Phone Number Validator(tm) in Java, C++ and Ruby combined, with enough left over to throw in some client-side javascript validation for good measure.Heck, at most bill rates you might as well outsource the number validation to a 3rd world country and do each and every one by hand if you’re even going to waste five minutes talking about whether or not to implement it.
March 8th, 2006 at 12:27 pm
Even worse are the fields that not only require that you type the value without spaces or dashes, but also place a limit on the number of characters entered. If you type or paste the phone number 206-555-1212 into such a field, you will get just 206-555-12 — you have to manually delete the dashes and manually type the missing digits (which you might not even know, if you just copied and pasted the value from a window that is now closed). I see this all the time for credit card numbers — so often that I have developed the habit of typing credit card numbers without spaces.
It’s appalling.
March 8th, 2006 at 12:31 pm
David wrote:
I’m thinking there’s going to be a special place in hell for the developers who perpetuate these crimes.
March 8th, 2006 at 5:22 pm
For as long as there’s been code, there’s been a lack of all the right code in all the right places, and we usability nuts have complained about it. There will be no end to the problems and no end to the complaining if we don’t seek out systemic solutions. Every highschool programmer is repeating this problem all day long because all software development starts over again from a blank page instead of from a robust, usable solution and working in the other direction. Progammers aren’t any lazier or culpable than we usability folks. They are working in an unreasonable set of circumstances.