Dear Programmers, Why do you hate me?
-
... and all humans? When I pay a bill on line I have to enter my account number. The invoice I received shows this account number in a 4pt font as: 10000000002987421000331 or something ridiculously long with no breaks and an indeterminate number of zeros stuck in just for funsies. Sometimes there are alpha characters that include the letters "I" and "O" to guarantee I can't get it right on the first try. For the love of Dog, and my failing eye sight, could you please break this up into 3 or 4 character sequences, and drop all the 0s out? And if you allow "I" and "O" into the mix, could you please find some other form of work where your clients enjoy being tortured? Oh, and stop using 4pt fonts, too. As I struggle to enter my account number I assuage my frustration by imagining which of the circles Dante would put you in.
I hate myself sometimes too since I've done it to myself :-D A good human interface, for us pathetic humans :) , requires a lot of thought and often, coding. It often starts with database design; no spaces in credit card numbers, no dashes in SS#s and phone number requirements for SMS that accept 18005551212 as the only format. I love the "Enter your SS#" so you type in xxx-xx-xxxx and then get a popup saying only numbers are valid. Why didn't you set it to accept only numbers or drop the dashes, turkey? Forgot to do it, ran out of time, or maybe even some hate, lol. It's getting a bit better as more tools have easier formatting settings available prior to running data validation on the good ole submit button. But there remains a lack of data standardization in the industry and allowing il0O or even things like nw next to each other in some fonts is ugly. But often, it's the deck we're forced to play with.
-
I hate myself sometimes too since I've done it to myself :-D A good human interface, for us pathetic humans :) , requires a lot of thought and often, coding. It often starts with database design; no spaces in credit card numbers, no dashes in SS#s and phone number requirements for SMS that accept 18005551212 as the only format. I love the "Enter your SS#" so you type in xxx-xx-xxxx and then get a popup saying only numbers are valid. Why didn't you set it to accept only numbers or drop the dashes, turkey? Forgot to do it, ran out of time, or maybe even some hate, lol. It's getting a bit better as more tools have easier formatting settings available prior to running data validation on the good ole submit button. But there remains a lack of data standardization in the industry and allowing il0O or even things like nw next to each other in some fonts is ugly. But often, it's the deck we're forced to play with.
-
You nailed it. I've had a lot of fun writing parsers that accept as much variation in user input as possible and still maintain accuracy. The SS#, phone number are perfect examples. Time entry is another good one.
Oh no, the dreaded "Time", lol. That is so true. Whenever possible, I'll load time into a combo if I need blocks like 15 minutes. On the desktop side, using visual studio date and time widgets helps muchly. Last names are another tough one as they are usually critical lookup fields. O'Reilly, Oreilly, and O Reilly. And depending on your SQL, you need to watch the apostrophes.
-
my mini-spec: Base32 Encoding for IDs essentially just [A-Z 0-9] but without '1', 'I', '0', or 'O'. so, ([A-H]|[J-N]|[P-Z]|[2-9]) case sensitivity: no a uint64 can be represented in 13 chars .. a 128-bit GUID in 26 chars everyone please ratify and adopt my proposal as a worldwide standard, asap kthx