Seen at a gas station:
You know your UI has usability issues when people tape multiple signs on your gas pump to help people get through the intricate and error-prone process of purchasing fuel.
Why does the upper note exist? The trouble is that there’s a Debit button but not a Credit button, and so since Credit is the default, users need to remember to override the default before swiping the card. People will sometimes naturally forget the special step because there was originally no reminder that this needed to be done, and because most other pumps don’t work that way. One solution would be to print the information prominently near the card reader, thus standardizing the note and making it more visible. A better and simpler solution would be to do what most pumps do: Avoid the opportunity for forgetting to specify the right thing by having both buttons, Debit and Credit, and simply prompting the user to press one or the other after they swipe their card.
But the trouble behind the lower note is even more blatant and, frankly, inexcusable: Is there any good reason not to conditionally print “ENTER PIN” or “ENTER ZIP,” instead of just always printing “ENTER DATA” which is not only unclear but also one of the classic geeky words to avoid in a consumer-oriented UI?
Then again, I’m amazed that in this day and age I still see output like “1 item(s) purchased.” Apparently it’s still more important to write the programmer-friendly printf( “%d item(s)”, count ) than the user-friendly printf( “%d item%s”, count, (count==1 ? “” : “s”) ).
Sutter’s Mill 
I saw a pump the other day with a similar note taped on next to the diagram showing how to insert your card. The note read
“Please insert your card OPPOSITE to what is shown”.
Yikes. It would have fit right in the picture here.
@I. J. Kennedy:
I have seen some U.S. ATMs that sell USPS postage.
(I agree that it should know what it just dispensed.)
My local ATM says PLEASE TAKE CASH OR PURCHASED PRODUCT. The software doesn’t know which it just dispensed? Also, what products can one purchase from an ATM?
Dim, I’ve read that gas stations are the ideal places to test stolen credit cards. Drive up, stick it in the machine. If it works, fill up. If not, drive off. In either case you know if the card still works or not. If you have to enter the zip code, then there’s a very, very slight chance that you’ll deter the thief. (Of course, card themselves are often stolen with other things that give the Zip code. Mine’s on my driver’s license, for example.)
Of course, this keeps you out, not to mention those pesky Canadians, who have letters in their postal codes.
So it’s mostly ineffective against thieves, and screws up legitimate customers. Typical of a lot of security ideas I see nowadays.
Why can’t the card type be auto-detected is my question? And ask the question only if that particular card does both (or if it couldn’t be determined)…
I think I use too much Apple stuff.
Each time I went to the USA I find some very nice UI pump.
First of all in the USA for European you have to choose credit for debit in every location.
But the funniest thing is when the pump ask for your Zip code. When you see that message you know that you can’t have gas there if there is no cashier.
My personal statistics are around 90% of pump ask for zip code for my visa card 5 to 10 years ago and now around 50%
It must have been a genius who designed this pump – why on earth do you need Red cancel button?
Herb,
Talking of the print statements, I have to mention one problem with the various Indian Language versions of Windows GUI.
For eg: When using Telugu(India) language, if we do a copy of files in Windows, we get the below dialog box with the status message.
“1 of 15 files being copied.”
If we have to place the numbers in the same position and translate the other words in Telugu, it translates to something like,
“15 out of 1 files being copied.”
I can understand that it is very tough to write code for some of the Indic languages.
> Then again, I’m amazed that in this day and age I still
> see output like “1 item(s) purchased.” Apparently it’s
> still more important to write the programmer-friendly [code]
> than the user-friendly [not-localizable, more
> complicated code].
I think you just illustrated the point.. it's not about programmer friendliness, it's about PM friendliness. The feature you just spec'd informally has a higher test cost, higher localization cost, and will all-around make boss/manager/businessy people cringe and cry "schedule".
One possibility is that they did market research, and that research found 97% of their customers use credit; so naturally they folded this into their next design, "helping" the user by "optimizing the credit purchase experience".
Don't attribute to stupidity that which can be adequately explained by product planning.
Most modern debit cards can be used as either credit or debit. If used as credit, the merchant pays a much higher transaction fee. Credit is the default… that’s why the merchant is encouraging the user to use the card as a debit card.
If your debit/credit card has rewards (some give 1% cashback), then you will also only get the reward if you use it as a credit card.
Amen to Igor Tandetnik
Nor do I know why credit and debit cards need different treatment. When I got my first debit card, I was told to use it like a credit card. Are there laws that require different handling?
While plurals are a lot more complicated than “s” versus no “s”, I doubt that most software that spits out “1 item(s)” is suitable for translation anyway. If you’re going to internationalize software, getting English plurals right is an easy special case (whether by providing the plural or by rephrasing the output). It’s probably worth a little effort to make the software work right in its native language, although it may not be worth a lot more work to make it able to work in different languages.
I don’t know any operational details about credit vs. debit cards, but I’ve always wondered why the question is asked in the first place. It certainly would seem like there should be a way for a card to identify itself as being a “credit” card vs. a “debit” card; but perhaps that’s not actually done for some reason.
Plurals issue is more complicated than that. In many languages, it’s not just two forms for “one” and “many”. E.g. in Russian, there are three forms: one for when the number ends with 1 but not with 11, another for when it ends with 2, 3, or 4 but not 12, 13 or 14, and the third for everything else. And the three forms are not built uniformly for all nouns (like English day/days vs party/parties vs bus/buses vs scissors/scissors, but with even more variants and less regularity).
See also
http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
I’m with you all the way up to the plurals issue (though here in Europe, both credit and debit cards use PINs).
On plurals, though, the “user-friendly” version is not good for localization. You need two separate localizable strings for singular and plural, as different words can get inflected depending on the language, or to switch things around so that you’re using a more symbolic notation, like ‘%d x %s’ or ‘%s: %d’.