I am making reservations on Jet Blue for a trip to DC and back. I am using their (Jet Blue's) rental car lashup, Hertz. The irritation is that Hertz can't accept my phone number with the bow-legs and the dash. Is their software that bad, their programmers that weak, that they can't take it one of several different ways? Why am I, the customer, being forced to fit a specific mold when the software, properly written, can do the work?
And, it is Hertz and not Jet Blue that is causing this problem.
Just asking?
Regards — Cliff
2 comments:
Software is indeed that bad. It's amazing how long bad programming persists in the bowels of the beasts.
It's laziness and time constraints I'm sure coupled with a fear of accepting typos, not lack of skill.
Time is money, and errors are even more costly. Although this should be a simple problem, I've been sitting here for about five minutes working out different ways phone numbers can be incorrectly formatted.
You can't just strip punctuation, for example: (9789-555-121 would be a bad entry that would verify as a 10-digit number caused by two errors at once: Missing the shift key on the closing parenthesis, and then omitting the last digit. Stuck key maybe.
Maybe you write a regular expression for numbers, optional parenthesis, optional dashes, remove whitespace. You know how many unicode characters look like a '-'? If you don't accept them all, the user is going to get a very bizarre error. Still not insurmountable, but then someone is going to try 978.555.1212 and wonder why that doesn't work. Then your instructions on the page must say use format X, Y, or Z, which is long and confusing. Better to just avoid the issue.
Forced examples, sure, but it is very frequently found that the problem in a software system exists between the keyboard and chair, and engineers need to program around this. Sometimes, limiting use-cases is the best way to do that.
IMHO, The best - and most precise - phone number entering systems are those that draw the brackets and hyphens for you. In that case, the number looks like you'd expect, and the software verification is still potentially as simple as "is it 10 digits?" Even then, there are complications, if you want to make them. No phone numbers start with 1 or 0. If you were writing this code 20 years ago, no phone numbers had a second digit (in the area code) of anything BUT 1 or 0. If you wrote it that way originally to be "better", now someone has to change the code, put it through testing, etc. And until it's done, valid phone numbers don't verify.
User-friendliness and robust software systems aren't always one in the same.
Post a Comment