Judy Nollet
White Plume Communications

writer, instructional designer, eLearning developer

A Button By Any Other Name

Suppose I say "I'm a high-level programmer." Most people would be impressed, because the standard usage of "high-level" means advanced or complex. Programmers and other technical folks, however, would not think much of my skills. And rightly so, since when it comes to programming, the "higher" the level of programming, the further one is from machine code (the Øs and 1s that comprise the "lowest" programming language). Thus, a descriptor that means one thing to the general populace can have a completely different meaning to certain specialists.

And that's why programmers should not be allowed to name screen elements, nor write instructions.

Don't get me wrong. I have immense respect for programmers. Yet while they're amazing when it comes to writing code, they're usually not as adept at writing clear, concise English. Not to mention that they generally don't want to spend time doing that kind of writing.

Case in point: a button called "Manage Appointments." It's on the internal-use-only menu of a site that allows the public to schedule meetings with a professional by selecting a location and a time slot. (For confidentiality, I won't say what the appointments are for.) This site was produced by programmers with a few basic descriptions about the tasks needed, but not much else. In other words, the programmers were responsible for a lot more than programming.

Now, what do you think you'll be able to do if you click "Manage Appointments"?

  1. See which time slots are filled.
  2. Access information about who is scheduled.
  3. Adjust the time slots for future dates.

The answer in this case is "c." The real question then becomes "Is that the best name for the button?"

Once people know what the button is for, maybe they won't have trouble associating that button with that task. However, the task isn't performed often, so it may take an extra moment for them to recognize which button to use. Admittedly, it's not a major impediment to productivity. But that doesn't mean the button shouldn't be named more accurately. For example: "Adjust Time Slots." That's slightly shorter yet more precise.

Of course, as a writer, I'd like to say that the only way to get clear-cut names and labels is to hire a writer (certainly an excellent option!). An alternative is to ask some users. Yes, I realize this is not a radical, new idea. Usability testing is always appropriate. But, sadly, it is often skipped, generally with an excuse about budgetary and/or time constraints. This brings to mind the adage: "If you don't have the time or money to do it right the first time, how are you going to find the time and money to fix it?"

The most efficient software development I've seen was accomplished by programmers working from detailed scripts. At the very least, they deserve a basic flow chart and a list of standards to follow, which might include instructions about:

  • the use of screen titles
  • the field format to follow for dates, phone numbers, and similar multi-part fields
  • the convention for naming various screen elements

When multiple programmers are involved, the more vital it is to be sure they're all following the same rules.

In other words, give programmers what they need so they can do what they do so well. Let them write code.

return to list of articles

Copyright Judy Nollet, White Plume Communications. 
		All rights reserved. Email white plume at comcast dot net. link to email Judy

White Plume Communications logo
Contact information.  
	Email white plume at comcast dot net. link to email Judy

Want to read more? Return to the list of articles.