In days of old, when knights were bold, and they kept their data on large reels of magnetic tape, the tapes were stored in a central tape library, and were mounted by request on mainframe computers. Each tape in the library was given a volume serial. One requested a tape by its volume serial, which was six characters — letters and numbers.
Once in a while, one might need a fresh tape to write information to, which one would then read back in the same program, and the tape would not need to be kept in the library afterward. These were called scratch tapes, and the volume serial “SCRTCH” was reserved for such requests.
Now, if you needed a scratch tape and made the mistake of requesting it as “SCRATCH”, the program that handled the mount requests would see that you used seven characters, and volume serials could not be more than six. But more than that, it actually recognized the specific name “SCRATCH” and gave an error message similar to this:
Error: Scratch tapes should be requested as "SCRTCH".
And you had to re-submit the request with the “correct” volume serial.
This was just stupid. The computer knew what you meant. There was no question about it. So why complain and make you re-submit? Just do it!
There was a lot of that sort of thing back then. But, hey, those were the old days, and we’d never do that any more, right?
Well, not right. We still do it plenty.
We’ve all gotten automated email that said, somewhere in it, “Please do not reply to this automatically generated email. Instead, direct any questions to frobozz@example.com.” Now, there’s a header field called “Reply-To” that can be put into any email message, and that every email program understands, which controls what address the reply goes to. All they had to do to make replies work the way they and you want them to was to put this into the headers of the message:
Reply-To: frobozz@example.com
But they didn’t. Lazy programming, poor human factors.
On the other hand, it might be intentional: they might actually not want you to reply, and by making you take the extra step of manually entering the reply address (or even using copy/paste) instead of just clicking “Reply”, they may be discouraging it.
But, then, the other day I got the online proxy materials for the 2010 IBM Stockholder Meeting. It includes a control number that allows me to vote my shares online, and it looks like this:
Proxy Login Details:
Control Number:1234 5566 7788 999Note: When voting your shares, please DO NOT cut and paste the 15-digit Control Number. You will need to enter the 15-digit Control Number without the spaces.
Yeah, that’s just stupidity, unmitigated. It’s pretty likely that a good number of folks will transcribe a 15-digit number incorrectly, and it’s an avoidable situation. They could include the number without the spaces, so it can be copied and pasted. Even better, the web server could simply strip out spaces, dashes, or whatever, before passing it on to the proxy-vote handler. And in this case, they want you to do it and get it right, so the issue with the Reply-To doesn’t apply here.
More lazy programming, more poor human factors.
[I copied-and-pasted the number into a text editor, deleted the spaces, then copied-and-pasted that into the web page. It worked fine. But I suspect most people would just type it in, and then utter discouraging words if they typed it wrong.]
We need to think about this stuff when we provide user interfaces. Stop making every user do the work. Take an extra few minutes to help them out.
5 comments:
Being a web developer, I endeavor to create positive user experiences in everything I do — especially because I know much I hate it when other programmers don't.
You're absolutely right about lazy programming. Yes, it's sometimes rather time-consuming to write and test the extra code, but there's really no excuse not to because it's easy.
I recently ran into a great example of this. My wife was trying to pay a bill online, so she filled out the form with what appeared to be accurate and correctly formatted information. When she submitted the form, an alert popped up and told her that something was not correct so the form would not be submitted. Then the window contents darkened and a modal window popped up saying to wait while the form submits and warning her against submitting again lest she be charged twice.
After waiting for a few minutes, she asked me what I thought she should do. Eventually we decided to reload the page and try again. She filled in the form and consulted me again before she hit submit. It looked good to me, but the same thing happened.
"Turn off your JavaScript," I told her. She did, reloaded the page, and filled out the form once more. This time when she hit submit, we skipped right past the alert and the modal window. It appeared to have worked, and an e-mail confirmed as much. The charge showed up on the credit card statement a couple of days later, further confirming that it worked.
Talk about lazy programming. If your form can detect a problem, it's also capable of telling me what that problem is. It's also clear that someone didn't test submitting the form with errors, because they would have realized that the modal window prevents users from trying to fix the mystery problem and probably scares most users into giving up.
Finally, let's assume there really was something wrong with our input. It seemed like they were only running client-side validation on the form. Not only is that lazy, but it's a horrible idea because people like me will do what I did: Turn off JavaScript and bypass your validation (I always use at least server-side validation, although I often include both).
That's just one example, but I constantly wonder why things can't just do stuff for me. I guess I just expected too much out of the 21st century.
I was just doing a form at work. It asked for the date. I put 12 Mar 2010. It immediately erased the field and popped up a little cue bubble (I don't know what they're really called) that said, sternly, Date MUST BE in format YYMMDD - which is hardly standard where I work. And could have been on the dang form.
Thomas J. Brown said:
You‘re absolutely right about lazy programming…….
Lazy programmers will always be around, for as long as the software industry exists.
However “Lazy programming” is not always the reason for developing poor user experience, other reasons are lack of experience and sometimes unreasonable project plan; hence we can’t always blame the programmer. Years ago, I switched career from Electrical Engineering to software programming. My only training was reading a “C programming book” over a long holiday weekend, and started coding a week later. No supervision, guidance or code review, to help me improve my programming skills and to perform quality control. Hmmmm… imagine the quality of that user interface? I wasn’t being lazy, just didn’t know any better. Couple of years later, I got a programming job in a research center, working with a group of experienced programmers; they helped me to hone my skills tremendously. As part of that process, I began to grasp the concept of robust error handling with meaningful error messages to the user, and friendly user interface to correct the none canonical inputs such as stripping the extra blanks or dashes and so on.
In terms of unreasonable project plan: I remember being a lead programmer in a software development project in 2001. It was rather a sweat shop than a software development house. The time line was absolutely un-reasonable, we were working 15 hours a day, 6 days a week to be on schedule. The management motto was that of “we don’t have the time to do it right the first time, but we can afford to do it all over again”. Obviously coding under stressed condition diminishes the precision; hence the programmers were focused more on the functional piece than quality error handling or the user friendliness. They weren’t being lazy; they were exhausted and pushing to meet the deadline.
@HRH: Both valid points. As someone who is self-employed and knows better, I forget that not everyone has the experience and luxury of time that I do.
I was also self-taught, and much of my early code was... Less than elegant.
I've also worked on projects with a "get it done, then get it right," mentality. It's strange, the "get it right" part rarely seems to come about...
I guess I was sloppy (or lazy?) in calling it “lazy” programming. I really did mean to include corner-cutting for whatever reason: laziness, sloppiness, inexperience, unreasonable schedules, bad management, whatever. The results are programs that make the end user compensate for things that the programs could have — and should have — taken care of.
Post a Comment