I don't know whether this'll be a series or not, but a dumb-as-a-rock aspect of the user interface at my local ATM prompts me to say something about lazy programming. I'm talking about cases where the programmer could have — and should have — made the program better with just a small amount of extra work and thinking... and didn't.
In the case of the ATM, it's in the segment where you select the account you want to work with. Here's how a deposit works, for example:
ATM: Welcome to the Bank of Your State ATM. What language?
me: [selects English]
ATM: What do you want to do?
me: [selects Deposit/Payment]
ATM: Enter amount.
me: [enters dollar amount]
ATM: [delays while looking up account information]
ATM: Which account? [displays list]me: [selects checking account]
ATM: Gimme the envelope. [opens access slot]
...etc...
Now, the thing is this: I have only one account at the Bank of Your State, and yet the user interface still shows me a list of accounts — rather, a list of account — from which I must select my lone account in order to continue.
This is lazy programming. It's trivial to check the list and see if there's only one entry, and to skip asking the user in that case. In the following pseudo-code, it's just the boldface lines that'd have to be added.
Retrieve account list;Basically, two lines of code to add, so that thousands of ATM users don't have to stand at the ATM screaming, “I only have one effing account here! Why do I have to pick it from a list of one?”
If number of accounts > 1 then {
Display list;
Get account from user input;
} else {
Get account from sole entry in list;
}
...etc...
One of the teleconference systems that we use at the office is like that too, and sometimes the person who's set up a meeting I'm attending has used that service. Here's the sequence for connecting to that, when I'm the first one to do so:
me: [dials teleconference number]
it: Welcome to the teleconferencing system. Please enter your meeting passcode, followed by the pound sign.
me: 123456#
it: Your passcode has been accepted. After the tone, please state your name, followed by the pound sign.
me: “Barry”#
it: You are the first caller to this conference. Please wait, while others join.
it: [announcing] “Barry” is now joining.
You'd think I'd know that I'm joining. You'd think that since there's no one else there to listen, there'd be no value in saying that. You'd be right. But the programmer was lazy.
It's the little things like this that make us snap and sit on rooftops with high-powered weapons. Look at what can be prevented with just a little care on the part of the programmer......
10 comments:
The classic, which has annoyed me for decades, is along the lines of: "There are 1 items in your search result". As with the cases you quote, it is very simple to substitute 'is' or 'are' as required, along with the matching 'item' or 'items'. Or even just change the output slightly, to "Number of items found: n", which covers all cases in a generic fashion.
Is it lazy programming, or lack of testing, or the marketing department promising the product in the amount of time it would take you to design it, if you were designing it properly, never mind code and test it, or is it hardware that has limited space for instructions...
I hate seeing programmers blamed for stuff that is often the fault of other people who don't understand the development process. A lot of programmers do really well under the ridiculous constraints set by the marketing department.
It's true that programmers are often victims of pressures beyond their control. Still, as a programmer myself, I have a good idea when that's the issue, and when someone's made a lazy omission or a rookie mistake. Failing to check a list for one entry (or no entries, which might cause a crash or a truly nasty UI experience[1]) falls in those categories. Tight schedules or absent testing resources don't excuse an omission like that.
—————
[1] Imagine a UI like my ATM uses, where a screen comes up with a list of accounts and a button next to each. At the top it says "Select account", and the only way to leave the screen is to push one of the buttons next to an account number (the rest of the buttons are disabled). Now suppose that the list is empty, and no buttons are enabled.
Seems like you'd just have to wait for the thing to time out and log you off. Yow!
The programmer is the least likely person to blame for this. It's unimaginable that a financial application like this one was not tested and revieweed thoroughly to see whether it met the client's requirements, or that the client did not approve of the design.
The ATM example is likely the result of lazy specification of requirements, or even possibly an explicit requirement that is intentional.
The customer may have requested that the accounts be listed no matter how many accounts you have so that you had an extra chance to verify that you are correctly depositing the money. Why? We can only speculate.
The screen comes up and tells you to choose the account (explicitly) where you want the money deposited. It is your chance to see if it is the correct account (in this case, a checking account.) There is an outside possibility that you'll see "Checking Account" and think: "Oops!"
Is this necessary? I don't know. For my own purposes, and in most cases, I likely wouldn't find it necessary. I merely illustrate that the client may have had a reason to approve of this design.
Possibly (likely, even) there were discussions among low-level people about this. Those people were probably programmers and those people probably were not authorized decision-makers. They may not have even had direct access to converse with decision-makers. I've been in such situations; you can argue until you're blue in the face and you won't get anywhere if you're talking to someone who thinks his ass is already covered and he doesn't want to take it up with the decision-makers.
I've also been that person who acts as the go-between and I have told programmers "this is what the client wants."
If an issue is important enough, it can kick up and modify the requirements after discussions with the decision-makers. If not, (or if the issue is just the result of the programmers disagreeing with the logic of the decision-makers) the requirements are fulfilled as-is.
«The customer may have requested that the accounts be listed no matter how many accounts you have so that you had an extra chance to verify that you are correctly depositing the money.»
That's a good point that I hadn't considered. I think it's a UI annoyance, but the "oops" point James makes is one I hadn't considered.
But, then, I have the "confirm delete" and "confirm close" stuff disabled just about everywhere I can. I hate it when I go to exit a program and it says, "Do you really want to exit?" À chacun, son goût (ou sa bêtise).
I agree - I like to disable those confirmations wherever I can.
"If I didn't want this file deleted, I wouldn't have asked you to delete it!" And I can scarcely remember any time when I've been saved from disaster by one of those confirmations.
When I see a design I don't like, I usually blame a lack of understanding of the problem on the part of the designer, an inability to design well on the part of the designer, or weird requirements from a confused person in charge. Programmers I blame for bugs, instability and inflexibility.
Of course, sometimes the requirements do make sense and I have merely misunderstood them. It happens.
There's at least one more step that could be removed from the ATM.
In Finland, the user's language preference is stored on the card. The "please insert your card" prompt is multilinugal, everything is automatically in your language of choice from there on.
I have, as a matter of fact, had the "do you really want to ...?" save me - I'm not that good with the little pad on my laptop (tremors) and often I'm hitting the X when I want to hit the minimize... Which is why I like to have the things there to turn off rather than not have them.
But your ATM interface sounds like it was made by PeopleSoft. There's an application I have to use on a regular basis at work which will step you through four intermediate screens, each of which has ONE option, before getting to the final screen. That annoys me intensely every time I have to do it.
It does seem like a rather unnecessary step. The only plausible reason I can think of as to why it's there (other than incompetence) is for learned behaviour.
I know where all the buttons are on the normal machine I use, and I can pretty much take out money without looking. If a step is suddenly added when you get another account you are prone to make a mistake.
However this could be avoided by positioning the buttons differently between the step before and after so that should you automatically move onto the next step nothing bad happens. Still doesn't then take into account if you continue on after that though.
Another good reason, from "icr". See, that's why I post these things — it's not just to rant, it's that sometimes I get new views, which I hadn't considered before.
I'm convinced that the ATM thing isn't just lazy programming. Maybe they fought that fight with the customer and lost. Maybe it's to remind you what account the money's going into, to prevent an, "Oops, I'm at the wrong bank!" situation. Maybe it's to provide a consistent UI in the event that the user adds an account (or removes one). Maybe all of the above.
Thanks for all the comments, everyone.
Post a Comment