The Computer As Medium

I’m reading Peter Bøgh Andersen’s A Theory of Computer Semiotics (kindly donated by Håkan). Very interesting. The introduction to its second part begins like this:

It should come as no surprise that the interface [...] as a collection of computer-based signs, and its functions relative to the linguistic environment and working context reign supreme in this approach [of seeing the computer system as a medium]. The basic function of a system is to generate processes in which an interface can be expressed, just as the only reason for having the costumes and wings in a theater is the experience they may contribute to giving the audience.

So software development in Andersen’s approach is centered around the user interface, which is something he says his it shares with user centered design. Furthermore, it is seen as a collection of signs (this is what semiotics is about), which are chosen as a result of analyzing the working language of the future users. And lastly, the interface is seen as something that emerges as the software is used, not as something that exists as a discrete component among others.

This view makes it difficult to maintain the tradition of separating functionality from the interface. Traditionally, functionality is what can be done with the system, while the interface is the manner in which it is done. [...] I find it impossible to maintain that distinction here, since aspects of the functionality contribute to the interpretation of the computer-based signs.

He explains this with an example of a pencil icon, which would be interpreted as a drawing tool if it follows mouse movements, and if pressing the button would result in something being drawn. But if it was static, it would be interpreted as “a signpost,” signifying perhaps that the user has write access to a file. So this is a difference in functionality, and “since it determines my interpretation,” Andersen writes, “it must be incorporated in my notion of interface.”

The statement that the computer is a medium for communication implies that it is the designer of the software who communicates with its users. The software isn’t a participant in this communication, but the medium through which it takes place. The language of this communication is, or should be, Anderson writes, rooted in the working language of the users. This of course means that the working language must be analyzed as part of the development process. However, this analysis isn’t something that can be done once and for all, at the beginning of the project. So this approach seems to support incremental approaches.

[N]ot all aspects of functionality belong to the interface. For example, in a drawing program, there may be differences in the algorithm implementing the drawing actions of a pencil tool [...] but if these differences do not influence my classification of the actions [as] drawing, they are not part of the interface, but only expression variants. However, we cannot say in advance that a particular part of the system structure is irrelevant to the interface since this can only be ascertained by applying the commutation test when the system is used.

The commutation test is, Andersen writes, “the most important tool for the linguist.” He goes into it in quite detail, but I’ve only skimmed through those pages. As I understand it, though, the commutation test is an analysis that can be used on different levels of how language is used, not only verbal language. Since the computer is the medium and the user and designer communicates with each other through this medium, the language they use is the language of the user interface, which is heavily influenced by the user’s working language. The commutation test then, I guess, tests whether this language, the language of the user interface, works.

Somewhere Andersen writes that the ideal is to adopt concepts already in the working language and make them signs in the semiotic system that enables the user interface to emerge. But this can’t always be accomplished. Often new concepts must be invented, and these in turn will affect the working language. So the commutation test probably analyses the verbal language of the users as they use and talk about the software. He ends his introduction to the second with these words:

[T]his method of structuring systems is neither common, nor unproblematic. In fact, [more common is] a quite different view of system architecture [...], where the computer system [is] viewed as a model of reality [...]. The designer in this method is like a play writer that first describes the plot of the play without regard to its theatrical effects, and then later puts selected episodes on the stage. [...] From my point of view, the designer should not see herself as a natural or social scientist describing real objects or persons. Instead she should compare herself to the more humble position of a play writer or stage director—people that basically do not describe or create real persons or events, but only painted canvas, fake uniforms, and would-be dramas that the audience in lucky circumstances may use to create real emotions and insights. The system structure only specifies cardboard actors on the puppet theater of the computer screen.

See Peter Bøgh Andersen’s homepage for several interesting articles (judging by their titles). And you can search inside this book on Amazon.