I just went to Lowe’s to purchase a new appliance. They needed my email address in order to deliver it. However, when I gave it to them, their system insisted my email address was invalid.
My email address uses the *.name top level domain and many places still insist that this top level domain doesn’t exist and thus my email address is invalid despite the fact I’ve been using it for almost 20 years. The *.name domain was established almost two decades ago in 2000.
I wonder if someone from France has issues with their email address if they use their country’s *.fr top-level domain. And what about almost 1500 of newly approved top level domains that came about in 2013?
This isn’t the first time my email address has proven problematic. Poland Springs also won’t let me use my email address and neither do two major rental car companies or one of my frequent flyer accounts. For these people, I have a Gmail address that forwards any email sent to it to my *.name address.
If your memory goes back far enough, at one time there were only three-letter TLDs (ie, .com, .edu…). When I started my business and used a “.info” TLD, almost all older eMail server software didn’t know what to do with it. Today I rarely run into such software. You need to contact the webmaster/IT-geek of the company to let them know something is not right. It’s a fairly simple fix but they need to know about it in order to fix it.
Actually, were originally seven TLDs: .com, .org, .net, .edu, .gov, and the two most people miss: .mil and .int which was specifically reserved for the UN and its organizations.
I’ve tried reaching out to whomever is responsible for whatever company is causing me hell, but I always hit a brick wall. Most don’t believe that .name is real. Many just don’t seem to care. Why not just use Gmail like everyone else?
I’m still trying to figure out why Target’s website and app both think my (regular/USA 10-digit) phone number is invalid. It’s not as if the area code was ‘555’ or something.
There are far too many programmers writing production code that really don’t understand what they’re doing.
Domain name validation is one such case. The DNS system has always been too complicated for simple switch statements to be hard-coded into apps. The only way to validate an e-mail domain is to do a DNS lookup for its MX record and only generate an error if one can’t be found. Anything else can’t possibly work reliably given the massive numbers of TLDs that exist and have existed for decades (e.g. every country’s two-letter TLD).
Ditto for phone number validation. Once upon a time, there were a few simple rules for validating US phone numbers, but those rules no longer work. Thanks to number exhaustion in area codes, the phone companies were forced to issue phone numbers that would have been invalid under the original rules. And, of course, it gets exponentially more complicated if you need to support international phone numbers. Developers who aren’t experts in the phone system are likely to hard-code inaccurate/obsolete rules. Use of a good third-party library (e.g. Google’s libphonenumber package) will produce much better results than something the developer invented based on his own limited understanding of the global phone system.
I like time and date issues, summarized nicely here, though he’s missing some of the transitions from Julian to Gregorian, e.g. New Years used to be in March in Europe, which can make historical date calculations more ‘interesting’:
Since you brought up timekeeping, these articles should be required reading by any programmer trying to write code that manages time values. These have been discussed many times in the past in many different forums, but they’re still great references.
I oversaw a bunch of Perl programmers and insisted they use the standard date/time module that comes with the Perl distribution and not to write their own. One day, we had a problem with a bad date conversion. I checked and the code used the standard date time module I insisted on. Looking at the code of the date/time module was code equating one day to 86,400 seconds. Going through the code of other popular date/time modules, I saw the same bad assumptions (although to be fair, a few had comments that this was a bad idea in the code).
I wonder how other languages handle this issue with their standard routines.
This doesn’t surprise me. As someone who shops at both Lowe’s and Home Depot, I have found that Lowe’s technical situation to be woefully lacking. Cashiers type into monochrome text-only terminals. Their website search function rarely turns up what I am looking for. I could go on…
Good gripe. To me, the most irritating aspect of this story is that they don’t have a robust system to capture and fix problems. That demands a culture of not shrugging of problems. Surely they have seen this for a long time.
I used to report issues I found on websites but response is so rare, I seldom bother anymore. Sad. So much that should be “user experience” is left to IT without marketing oversight.
I ran web operations for a $2.5 B company. We put a prominent Contact Us link on every page – not a common thing in those days. It didn’t try to route people to a FAQ. The link sent a message – directly to me, not to support staff. I used to delight in those times when I could have something fixed within minutes. It was fun, but there was a fundamental benefit for us: it meant that we had to have an infrastructure capable of rolling out fixes rapidly.
For that reason I don’t usually complain about poor websites, but sometimes I do and it’s nice to be taken seriously. My bank currently sends PDF statements that look OK in Preview, but PDFKit cannot “see” the text. The company that makes the bank’s PDF software have been quite helpful, though it remains to be seen whether they can persuade the bank to change (I think it’s just a software switch somewhere).
In terms of parsing form inputs, I have a big gripe with forms that reject spaces in phone numbers (I’m in the UK – do US folk have the same problem with hyphens as well?). The official UK phone number format includes spaces; what’s so hard about stripping them out before counting the digits or whatever it is they do to check validity?
I use a password manager, and another annoyance is password and other fields into which one cannot paste. I find these sometimes when creating a new account. I don’t know whether they think it helps prevent errors in the “now type your new password again” field, but I find it infuriating.
I use a password manager, and another annoyance is password and other fields into which one cannot paste. I find these sometimes when creating a new account. I don’t know whether they think it helps prevent errors in the “now type your new password again” field, but I find it infuriating.
Paste the following code into a bookmark (a “bookmarklet”). I did not author this; I found it on a Google search. It only works on Safari and Chrome, reportedly.