Perhaps the card companies mandate it?
In defense of the programmers, let’s remember that only Visa and Mastercard use the four groups of four setup. American Express uses 4, 6 and 5.
This, too, can be accounted for in the programming, but where do you stop? I remember my days when I used to do web design and a client complained that his site looked like crap. We figured out that his monitor was set to show only 16 colors. Two weeks working in programming and you realize that there’s no way to not piss off end users because some percentage of them just fundamentally don’t get it. Won’t get it. Can’t get it. No matter what you do.
(In fact, I’ll bet you anything those sites that auto-group the numbers get e-mails from people saying “I’m trying to type in my credit card number, but your site is broken. It keeps inserting spaces that I can’t get rid of.”)
I much prefer a single, flat field for entering CC numbers. Auto-advancing annoys the crap out of me. If I fat-finger something, I want backspace to work. I want focus to jump when I want it to. I want not to guess about whether focus will auto-jump at 4 digits, whether my entered keypresses will be lost as it waits for me to press tab, whether my entered keypresses will add to the field in error, etc. Just let me enter the 16 digit number.
Some upthread are blaming the flat input on poor design or badly trained programmers. I don’t see any evidence for that. It seems like a flat field is the equilibrium format, making no questionable assumptions about card type or user expectations. And verifying 16 numerical digits isn’t difficult. The Microsoft license key example doesn’t seem germaine, as you enter that exactly one time ever (so you gain no familiarity with it), it is longer (25 characters vs. 16), and it has a mix of letters and numbers (36 symbols vs. 10), all of which makes verification much more difficult. It is also a fixed format (so no guessing about input type), and the UI isn’t general purpose (meaning users have no particular expectation about what happens to focus when you type in the fields).
Unlikely. The “credit card companies” have little to do with the card/consumer interface. (Visa, for example, is a relatively small company that only deals with management of the brand and licensing to banks.)
The payment processors only get the cooked data of the charge submission, which has to be in a particular format and so forth no matter how the entry screen is designed.
I doubt any of the card issuers have a guideline or requirement for entry screens, given how many variations there are even among major retail sites.
You and Xap are clearly in the “why bother, can’t be fixed, too much trouble” camp while I maintain that making a user interface simpler and more intuitive is an unvarnished positive. It is absolutely possible to make a simple, clearly-labeled, self-teaching, adaptive credit-card interface better than about 90% of those in use, and users will quickly come to expect/love it. Saying “people only expect a shitty product and have adapted to it so there’s no reason to confuse them by trying to do better” is a self-defeating attitude coveted by programmers more concerned with the elegance of their backend code.
Well… I do put a very high premium on the user interface. I’m frequently the person saying that the interface is more important than what the software actually does because it’s the part the user actually interacts with.
However, what I’ve learned is that you can please some of the users some of the time, but never all of the users all of the time. No matter what you do, you’re aiming for user satisfactions somewhere in the 60-80% range. Maybe on a really good project, you’ll get 90%.
I’m with dracoi on this. Good user interfaces are dependent on two things: 1) sufficient interaction between users and codes during the creation and 2) users.
When the population of users is everybody, no single solution will work for everyone. Creators have to gauge where to put the sweet spot, with the range dependent on ease of use and sheer understandability. Lower the bar too much and you frustrate people at one end; raise it and you lose people at the other. It’s a very, very, very hard problem and I’m not surprised that many people fail it. I don’t applaud them for that, though.
Moreover, that’s a different issue than the one I was raising, which is the power of legacy systems. Windows XP still has a base of something like 8% of users, even though it’s no longer supported. When people get used to a system that works, they have very high reluctance to switch to a purportedly better system because they know for certain that their productivity will decrease during the learning curve to the new system. Which often is not in fact better in many ways for them and their particular uses. This is well nigh universal and must be accommodated. I experience it. And so do you, just because you’re human. Calling this “why bother, can’t be fixed, too much trouble” is ludicrous, insulting, and a demonstrable lack of understanding of humanity.
I’m with Exapno Mapcase and dracoi on this too.
I work for a large advertising agency in technology, on the project management side. I’m also a former developer with a hard-core CS degree. My team builds websites every day, for a variety of clients that need to meet a variety of needs.
Here’s what we might see:
Client: “I need to make a form so users can submit questions to us. They’ll need to give us their contact information so we can get back to them.”
So we’re talking name, address, city, state, zip, phone number (or 2), email, etc and a field for their question.
But it turns out this is going to be an international form. So city/state/zip can’t be US-centric. We also now need to add country, but to make the city/state/zip validate for each country will take many hours because it’s all different formats. Also “state” isn’t “state” everywhere. Maybe its “region” or “province”. Zip codes are even worse.
Then we come to phone number. The client wants us - thinking ahead - to validate to (###) ###-#### … a US format. But you can’t do that because if it’s an international website, you have to worry about country codes, and other countries that do other formats – ##.##.##.## for instance. I looked into it at one point, and even within some countries the format changes.
In this particular instance, the client said to only validate it to the 10-digit US format if the country was US. Cool and all, but then that leads to messy code which makes future updates significantly harder because you need to account for the extra conditionals. And if any significant amount of time passes, you might not have the original programmer on it or they might not remember what they did or it’s not even the same company.
Bottom line - yes it can be done, but it will take a huge amount of time to customize, both now and in the future. Don’t get me wrong - I completely support user-centric design, but nobody wants to pay for it. So don’t blame the “lazy” or “incompetent” programmer. Blame the people holding the purse strings.
Contrast all this with, for example, Microsoft Excel, which allows the user to enter dates in umpteen different ways, and it always (well, frequently) figures out correctly what you meant.
You will note that when I assessed blame, it was on the education system and management. However, “lazy” and “incompetent” still describes a significant portion of the IT world, from programmers up through the highest reaches of management.
I am sympathetic to the issues of international information, (and certainly to incompetent users), but I have also worked with enough coders and managers who just did not care about quality. (I currently use a system that produces a receiving statement to reconcile products received against the invoice billed: the invoice number (required to initiate the reception process) does not appear on either the receiving statement or the screens from which the statements are printed. Some idiot kid did not understand that it would be a good idea to have some way to match an invoice to itsreception and some lazy and incompetent senior or lead did not think it worthwhile to review the document for “possible” flaws.)
Okay, that’s completely fair. I too have met my share of lazy programmers who take the easy route.
I amend my statement to “don’t always blame the incompetent or lazy programmer, they may not be the only one at fault”. Fair enough?
As others have said, how exactly to accept the credit card number is generally up to the programmer.
I generally avoid trying to give instructions to the user, because they will invariably not follow them and then get frustrated, which gets us frustrated when they ask for help or complain.
In the case of credit card numbers, I give no particular instructions on the entry blank. Upon submission I strip all non-numeric characters (generally spaces or hyphens) from it, and if I wind up with 16 digits that start with a 4, 5, or 6 and the check digit works out, then I accept what the user entered.
Should we go over to the Microsoft forums and see how many complaints there are about date formatting?
You don’t have to go too far. Canada - according to Microsoft - uses dd/mm/yyyy. Well the government might, but the rest of the country uses the same as USA - mm/dd/yy; as a result, I run across so many stupid situations where March 9th is interpreted as Sep 3rd… All because we didn’t lie to MS and didn’t go into regional settings and re-customize the settings.
The problem has been alluded to. Not all credit cards are 4-4-4-4, so you need to keep a running collection of all possible formats you accept. Any changes mean updates. Will AMEX notify you if they switch to 4-4-4-4 or will you find it out the hard way? Quite often (as you see entering MS license keys) breaking into groups means a backspace either does not work or selects the entire previous group and the next backspace deletes 4 characters. You also have to allow for people seeing the dash and thinking they have to enter the next dash or space… and so on. Having input fields change, on the fly, based on choices - more tricky programming, risk of slowdowns. (You selected CANADA, now wait while the screen is redrawn with “PROVINCE” and loads the list of provinces and territories instead of the 50 states)
Simply, if it’s a frequently-used field (i.e. the clerk’s input screen at the DMV office) then you can program all these tricks. The end users use the same screen a hundred times a day, every day, and get used to what it will do and appreciate the help it provides. If it’s the sign-up for the church fundraiser, the users will use that page once or twice a year, and simple, similar to every other page they encounter, is simplest and easiest.
Hey, as a programmer type, I take great umbrage at this accusation that programmers are all too lazy and/or stupid to do this right!
Kidding aside, it would not be hard to break it up into four groups. So I refuse to believe that every programmer in the world who ever coded an order entry form was too lazy/stupid to do it, and every single manager/client/functional analyst who was responsible for double checking usability, let it slide.
In addition to what dracoi and otheres have already said (e.g., american express numbers come in 3 groups, not 4): here’s a discussion among people who are supposed to think about these things for a living - website design - Credit Card input format - User Experience Stack Exchange
One point that seemed to make sense is that given all the possible format variations, the best way to handle it is Accept any and all formats typed into one box and then try to intelligently figure out what the user put. e.g. allow them to put spaces or whatever if it helps them get it right. control-z alluded to this approach. Makes sense to me.
Yes, Excel does that conversion very well – even when the data isn’t a date.
I frequently do spreadsheets of voting data with Ward-Precinct data (like 01-08) and Excel insists on converting that into January 8th.
Did not read all of this, but:
There is a reason why you ask for CC type AND the number: security.
If I say it’s a Visa and key in a Mastercard number, a good program will note that.
Especially if, after issuing a warning that there is an error, I get the same mistake twice.
Just how did this person get this number?
And, once more, it has only been stated 2x that I read:
THEY ARE NOT ALL 16 DIGITS.
NOT ALL POSTAL CODES ARE 5 DIGIT NUMERICS
Now, go back to bashing those over-paid, insufferable programmers.
:
+1 for a generic text field that accepts far more characters than needed and uses regular expressions and such on the back end to sort things out.
If possible, use Javascript with regexes to let users know their number is nonsense with a polite red note to the side, but don’t mess with the cursor or anything else.
One minor pet peeve I have is when I use my password safe app to auto-fill a form, I watch in annoyance as either the first 3 or last 3 digits of the CC number are truncated. The app pastes it in with spaces, but the pages only allow 16 digits.
Removing unwanted symbols and spaces is trivial work, but so many sites don’t do it.
Same thing happens with phone numbers–it tries to paste in a US format, while some lunkhead has said “digits only” in the form and set it to allow only 10 numbers.
Another vote for lazy/clueless developers.
Ironically it is probably more work to catch and report a user’s formatting “error” than it would be to strip extraneous white-space from the input and allowing users to enter numbers in any way they feel comfortable.
Don’t forget about cable ties!
Anyway, here’s another vote for lazy/incompetent programming and/or analysis. If I had to guess, I’d say that some analyst somewhere found out that they needed to enter a credit card number, looked up the maximum length, and said “16 digit numeric field”, when in fact, they should have specified something like 20 character text field; strip out any non-numeric characters and validate the length based on the card type chosen.
Then the programmer probably didn’t put any original thought into it, because you know, it’s on the spec as a 16 digit number, and coded it exactly as specified.
That’s actually something that frustrates me; too many programmers are way too willing to push off any responsibility of a cruddy user experience or anything like that back onto the analysts, when all it might take is “Hey- this is a credit card number. Shouldn’t we do it THIS way, instead of the way on here?” and they’d have a much better result.
But no, they just take it as-is, and then blame the analysts. Sometimes I’d almost rather have a coding robot, because at least they’d have regular expressions that you could use to make things more clear, instead of more infuriating.
What sort of shop has an analyst that never looks over the code written based on his specs?
Sorry, (I realize that there are shops that are so compartmentalized that analysts are dissuaded from doing that, but) that is the sign of a lazy analyst. I actually worked in a shop where programmers and analysts and users were always supposed to go strictly through channels and never tread on each other’s turfs: I ALWAYS violated that rule. I would rarely get my hand slapped, followed by a “Thank you” from the other parties who could see that we were trying to build a quality product. In most shops, there is no reason for the analyst to sit back and wait for the programmer to come back with questions. There is always the opportunity to review the output. (Some programmers can get testy about someone “checking” their code*, but there is no reason why an analyst cannot review the finished product.)
- To which I say “If your code is at least adequate, you should be proud to show it to me; what are you hiding?”