A programmerism (or programmer-ism) is the inappropriate use of technical terminology used in various interfaces, which can lead the user to feel that the interface has been written in a foreign language. When a programmer or a system developer designs technical language into the interface of a product, the programmer is confronting the user with terminology that will confuse the user, make the user's task more difficult or impossible at worst. The technical terminology may be very relevant to the programmer or even the most 'correct' in technical terms, but it is still irrelevant to the user. Consider the following example (the screen dump is taken from the text editor Metapad).
The error message above appeared when the user tried to save the file being worked on. The error message uses the concept of a "process", which is not familiar to a non-technical user and will thus be confusing. Not knowing what a process is, the user is left to her own devices and must guess how to solve the problem. And since this is about saving her work, the incident will most likely be very stressful as she does not know if her work will be lost.
To the programmer, however, there is nothing alien about the error message. In fact, using the word "process" instead of "program" may in fact be more technically correct. For the technically curious reader, a process is the sequence of states of an executing program. A process consists of the program code, private data, and the state of the processor, particularly the values in its registers. Also, the process may have other associated resources such as open files (Free Online Dictionary of Computing). In our Metapad-example from above, the programmer confronts the user with this technical complexity and thus forces the user to derive which consequences it will have for what she is trying to accomplish (in this case, save a file). If the user cannot make out what a process is, she will not know how to save her file.
Differing objects of interest
It is important to keep in mind the difference in focus between users and programmers. Users are not (necessarily) interested in the technical aspects of computers, but use them as means of or tools for achieving their goals/completing their tasks. The user's focus is on her task or, more generally put, some subject matter and from the user's perspective the computer merely acts as a subsidiary tool that is put to use in this activity (see transparency). The programmer's object of interest, on the other hand, is the computer, and acquiring computer-related knowledge is an objective in itself. This may be part of the reason that system developers/programmers do not speak to the users in the user's own language as they fail to recognize that the user's domain of relevance when using the computer/the application is different from the developer's.
Determining the right amount of technical terminology
- Starts in X days–96% booked: Quality Web Communication: The Beginner's Guide
- Starts in X days–93% booked: Get Your First Job as a UX or Interaction Designer
- Starts in X days–96% booked: Information Visualization: Getting Dashboards Right
- Starts in X days–93% booked: User Research - Methods and Best Practices
The take-home-point of the above, is that the user should be addressed in the user's terms. This does not mean that all interfaces should communicate in abstract and completely non-technical terms or that technical terminology should be eradicated. Rather, an appropriate level of abstraction should be found so that the user is exposed to an appropriate amount of technical terminology. It should of course be acknowledged that technically generic terminology, once learned, is generalisable across many applications/products with the same underlying technical architecture.
As a final note, the actual reason the error occurred in the Metapad program (figure 1) was that the file being worked on was opened by another instance of the Metapad program. The user did not know that the file was open in two instances of the same program and when trying to save the file from one instance of the program, a file system write error occurred because the other instance had a file lock on the file. This scenario could have been entirely avoided with a few lines of code added to the Metapad program. In other words, there was absolutely no reason for the error message to be there in the first place.
- Free On-line Dictionary of Computing, Edited by Denis Howe(Original database files available at foldoc.org). [<a href="http://www.interaction-design.org/dictionary/advancedsearch.php">Accessible online</a>]
- iarchitect.com (-0001). Interface Hall of Shame: Terminology. Retrieved 2003-08-07 00:00:00 from http://web.archive.org/web/20020602184113/http://www.iarchitect.com/clarity.htm