Geek News

I have a request for all you programmers out there. Please, please, please say what you mean.

If programmers would label their program fields with words that closely describe what the field represents software would be so much easier to use.

Here’s an example from the Crested Butte reservation Web site. While booking a room recently I was shown a screen with four columns – one with a drop-down list box where I could select a number, one showing information about available rooms, one showing pricing and one with “select” buttons.

The first column was labeled “Quantity,” and I thought, “What are they asking me? How many people? I already told them that. How many nights? But I told them that, too. How many rooms? That would be weird, wouldn’t it? I can select up to six rooms?

“Travelocity and Orbitz ask how many rooms at the same time you select the number of nights and people. Did this program ask that? I don’t remember. No, surely it can’t be the number of rooms. There are just two of us. The price shown is per night, not for three nights. Maybe I have to select the number of nights.”

That’s how my thought process went.

Of course I figured out what it meant eventually. I selected what I thought were three nights, clicked a select button, realized I had just selected three rooms and went back and fixed it. Perhaps I could have got the right answer quicker, but I’d still have to think about it.

To quote the title of an excellent book on Web usability – “Don’t Make Me Think.” Tell me what you want. Instead of saying “Quantity” the programmer should have had a label that said “Number of Rooms.”

During my 26 years in software development I’ve learned that this is a common problem with programmers. They often pick obscure terminology instead of clearer terms. There are three reasons.

– Inside the program code programmers often use generic rather than specific terms. In this example the number-of-rooms information is being passed back to the Web server as the “quantity” field. That’s fine.

Everyone on the programming team knows what “quantity” means. Unfortunately these generic terms often find their way to the user interface. Nobody bothers to take the time to translate them into something more understandable to the user.

– Another reason is that programmers also like short terms – preferably single words. Why say “Number of Rooms” when you can say “Quantity?” It takes up less room and is quicker to type. It’s a bad idea in user-interface design when a few extra syllables can make software so much easier to work with.

– Finally, most programmers are really, really bad at user-interface design. Many will admit it or tell you outright they don’t really want to design “screens.” They would rather stick to the code.

I have a general rule of thumb: You should never allow a programmer to design a user interface. Sure there are exceptions. Just as there some football players who can ballet dance (consider Herschel Walker of the Dallas Cowboys and the Fort Worth Ballet), there are some programmers who can design user interfaces, but whether football and ballet or programming and user-interface design, these are not skills that generally go together.

The problem is there’s an assumption in all but the smartest and largest of companies that designing user interfaces is part of the job of programming. Programmers are routinely given the job of designing what a user interface looks like and how it works. Management just figures this is what they’re paid to do.

Now do you understand why so many programs are so hard to use?

So, programmers, if you’ve been given this task at least think about the words you use. Think about what words make sense to a user and employ those terms instead of more generic code talk.

Oh and while we’re chatting, here’s another pet peeve I’d appreciate if you’d fix. When I enter a credit card number I should be able to enter dashes or spaces if I want. That’s how numbers are written in the real world so I’d like to do it in Web forms. Let’s face it – it’s not a lot of programming to allow this.

But if you’re lazy and can’t be bothered to code the system to work with credit card numbers in various formats (Crested Butte programmers take note), don’t accept the number and then right at the end of the process tell me the transaction wouldn’t go through because it’s a bad number and then force me go to go back and enter all my contact and billing information from the beginning again.

That’s just plain rude.

Peter Kent is an e-commerce consultant in Denver. He can be reached at or