When I look at my various cards the numbers are embossed in groups of 4 like
1234 5678 9012 3456
but order anything online and the standard form makes you put the numbers in straight, like
1234567890123456
which makes it very easy to make a mistake. Microsoft realised this many years ago and splits its license keys into blocks of 5. Why don’t others? Is there some legislation?
I’m looking for a GQ answer, please.
I have also wondered the same thing. It also applies to telephone numbers and post (zip) codes which often get rejected if one includes the space(s).
Entering 16 digits allows the programmers to avoid coding to resolve spaces, hyphens, or other characters that might be embedded in the string at the whim of the person keying the data. They can simply code for 16 digits and reject anything that does not match that template.
Parsing a number with embedded spaces or hyphens is not difficult, but it is time consuming when you can save programming time and computer cycles by simply demanding the user provide the final number it needs.
The spaces on the card are a convenience to allow the human eye to recognize the numbers in manageable blocks, but the actual card number is the 16 digit code. (Slightly shorter for AmEx, Diner’s, and some retail chains.
The hard part is reading the card and NOT entering the data on the screen.
For someone like me, telling the difference between four consecutive 1s and Three consecutive 1s can be quite difficult if I don’t have my reading glasses on.
It’s less difficult on the computer screen because you have multiple options of verifying if you even need to.
This.
It takes almost zero time for a competent programmer to extract the digits and eliminate spaces. There are even functions made to do just that.
It’s basically laziness by the web programmer and/or analyst. It has no practical use other than to piss off customers.
I’ve previously written code to accept card numbers. I was most interested in the particular issuer format and validating the number using their algorithms. The very first thig I did was eliminate spaces and apply the relevant algorithms.
That same convenience, if implemented in the web form, would also allow the human to spot a data entry error more easily. Some web forms already do this when it comes to postal addresses (ZIP+4) or IP addresses, using Javascript to advance the cursor to the next field after each block is filled with the maximum allowable number of digits.
Such a lack of uniformity could explain why the automatically-advancing cursor from one four-digit field to the next has not been implemented for entering credit card numbers.
And that is totally an awful thing to do if your website is used by anyone from a different country. Trying to force-fit a Canadian postal code into a form that demands US-formatted input is impossible.
A general rule of language- & country-agnostic web design is to NEVER assume, or force, the format of input.
4 sets of 4 digits is fine. For about 80% of worldwide credit cards. The other 20%? Tough; you can’t buy our products. That’s not smart, not smart at all.
Lazy programming, especially by web coders. It is trivial, and always has been, to strip user entry of excess characters - especially placeholders like spaces and hyphens - and to regularize the case when needed. Four fields coded to accept four numbers each is another trivial construction. We did this all the time back when it was C and assembler and much harder to present on a screen; now that it’s all APIs and modular code, there is no reason to throw up a randomly-sized box for people to laboriously type 16 digits into, and not allow any kind of visual-aid spacers.
Machine cycles, my ass. Nearly all of that processing is, or can be done in the client, and would be negligible even on a heavily-loaded storefront server.
As for “some credit cards don’t use 16 digits”… then why is so much code wasted on making the user select the type of card they’re going to enter? The data all goes directly to a payment processor that knows it’s a Visa or MC or Discover or Amex anyway. So you want to take something odd? Make it another choice and process the user input differently. But I’d bet the number of cards used online probably exceed 99% 4x4=16 format.
(I feel the same way about US companies with a massively US clientele that “sensitively” put USA in alpha order in a list of 250 countries, instead of at the top of the list and default. Wouldn’t want any Uzbeks to feel slighted when they order from Victoria’s Secret.)
The majority of the sites with which I do business do this for telephone numbers.
I am guessing that the prevalence of American Express, with its 4-6-5 numbering sequence is responsible for many of the no-break sixteen-digit entry fields. It would not be a horrible situation to set the window to display four 4-digit fields if the user picked Visa, Mastercard, or Discover while setting the entry windows to a 4-6-5 pattern for AmEx, but I could see a lot of programmers not thinking about it and a LOT of project managers telling those who did to simply set one long input field.
(On the other hand, since they are using one long entry field, I see no reason for any entry screen to demand to know which card is being used, since, for the big guys, (often the only cards allowed), the first digit identifies the issuing system: 3 = AmEx, 4 = Visa, 5 = MC, 6 = Discover.)
I agree with those who say it’s laziness of the programmer. I was at a site yesterday buying something that automatically grouped what I typed into groups of four, it didn’t even require me to hit space or dash. That’s good programming, I wish all sites did that.
Programmers are so notoriously bad at considering anything to do with the way mere users see their production that an entire sub-industry has had to grow up to compensate for their myopia.
(I’m not even talking about the ones that are arrogant and malicious - just the ones who have absolutely no clue that Joe User will find one approach intuitive and easy to use while another is mystifying to the point of cancelling the order attempt.)
The very idea that “SEO” and “UX” have to exist as separate specialties indicates how lame the entire industry is about considering the end purpose of their efforts. As I’ve put it elsewhere, it’s as if Ford designs a car right down to the last detail… and then calls in teams to make sure it meets fuel efficiency, safety and human-engineering needs.
I would tend to blame that on the schools that teach programming. They spend lots of time on developing “language” skills and no time (that I have seen) on developing a mindset to actually make software user friendly.)
One of the reasons that I have been much beloved in the user communities for whom I have worked has been that I was an end user for several years before I got into programming and look at specifications differently.
(I am also considered a bane among programming staffs when I am a user, because I call them on their crappy, user-hostile coding so often.)
Yes, and I have seen this in the case of phone numbers, social security numbers, etc. One potential problem with this from the user’s point of view is that the cursor might or might not automatically advance to the next field once you’ve typed all the digits in one of them, and if it does the opposite of what you’re expecting, it can mess you up.
Lemme buy you a beer.
I spent quite a few years on the documentation/user materials side, but with a strong programming background and a powerful sense of “user experience” (before it became a buzzword) and esthetics. I had quite a few go-rounds with the programming staff about menus, screen layout and functionality, but in the end, I did more than get them to think outside their tiny little code boxes… I finally got them to see software from the user viewpoint in, not from the code-module viewpoint out. (I also inverted the design process, by creating the user function screens and then passing them to programming for development, instead of letting them pull every module function up to a window of its own.)
I am rusty on modern programming tools and techniques but having come from the hardscrabble, code-it-all days I can’t cut the modern crowd any slack when it’s drag, drop, nudge, cleanup and compile all from E-Z menus. No excuse at all for not understanding good user esthetics and convenience.
It’s funny, I can’t get any “UX” work because I don’t sling last week’s lingo and haven’t spent the last three years using wireframe tools… but I’ve literally forgotten more about crafting user experience on the screen than most of these puppies with their still-smeary certificates will ever learn. Damn kids.
I agree with this. It would help if schools taught user friendliness concepts. But I found in my 20 years as a programmer that the more user friendly my programs were, the less elegant and downright ugly my code was. It was a definite trade-off. I suspect most programmers prefer to focus on elegant code because that’s how they’re evaluated (and have bragging rights).
I launched in the early 90’s in dumb terminal days and was a system engineer until just a few years ago. I noticed that when the industry transitioned from dumb terminals to web interfaces that most user interface principles were thrown out the window and had to be gradually relearned. Technically, it was because early browsers didn’t offer the simplest UI capabilities like client-side field validations. Remember the days when you had to reload the entire page to validate a single field? I also noticed the irony that during this time colleges started offering degrees in HCI (human computer interface) and user experience design, but nearly no companies hired those graduates for that purpose. It’s a very sad statement on the IT industry.
Funnily enough, I still have my coursebook for HCI from my BSc Computation 25 years ago…
But we digress. I’m sure there’s a Doper or two who work for the card companies, and I hope they’ll chime in.
Many web “programmers” are not programmers in the historic sense of the word. They don’t come from a programming background so they lack the proper training and understanding required. They’re just social media hacks who can spit out a web page in a moment’s notice with no regard to proper programming techniques and requirements. If you spend time and look under the sheets, it’s all held together with bubble gum and spilled energy drinks. Proper coding uses baling wire and original duct tape.
Why would the card companies be responsible for this? The culprit is whoever coded the payment information applet that the merchant site uses. There are so many minor variations among sites that it’s obvious that no one source is being tapped.
At this point, the confusing differences among entry screens makes it more likely that the one constant among them - a 16 number box for credit cards - stays the same. Going to a better system would confuse enough people for just long enough to generate chaos.
Like seemingly everyone else in this thread, I spent time in the coding trenches. I handled everything that required words, from writing the system specifications to writing help files. That meant I was the person to click on every button and follow every procedure. If there was a way to break a system, I broke it. They quickly learned to stop hiring me to write the manual 24 hours before it was supposed to go out the door. Our biggest project was to computerize the sales force for one of the country’s biggest corporations. We were not allowed to talk directly to them, however. Everything had to go through intermediaries. And that, my friends, is why the computerization of America took 20 extremely painful years and will last 20 more.
That far back, it’s probably as much about “proper user training and acclimatization” as it is about UI design. 