|
Please enter... without dashes or spaces
Have you ever seen this on a web site: "Please enter your credit card number without dashes or spaces."
Or the following, which is from Fog Creek's order form: "If this is a U.S. address, please use the 10 digit phone number with no punctuation and no leading 1."
I remember having a hard time the first time I ever used a credit card online. I tried it with spaces and dashes before I finally figured out that I had to run the numbers together.
Has no one figured out how to make a web site more usable by stripping dashes and spaces from a number?
Nate Silva
Monday, January 19, 2004
Could be done with some simple JavaScript...
www.MarkTAW.com
Monday, January 19, 2004
When I code to accept credit cards, I fix the field at 16 digits and prevent any non-numbers from being entered (w/ Javascript). It can't really be screwed up.
Of course, I could just as easily strip out the characters after the fact. Either way, I think, is acceptable. What's not acceptable is leaving it free form and then erroring out when the user doesn't get the format exactly right.
Almost Anonymous
Monday, January 19, 2004
AA, with your solution (esp. if it's not labeled), then I type
1234-5678-9012-3 and suddenly can't type any more.
I think the only acceptable solution is to accept any format and strip the non-numeric characters after posting.
Philo
Philo
Monday, January 19, 2004
Philo,
As I said, I "prevent any non-numbers from being entered" so that's not a problem.
Almost Anonymous
Monday, January 19, 2004
So the user spends a week trying to figure out why "-" or " " won't enter.
It's easier to just tell them or strip the damned things out later.
www.MarkTAW.com
Monday, January 19, 2004
The joke is, our order form doesn't even care if you do put in dashes. The instructions are sort of obsolete, but it's hard to get up the energy to fix something so small. :)
Joel Spolsky
Monday, January 19, 2004
By the way... for usability purposes, often it's worth putting instructions there even if you don't care one way or the other, because some users will be confused if you don't tell them exactly what to do. They'll think "gosh, do I put in spaces? Or replace spaces with dashes?" Even if you don't care, the user needs to decide what to do, so telling them what to do is just one less decision they have to make.
Joel Spolsky
Monday, January 19, 2004
Bad--Lazy--Joel.
www.MarkTAW.com
Monday, January 19, 2004
"So the user spends a week trying to figure out why "-" or " " won't enter."
If it ever came up, I'd change it. However, nobody has ever had a problem with it. Sometimes people just aren't that stupid and the discussions of "perfect" usability are just nit picking.
Almost Anonymous
Monday, January 19, 2004
Agree with everyone. Stripping all punctuation and converting to lowercase is NEVER a bad idea.
Dennis Atkins
Monday, January 19, 2004
don't you mean "is never a bad idea" ?
www.MarkTAW.com
Monday, January 19, 2004
And I'm sure Mr. DiCardi won't mind when all his correspondance goes to Mr Dicardi.
Snotnose
Monday, January 19, 2004
Actually it should go to MR DICARDI
www.MarkTAW.com
Monday, January 19, 2004
"And I'm sure Mr. DiCardi won't mind when all his correspondance goes to Mr Dicardi."
Which is why I store all my strings in Uppercase with the punctuation stripped out and replaced with a "?" AND have a variable length bit field marking which characters should be actually capitalized, and which characters shouldn't.
Then it's a simple matter of figuring out where the variable bit length field starts, which is signified with a preceding "//", which can be escaped with a "\" if it should actually appear in the string. Where a ? is found, the bit field is searched, and if it is a "1" for the place, then it is in fact a question mark (no escaping needed there), and if it is a "0" (lowercase, for the other letters), then another variable length hex string located at the beginning of the string (the actual beginning, not the logical beginning, as this string is stored similar to a CComBSTR) is searched, which holds the values, in order, no spaces, of the punctuation ASCII values. This string is ended (marking the ending of the beginning hexadecimal-punctuation-definition-string [HPDS], and the beginning of the logical string, or Alpha-Punctuation-Substituted-Logical-Beginning-String [APSLBS]) with a 0x3F, which is of course, the ascii value for question mark, since that value will never be present, because of the preceding "?", "1" (in the bitfield) rule for actual question marks. So it's a simple matter of parsing, substitution, and length calculation to achieve a VERY simple solution. I don't see what the problem is.
Unicode support will be in my next version.
Dignified
Monday, January 19, 2004
>>>If it ever came up, I'd change it. However, nobody has ever had a problem with it.<<<
How do you know this? The idea of it taking a week to figure out your entry scheme is a bit exagerated. 10-20 seconds should be enough of random poking at keys to figure out what's going on.
I can also imagine some fraction of potential customers entering four digits and a space, then, when the space wasn't echoed, just figuring that your web site was broken and going on to another seller.
Perhaps your product is unique and you can afford to be just a bit customer hostile.
mackinac
Monday, January 19, 2004
We've had the whole "freeform data entry is the only good way to accept data" debate before, and if I remember right it became pretty obvious that all we were going to get was a lot of noise and no results.
I do have to say that if you don't spell everything out exactly as it should be entered, and make the instructions idiot proof, you will be shocked at the numer of idiots trying to use your software. Many people have trouble even remembering their own e-mail address. Filling out a form on a web site is really going to challenge them.
Clay Dowling
Monday, January 19, 2004
It is natural for many users to have spaces or dashes in things like SSNs, phone numbers, or credit card numbers. Requiring people to leave out dashes or spaces is silly and annoying.
It is so easy to strip out the spaces and dashes when the data arrives at the site. Every time I see a site that requires the user to strip the spaces and dashes, I think "yet another stupid programmer who can't perform a simple string manipulation."
NoName
Monday, January 19, 2004
I agree with Philo and Joel's second post to this thread. This is a usability issue that many many web sites seem to ignore (some do so at their own peril).
I personally don't like the fact that many book publisher's web sites require me to enter an ISBN number with the dashes removed (i.e. Sams publishing). O'Reilly seems to be the best of the bunch. Not only does their web site handle the ISBN number usability issue but each book has an errata link associated with it. Note: While some books might not have any posted errors (either by the author or the general public), there is still a link to a document that states this fact (all O'Reilly books have an official errata document and an unconfirmed error reports document).
Imo, many web sites (i.e. book publishers) don't bother with the "messy little details" that can affect purchasing decisions. For example, while I believe Addison-Wesley publishes some very good technical books, I don't believe that I have ever seen an errata link associated with any of their books that I was interesting in purchasing from them. This fact has stopped me from purchasing at least three of their books. I made those "don't buy" decisions after reading numerous online reviews that stated the book's content was good but full of errors. Perhaps all three of the books that I decided not to buy had a companion web site that was maintained by the author. I will never know since in many instances this fact is only mentioned within the book itself.
One Programmer's Opinion
Monday, January 19, 2004
Years ago, when we were first setting up a way to purchase our software online, we considered several possibilities. One was a set of tools that put the order form right in the product. The user used the product for a while as a demo, then filled out the order form dialog, the program used the internet to validate, then unlocked the program. Very cool. No need to go to a web form and then download or copy/paste a serial number. Just fill out a form right in our demo version.
But... their code insisted on no spaces in credit card numbers and they didn't even say that on the dialog. It also would only work if you entered the expiration date correctly, again with no prompts or dropdowns. When I complained, they said "don't worry, any user who gets confused can consult the help screen". I figured that any company that expected a user to consult a help screen to fill out an order form would not survive, so went went a different route. Indeed that company did not surive the dot com implosion.
Usability matters.
Harvey Motulsky
Monday, January 19, 2004
Noname's comment is right.
If the non-digits are there for presentation, and are not required for communication, the simplest way is to accept ANY data as entered by the user, store it as entered (so that it can be re-displayed in the user's familiar form), but standardise the data at the point it is exchanged with another system.
For names, if I want my name to appear as He-Who-Must-etc, or Mr. He, or Must, Esq., why do you care? Getting too clever with data storage formats is a major cause of system usability failure.
HeWhoMustBeConfused
Monday, January 19, 2004
"However, nobody has ever had a problem with it. "
Hah -- that's like the owner of a soon-to-be-bankrupt business saying, "Our customer service can't be a problem -- nobody ever complained about it."
Most people don't complain. They just get angry or frustrated, and never come back.
J. D. Trollinger
Monday, January 19, 2004
Use four 4 digit fields with hyphens as part of the boilerplate (a la Microsoft's method for entering product keys).
No room for ambiguity.
Appleologist
Monday, January 19, 2004
Yeah but then you enter into the whole "does the cursor automatically move to the next field or do you make the user hit tab" debate.
Full name:
Monday, January 19, 2004
I come across this every time I log into my bank. When entering my client card number, it would be *much* easier to verify I've done it right if I could put spaces in the number I'm entering -- which is how it's printed on my card! As it is, I end up juggling two things at once when I'm comparing to my card: I'm trying to parse what I've typed into groups that match what's on my card, along with comparing the digits.
Every time I see something that says not to put spaces in, I think "lazy programmers." (Or "idiots", if I'm not feeling charitable.)
scruffie
Monday, January 19, 2004
Appleologist: I can't speak for users in general, but I ABSOLUTELY HATE (yes I intend to shout) those forms that break a single value into multiple subvalues. Why:
If you miss a digit along the way and realize it at the end when you're double-checking, you're screwed.
You never know if you have to tab or not to move to the next field, which interrupts your typing because you have to look away from the number and at the screen to see which subfield has focus.
You can't cut and paste a number from somewhere else. This may be an intentional aspect of Microsoft's implementation, but you know, I've found that keeping stacks of CD cases with product keys organized is pointlessly difficult so I long ago took the step of putting all the license keys for my various machines and various software packages in an Excel spreadsheet. Ideally, when I needed one of the keys I'd just load that spreadsheet and copy and paste, but now I have to retype. Grr.
Actually, in a lame threadjack attempt, I now want to air my beef with address-entry forms that make you select your state abbreviation from a combo box rather than letting you type it in. Maybe that's cool if you live in Utah and now get to type one character instead of two, but if you're in New York that means pressing "N" six times instead of typing the oh-so-simple two characters "N" and "Y". (Yes, I know you can use the mouse to expand the combo box and select from the list, which is fine except that it takes about five times as long as just hitting those two keys, which is practically hardwired behavior when you're typing your address anyway.)
John C.
Tuesday, January 20, 2004
Dignified - that was the funniest thing I've read in a long time.
RB
Tuesday, January 20, 2004
Personal pet hate is forms which ask for "town" my postal address is just:
1234 Some Street
London
PostCode
UK
Worse still since in the UK a postcode+housenumber is unique I've ended up with forms that autofill based on the postcode, then give me an error because there's no town specified, one wouldn't let me carry on because if I made up a town (actually I use a london borough name) then the address was different from the postoffice address . ARRRGGHHH!
Peter Ibbotson
Tuesday, January 20, 2004
> Stripping all punctuation and converting to lowercase is NEVER a bad idea.
My own preference is just to convert everything to the letter "z".
Mr Obnoxious Man
Tuesday, January 20, 2004
Never mind presentation. How about the data storage itself?
A business associate made a hotel reservation in my name at one of those online hotel sites and gave me the confirmation number. I then had to phone the 1-800 number and give the operator my credit card to confirm the reservation.
The operator could not find my reservation. The problem? The reservation number had dashes in it. AND THE DASHES WERE SIGNIFICANT!!!
That's right:
123-4567890 was a separate confirmation number from
12-34567890
Just when I thought computers couldn't screw anything up any worse...
David Jones
Tuesday, January 20, 2004
"So the user spends a week trying to figure out why '-' or ' ' won't enter."
And gives up in frustration...which, in this case, is exactly what we want.
Show me a user who takes a week agonizing over entering a credit card number, and I'll show you high tech support costs if that person becomes a customer.
Kyralessa
Tuesday, January 20, 2004
And now we know why Microsoft is worth billions and why most other programmers can't figure out why they aren't getting rich just like Bill Gates did.
Foolish Jordan
Tuesday, January 20, 2004
If you can checksum the data, let the user enter it however they want. CC numbers are very easily validated for validity without even a network connection. Accept anything the user enters, strip out all the non-digits, and verify the result. At the very least, you should accept spaces, dashes, and nothing-but-digits.
Richard P
Tuesday, January 20, 2004
I like this solution: For SSNs or credit card numbers, allow the user to enter the dashes or spaces (maybe that's all). For text fields, allow them to enter text in mixed case.
In indexing your data, strip out the dashes and spaces, and uppercase the text fields.
Now you can search in a deterministic way, while still producing data in a user-friendly way.
Zahid
Tuesday, January 20, 2004
John C.: Why don't you type "M" and the up arrow?
It still sucks if you're in the middle though. (But it sucks less)
Tuesday, January 20, 2004
"We've had the whole "freeform data entry is the only good way to accept data" debate before, and if I remember right it became pretty obvious that all we were going to get was a lot of noise and no results."
Do you mean that the noise was from the debate, or from users entering in bad data?
Baaaad data
Tuesday, January 20, 2004
do you prefer to use google (freeform w/correction) or highly structured search forms?
mb
Tuesday, January 20, 2004
To the Poster who hates single inputs broken into many inputs:
We use this technique all the time for phone numbers, because our clients feel that consistent data is more important than the inconvenience caused by multiple fields. (And as an aside, after the amount of useless or nearly useless data we've had to port from "applications" that were free form all the way baby, I tend to agree...)
That said, we work quite hard to make the data input method transparent to the user.
For instance, if you miss a digit along the way, in our implementation you can treat the field as a single field (backspacing works no problem). I'd argue that our method is faster in this respect because you can jump back to the beginning of each sub-field by clicking alt-tab.
Our users are not "one-time-only" users, so presumably they learn what the behaviour of the field is (it tabs automatically). However, if the user is typing numbers and hits tab right before (or after) the autotab, the form ignores the tab. The focus issue doesn't seem to be a problem.
We can also cut and paste into the field as if it were a single field. (we can't copy out of the field yet, but we're working on it)
Looking at your rant - it seems to me that your "issues" are more a result of bad/incomplete implementations rather than a problem with the approach per say. Obviously I'm biased. But you seem to feel strongly on the issue so - any other disadvantages that you can think of?
(Ignoring the "but you can't enter unexpected data" crowd, that's a separate issue).
Phibian
Tuesday, January 20, 2004
Ah yes phibian has just reminded me of one of my other pet
hates, phone numbers that aren't big enough.
my work phone number is +44 20 8303 3329 from outside of the UK or 020 8303 3329 from the inside. In general if I'm faced with a "broken" US style phone number field of the xxx-yyy-zzzz form then I have enough digits but only by omitting either the leading zero or the +44. (You don't see as many of these as you used to)
Peter Ibbotson
Wednesday, January 21, 2004
Phibian: what do your forms do if someone enters 1235-678, realises that there should have been a "4" in there, moves the cursor to between the "3" and the "5", and types "4"? Does it shift the "5" over into the next field?
Gareth McCaughan
Wednesday, January 21, 2004
Gareth - it shifts the digit over to the next field, but only if there is space in the field. Otherwise it doesn't let you type until you delete or backspace.
Peter's pet peeve is certainly valid, and I'm sure we will have to deal with non-North American phone formats some day. However, in our case the decision was that valid data for the (so far) exclusive audience of North Americans was more important than being able to capture non-standard phone numbers (which can be placed into the notes field if absolutely necessary). Don't forget that our users are not "one-time use" only (and the apps are not open to the general public).
I suspect the way we will handle non-NA phone formats in the future will be to have some way to toggle between them, but I haven't thought of a good way yet.
Phibian
Wednesday, January 21, 2004
> but I haven't thought of a good way yet
Perhaps a combo-box to select the country code.
Christopher Wells
Wednesday, January 21, 2004
there's another way to handle the restricet-input (e.g. phone number) case:
let the user type free-form.
simultaenously display the corrected version nearby.
if there's an error, make the corrected version turn red and blink.
user can type & edit in the way they prefer. (e.g. 212.555.1212), but the data in the database is in the 'correct' form (2125551212)
mb
Wednesday, January 21, 2004
I read somewhere that the reason so many web sites enforce this "no dashes or spaces" rule is that the credit card payment service provider insists on it for some reason. And yes, I do mean that they insist that the *user interface* be this unforgiving, not the back-end (which would be an entirely reasonable requirement).
On a related note, I also heard an amusing story a few years ago where a company approached a bank about online credit card processing, and their "solution" involved plugging in one of those little EFTPOS terminals you see in shops into the web server, and being careful to send one request at a time...
Daryl Oidy
Thursday, January 22, 2004
That's a good idea Christopher - we already gather country information.
In our experience, free-form typing is a bad idea (tm) for so many reasons if you care about the data.
Data integrity is harder: Freeform - if you miss a case, your data is now incorrect. If you are rigid about what is entered in the first place, the worst that can happen is user inconvenience. Obviously that's a trade-off.
I like splitting up the fields because that's one less thing for the user to worry about. If the field is free-form, most users (especially unsophisticated ones) are uncertain about what kind of data they are "allowed" to enter. Extra fields that auto-fill in to try and visually cue the user that the information is wrong are a hack at best - they clutter the interface with unnecessary information (very important if you have involved forms...). At worst they contribute to user confusion - "why is my phone number entered twice?"
--
I can tell many amusing stories about online credit card processing - like the spec we received that was one character off (and apparently had been for some months).
Or like the bank that did money transfers for any amount that you happened to place in the file - without checking to see if the account in question had sufficient funds. For extra security, you could pay an additional fee. This would get you one bank employee who would watch the transfer (during a specified window of time) to ensure that the amounts being transferred were legimitate.
Phibian
Thursday, January 22, 2004
 Recent Topics
Fog Creek Home
| 
