 |
A project to make businesses more aware of their customer experience, and how to fix it. By Mark Hurst. |
| About Mark Hurst | Mark's Gel Conference | New York Times Story on This Is Broken | Newsletter: Subscribe | RSS Feed |
Search this site:
Categories:
- Advertising
- Current Affairs
- Customer Service
- Fixed
- Food and Drink
- Just for Fun
- Misc
- Not broken
- Place
- Product Design
- Signs
- Travel
- Web/Tech
Previous: Infected Sony music CDs | Main | Next: Shower signs
November 17, 2005 12:02 AM
Broken: Google AdWords error response
This Google AdWords form is both dumb and condescending.
First, it doesn't know what to do with the dots in my phone number - it can't figure out what 212.736.2075 means, so it brings back an error message.
Second, it tries to educate me that "U.S. phone numbers are like NNN NNN-NNNN"... after living in the US for over 30 years, I don't need a Web form to educate me on that point.
Google should fix its field check!
Uhhh. thats because you are putting in your number as an ip address, who has ever put their number with full stops?
On top of that, I disagree with Google. From my 34 years of US experience, US numbers "are like" either
(NNN)NNN-NNNN or NNN-NNN-NNNN
I never use a space after the area code...
I have another complaint about the Google Adsense form. It does not allow you to use a PO box in the address. I can understand that sometimes a physical address is required, but that is not always a valid mailing address. In my case, the postal service does not deliver mail to my street address. You have to include the PO box or it will be returned to sender. I usually include both my street address and the PO box when filling out forms like this, however, the Google form rejects anything containing a PO box. Broken!
Sorry guys, I gotta call "not broken" on this one. Obviously none of you that have posted thus far are programmers. I've been in software development for 6 years and let me tell ya, you can't write tools that allow ANY kind of input.
So they fix their phone number recognition software to accept periods. Next someone will try using slashes (/), and someone else will use commas. Then you have to worry about the number of spaces people try to put between each set of numbers, if hyphens are included or not...it's no simple task. You have to draw the line somewhere.
Besides, the only place I've ever seen people use periods to separate their phone number is on business cards when they're trying to look sleek and cool. It's not a format that's taught in schools, and it's not the display format used in address book software packages.
As for their error message, how is it insulting? They expect the number in a certain format, and you didn't fulfill that. Would you rather they just say "Sorry, we didn't recognize the phone number. Don't expect us to tell you what you did wrong, though."
Users are broken.
Manni's right about one thing: It's not broken to show you the correct format; it would be badly broken *not* to.
But I disagree about writing tools that accept any kind of format. It is not difficult at all to write code that plucks the first seven digits out of a string and ignores everything else. It's not even hard to make that same code pluck the first eight digits if the first digit is a 1. And if you don't want to go to that trouble, then put three fields on the form that accept only the correct number of digits.
Manni:
I have been an application developer, and managed a web development team. Of course you cannot accept completely arbitrary input. But you can accept reasonable input. Putting in code to strip out the common phone number part delimiters is not hard. Furthermore, the use of periods as delimiters is not common in North America, but is more prevalent in Europe.
OK using the dots is a bit silly, and certainly is nonstandard. But it is a form of sillyness you see more and more in the US. So their input form should allow for it.
Incidentally Karen you are quite correct. The normal for of a number is (999) 999-9999. I wonder if their form will take this?
As mentioned here- your form validation should be able to strip out the crap and grab the correct numbers.
How about this- someone spend some time building the best darn phone number parser EVER for each country- (or better yet- one that can handle ANY number regardless of country) and everyone can freely use it in whatever scripting language/form validation they have.
Some kind of immediate updating (like say, AJAX) can let you know "(123)123-1234 is this correct?" before form submission- This same code would possibly even allow you to do a country switch- you could enter something like
-us 1231231235 and it would parse it for the US
In any event- the bigger problem is that there are so many different implmentations of validation, and so many different ways of entering, that it's no wonder no two users use the same method of input.
Broken
As someone who parses phone numbers on web forms all the time, I wrote a parser that will take pretty much anything, even:
123 456-A7B8C9D0
It strips all non-numeric codes out and then looks at the 10 resulting digits and breaks them apart as necessary.
It's not as hard as it looks.
It's sort of like the "please don't put spaces or dashes in credit card numbers" thing - you know, because string processing is difficult in computers or something.
The day you have to format something just because a computer can't deal, is the day the programmer got really lazy.
Stoo: Your idea works best, in my opinion. The downside is that it only works for US phone numbers, but it's not that big a deal since most of the rest of the world still operates via carrier pigeon or town cryer.
Ray: Even if it's becoming more common, my point is that you shouldn't have to constantly update software simply because people are using different delimiters in their phone number. If I start typing in my phone number as 987*654*3210, should I expect forms to accept that?
It's about reducing problems. If you restrict the input format, you reduce the risk of pulling out the wrong data. How many formats are allowed when you enter your bank account information for direct deposit or paying bills online, or for entering your credit card number for purchases? Probably only one format, with no spaces or delimiters. The reason is to make sure the wrong account doesn't get charged. How is this any different?
Paul: Writing a parser like that is easy, true. But was that the phone number the user meant to type in? You're going to blindly accept whatever input is given as long as you can find at least 10 digits? Chances are you'll now have the wrong phone number on file, rather than prompting the user that their number looks wrong and asking them to correct it.
Do you want to be held responsible because someone typed a credit card number wrong and it charged the wrong account? Stop treating users like they're incapapable of adhering to a standard format, make them take some accountability for their actions.
I like Paul's idea. If you're as likely to get a wrong number as Manni suggests show them the stripped down number on the next page and ask them if all the information is correct.
Manni, are you kidding? Who cares if they use commas or periods or whatever? You don't look for =( or =. or =/. You look for !=number.
You can write a function that takes the phone number string and tosses anything that isn't a numeric character in about a minute. That's a programming 101 exercise. In fact, I took a C class way back in college where an early assignment was just that: pluck the ten digits of a phone number out of any random way of entering it.
The followup was the ability to convert letters to their phone button equivalents, and detect whether it was a 7 or 10 or 11 digit entere and strip out the leading 1 for the 11 digit. That was about another minute.
The only thing you can't fix is transposed numbers, or just someone entering a wrong number, but now you're finally in the realm of the user's problem.
I'd fire any programmer who gave me a web form that needed the phone number in a precise and specific format.
Manni -- you need to spend a few more years in software development before making statements like that. I've personally written routines that accept a very wide variety of date formats, accept an expression for a number, etc. This one is trivial: just disregard *any* punctuation since phone numbers are all digits.
The one that annoys me more than this is credit card numbers where they insist that you do/don't enter the spaces. What's so hard about ignoring spaces?
I wasn't saying that a specific format is required, I'm saying that by restricting the input, you reduce the likelihood of stupid errors. I've already agreed that writing a function to pull numbers out of a string is a trivial task, my point is that you'll most likely have the wrong phone number in the end because the user fat-fingered some keys.
What would you do to a programmer that allowed an incorrect bank routing number that charged the wrong customer's account? Give him a raise for not restricting the user input?
Sorry dude, I'm a competent human being that can type in a phone number as I'm expected. AFAIK, we all learned the (xxx) xxx-xxxx format, why are you inventing methods to deal with people that can't resist breaking from the norm?
Universal validator for US phone numbers:
s/(\+?1)?[^0-9a-zA-Z]*([0-9]{3+})[^0-9a-zA-Z]*([0-9]{3+})[^0-9a-zA-Z]*([0-9]{4+})/$1-$2-$3/
Adapt for your language's local regexp syntax as necessary.
If you want to store international phone numbers, you should use international phone number format, which is +(country code)(phone number). Spaces don't matter, everything else is stripped out. For example, a US number would be +15055551212, while the Somalian idiots who keep on calling me at 4AM would be +2525653428 (an American would dial that as 011 252 5653428).
Broken.
I'm not going to be dragged into all the programming geekery; suffice it to say that the user is the customer and the customer is always right.
I spent over 20 years making computers go faster and memory chips hold more data, only to see most of my 10,000X performance gains squandered by programmers that still can't get most computers to start up quickly, keep running, and shut down smoothly. Pardon me if I'm more than a little bitter.
Manni: Restricted input can cause the correct number and type of characters to be entered by the phone number, which reduces, but doe snot eliminate data entry error. It also has the side effect of suffering from poor usability since the data is so structured.
Parsing out the delimiters in a phone number is NOT the sames as attempting to turn any sort of input into a phone number. If somebody types in a phone number of 893487348787348953893993, I think it would be quite valid to reject it. But of if the phone number were 205.987.6576, what would you expect the likelihood be that the user has in fact keyed the correct number? Removing teh delimiters likely results in a correct input. Furthermore, the form is more usable as the the phone number keyed in matches to the way the user would naturally write the number.
Wow, clearly I'm in the minority here. Unless, of course, you actually go to any website and look up where they have the phone number inputs. I checked my bank's website, two credit cards, and various magazine subscriptions I have, and ALL of them broke up the phone number into three text boxes in which you could only type numbers. The length of your entries was limited to 3 digits, 3 digits, and 4 digits, respectively.
Whew, it's a good thing those websites don't force users to enter data in a specific way.
Manni-
All of those sites are too constricting. It's bad design. The Opera browser has a notes feature that can act like a form filler- you can paste info into forms. I like to be able to just paste a phone number into a from and not have to break it up into three entries. Then you have the forms that autofocus the next field, while some forms don't.
In a nutshell, restricting input reduces problems, but at the cost of usability. There are times when that cost is (possibly) warranted- like say, your bank routing example- but there are also times when it is more important to allow the usability to shine through.. like say a phone number for a users personal information.
personally- I hate the forms that break it up into three different parts. It's one item.. a phone number. It's not three items. If the script can't figure that out, it's just plain lazy.
The simplest and easiest control for entering a phone number is a simple text input allowing the customer to just free-form key the number. When sites try to get all fancy, strange results occur. A common problem is the use of java script to automatically tab to the next segment of the phone number to overcome the restrictions of the segmentation of the phone number into separate fields. Try back-tabbing after entering an incorrect area code, and you've been auto-tabbed to the next phone segment in the Kitchenaid product registration site.
https://www.registration.whirlpoolcorp.com/registration/step2.asp
and finally-
What if we are submitting phone number to a business listing and want it to display as "1 800-PLUMBER" or something? If the submission engine/script only allows numbers, the price you paid the telco for that number isn't worth nearly as much since now your customers will see a less than easy to remember number.
back to the google screenshot: What if I have a five digit extension? Three digit? Am I out of luck?
and really finally-
Regarding the picture and the error messageL
It's not clear from the picture- does the form tell you the format they expect it in BEFORE it's been entered? (like when it says the format in the text box, but the instructions disappear on focus) If not, I would say it's further broken for not telling the expected format upfront. You can't tell the user after the fact.
About credit cards-
People naturally parse the extremely large number into chunks anyway- that's why the number has dashes or spaces on the card. So why prohibit that when entering information?
As others have said- parsing for meaning is not the same thing as taking any piece of information and trying to make it fit.
But a good lesson in regular expressions needs to be taught to all of these number validator.
Also, see this site:http://www.unixwiz.net/ndos-shame.html
Uh... of course any form can accept virtually anything. BUT... what's going to read the code? If it's a human, anything goes. If it's sent right to a datbase... game over. These forms are written to write directly to a database and that's the format their database requires.
You wanna re-write the database to accept anything as well? Now that would be a neat trick. In fact, if you could, you could probably retire with more money to burn than Gates.
Absolutely not broken. Written for the specific database they're using to accept it.
Good grief- I totally agree with you g_guy- but as we have said before- there's a difference between meaningful parsing of data and just accepting a string of junk.
Sure you have to take into account data format. And who doesn't backend validate before dumping in the database? That's just plain dumb to dump straight to DB. That still doesn't alleviate you from your responsibility of assisting the user.
I don't understand developers that figure out reasons why not to do work instead of just doing it right.. I think JL said it best up there- the customer is always right. Suck it up.. LEARN REGULAR EXPRESSION! Reg ex out the crap, parse for a meaning piece of data, and prompt the user to make sure that it's correct. You can do those things pretty easily and non-intrusively if you have any sense. We're not saying no holds barred- but if the user wants to use a dash, or a paren, or a space- let them! Just because they prefer to enter it one way doesn't mean you have to store it that way.
BTW- even if it is not going straight into the database- you still have to validate it possibly an HTML encoding if it applies.
...and if the DB they are using does not accept a '.' character, then I think google has bigger problems than form validation.
I just keep a nondelimited version of my credit card number on my encrypted note file where I keep all that kind of stuff for easy cut-and-paste access. I use my nondelimited version to past into forms.
That said, the lazy web programmer phenomenon with credit card numbers, phone numbers, and other variably delimited strings certainly is one of my pet peeves... ;-)
Manni, it's called SOFTware for a reason. I don't care if the user inputs 123@456)9876, the basic format is some kind of delimiter seperating 3 digits from 3 digits from 4 digits. It's not that d**** hard to figure out a range of ascii codes for NUMBERS. You can change it.. you can do whatever you please. Hence SOFTWARE.
Someone mentioned letters above... good point. Still not that difficult to have a table to refer to. A=2, B=2... yadda, yadda....
Absolutely the credit card number LAZY A** programmer problem is ridiculous. It's 16 freakin' digits. SO WHAT if I have a space or a dash or nothing at all- FIGURE IT OUT. Citibank allows virtual account numbers to be generated online. Use the web version and you get a 16 digit string. (right clicking is disabled (WTF?!), you need to use a shortcut key to copy) Which of course, does NOT fit into the average form, where it's sets of 4 boxes, or asking for spaces or whatever.
Eddie: you have too much free time on your hands to post that much
Yep: I'm not getting your "SOFTware" comment. How does the name imply that it should accept anything?
Eddie (again): If it's not right, then why does everyone do it? Everything credit card companies and banks do revolves around making the customer happier. If this format was such a problem, why does everyone use it? An industry standard arises from a format that is generally accepted across the vast majority.
Therefore, if most people were like you complainers, then the companies would have changed their websites by now.
What kind of retard enters a phone number with dots? Kids
stopped doing that when being '31337' went out of fashion.
Manni-
Nice personal attack... thanks. Here's mine: I do have a lot of free time on my hands because when I code, I use regular expressions. It saves me a lot of time checking for '/' and and '*' characters. You should look into it.
So are you telling me there's an industry standard for inputing credit card numbers? Where? Maybe everyone is using this method because it's the easy way out? If you haven't noticed, usability has never has been considered an important aspect of application development (although it's becoming moreso thesedays)
Unfortunatly, we are stuck with legacy form validation methods that people have copy and pasted for years, and the consumer marches on dealing with issues like Carlos posted (Nov 17, 2005 4:26:27 PM).
Also, you'll note that on several occasions, I (and others) stated that there are times when you want to limit input... like the cliched, exaggerated example of launching missiles. You want that interface to be limited and deliberate. But to enter a phone number for a google adwords field? Your banking examples fall into the middle ground where (I personally) would sacrifice a small amount of usability to force the user.
And finally- I have on at least 5 occasions written my online banking service to provide feedback. Two changes were implemented (as they were minor errors in their site). The problem is that there is rarely a good quality usability review of web applications to include online banking. Customers don't think to complain since that's the way they always do it, and banks don't think to make it better since that's the way they always do it. It doesn't mean it's the best way.
"..then why does everyone do it?" has to be the poorest argument ever. I'm ready to move on now. Thanks for the fun times.
I haven't dealt with regular expressions enough to be able to write them (or verify the posted one) without a guide in front of me.
However, it seems to me that a US phone number is [junk][3 digits][junk][3 digits][junk][4 digits]
Where [digits] are 0 to 9 and [junk] is anything that's not a digit and not a letter.
Look for three groups of numbers containing three, three, and four digits. Allow these groups to be separated by whitespace and/or a single punctuation character.
Being too strict annoys the user, but you also want to catch typos if possible.
I think the programmers posting here are losing sight of the bigger picture. The company (Google) wants to do business with customer (John Doe). John Doe wants to do business with Google. In order for there to be effective communication between the two parties, Google needs the correct contact information. Therefore Google puts checks and balances on its forms in order to get accurate information from the customer. Likewise Jonh Doe wants to be reached by Google, so he will be careful to enter his contact information accurately. Most online forms that I have seen consist of individual boxes (fields) for each item of information (title, first name, last name, sex, appartment number, street number, street name, city, zip/postal code, etc...) When I fill out a form online, I almost always tab between the fields (some people use the mouse which I find inneficient). Having three separate fields for the phone number (3,3,4; only numeric) seems the most suitable solution to guarantee accuracy. Remember this is a business transaction between two entities that want to be able to communicate with each other. The main thing is the format a company chooses for their online form has to be easy to for the customer to complete. No single solution is better than the others as long as it is clear to the person completing the form what is required.
Not broken, but needs a little improvement in labeling fields for accurate first time entry.
PS. This "post a comment" site parses a double space entered after a period to a single space. (I guess they want to save room on their hard drives)
PPS. This site needs a little fixing also as it does not tell you what fields are required to post a message until after you hit post. Not broken.
Uuhhh, it's telling you to put dashes instead of dots. Machines process numbers according to a certain format, and if you don't follow it, the machine doesn't like that.
Broken form. If the parser requires a certain format, then the form should be designed to require or at least encourage that format.
Best yet, have a halfway intelligent method for processing almost any input, and if it doesn't fit what the parser expects then check back with the user to verify if the input was interpreted properly.
If my cell phone can take a string of digits and group them according to convention, with parentheses, dashes, and everything, then certainly a decently designed web form should be able to do the same thing with the 60 million times more powerful processing power that the PC has over the cell phone.
Loren and Kenton have hit it on the head: The more work the programmer does making less work for the user, the better the user experience.
I would just like to point out that phone number data entry is used as an illustration of Cumbersome Forms in Jakob Nielsen's Top 10 Web Design Mistakes of 2005.
http://www.useit.com/alertbox/designmistakes.html
Look at number 7 for the cumbersome forms.
Google is just evil. I put AdWords on my web site and after 6 months I earned a little over $100. I called to get my check and they said that my business is not generating enough ad revenue to make the relationship worthwhile, so they are canceling my account. I asked if I could still get the check and they quoted a part of their terms of service that state that they have the right to cancel an account at any time and retain the unpaid balance for themselves. I filed a report with the BBB, but they just quoted the TOS again and mention my clicking I accept, I also waived my right to sue from another state and or county.
It shouldn't matter wether the user inputs periods, slashes, or exclamation points. The non-number should be automatically discarded and replaced with a space or dash, as appropriate. It's really not hard.
Google is not broken. Users are broken.
If Google wants the phone number in a specific format, you should follow the instructions.
As for the suggestion to have 3 seperate fields for each group of digits, that presents other problems... namely being unable to copy a phone number as a single text string and paste it into the form. If Google did this, the rest of you monkeys would be complaining that you can't copy and paste your phone number anymore!
Even if Google programmed their scripts to ignore all non-numeric characters and just count the first 7 or 10 digits, it would have trouble differentiating between a regular 10 digit number (which includes the area code), and a 7 digit number with a 3 digit PBX extension on the end.
Seriously, you people are a bunch of lazy whiners if you can't enter phone numbers in the format you were taught way back in kindergarten.
The fault is yours. You intentionally put your phone number in with dots instead of dashes. Having lived in the US for 30 years, I'm sure you must have known that dashes were the most common format, yet you still had the audacity to call the form condescending. Come on.
Comments on this entry are closed
Previous: Infected Sony music CDs | Main | Next: Shower signs
more like google should have gave you 3 input fields, instead of just one.
if the dashes are REQUIRED, then why have the user enter them?
Posted by: Lacit at November 17, 2005 02:05 AM