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
Figure 1: Error message when trying to save an opened
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
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
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.