Social issues are critically important for interface design; this can be seen as part of the general point that it is always artificial to separate social and technical issues. Let's start with the importance of the social for engineering in general, looking at some "wisdom" quotes from experienced engineers, who say things like

In real engineering, there are always competing factors, like safety and cost. So real engineering is about finding the right trade-offs among such factors.

It's the "people factors" that always cause the most trouble.

Engineering is all about finding the right compromises.

Companies spend a great deal of effort training employees in social skills such as how to conduct a meeting, ethics, management skills, group skills, etc., and many say that such skills are essential for advancement. Also note that there is a recent trend in engineering education to include courses like "Engineering Ethics" and "Engineer in Society". For example, UCSD has introduced a course in "Team Engineering" (ENG 101).

One can also cite many large computer disasters, such as the $8 billion FAA air trafic control modernization default, the Atlanta Games sports data fiasco, the Denver Airport baggage system failure, the default on database modernization for DoD, the London Stock Exchange modernization collapse, and the UK National Health Service information systems disgrace; in each case, social issues were very deeply implicated. What all these disasters had in common is that they were impossible to hide, which suggests that they are in fact the tip of an enormous iceberg of failures which were never made public, such as the near failure of Bank of America in the late 80s (due to a botched database system upgrade).

Studies from "software economics" show that for large projects, most of the cost of error correction comes from errors in requirements (approximately 50%), while the smallest part (maybe 5%) comes from errors in coding, and the rest comes from errors in specifying modules (maybe 20%) and in overall system design (maybe 25%). Of course, these figures vary widely among projects. Another important fact is that most projects are cancelled before completion, again usually due to requirements problems. It is therefore very significant that the most serious problems with requirements have a strong social component.

Of course to see that all this is relevant to user interface design, you have to accept that user interface design is a branch of engineering with a great similarity to software engineering. To me this seems obvious, and it is also very well supported by experience; I would say that these two fields differ mainly in their scope. So the conclusion of all these arguments is that user interface designers have to take account of social issues or they are much more likely to fail. Note that to speak of "social issues" as separate from "technical issues" is questionable, and many modern social scientists (such as Bruno Latour and Leigh Star) claim that they really cannot be separated. However, they are often separated "for some immediate practical purpose," and of course it is convenient to speak of "social factors" even though they never exist in isolation, as long as one realizes the limitations of this way of speaking. Blended terms like "socio-technical systems" are better, although they still suggest a separation, and also may be more difficult to understand.

A couple of years ago, I attended a meeting at UCSD which discussed the so called "digital divide", and was surprised at some of the opinions expressed. One person seemed to think that just throwing technology at the problem could solve it, or at least, make a major contribution, noting that very large amounts of grant money were available for this. Another wanted an extensive survey of views of people currently without computer access on what they wanted. (But another participant recalled a recent large survey of this kind done in Chicago, which found that the top two items for what poor people there wanted were: (1) some way to ensure that their trash would be picked up; and (2) inexpensive child care. Alas, these are not the kinds of thing that the internet is good at.) Several wanted a detailed survey of organizations involved with computer literacy, and of facilities currently available; in fact, these already existed for San Diego. Others wanted to emphasize training through grass roots community organizations.

Only one participant seemed to realize that information and services on the web in their current form are not suitable for many people who could certainly benefit from them if they could access them. This person cited a study done in Birmingham about a project to provide information about cancer over the web. It seems that many people were intimidated or confused by the way all this information was organized and the language and social conventions that were used, and as a result jumped to sometimes unwarranted conclusions, such as that they had learned for sure that they were going to die of cancer soon.

This paper was written for a conference in the area of software engineering that is called requirements engineering, which is concerned with determining the properties that a system should have in order to succeed when it is built. Obviously, the user interface is one area of concern for requirements, and in fact, everything in this paper applies to user interface design as a special case; in general, you can just substitute the phrase "user interface design" for "requirements engineering" to get a paper that reads as if it were written for this course. The paper goes much deeper into the theories behind interviews, questionaires, focus groups, etc. than our text does, and in particular, it provides theoretical tools for understanding why various techniques are unlikely to work in certain situations.

One concept of particular relevance to user interface design is that of adjacency pair, because it can be used in exploring the naturalness of many dialogue-like featues of interactive systems, such as login and logout procedures for operating systems. Moreover, the related notion of noticeable absence can be used to explain why an interaction with a computer system seems unnatural when the systems fails to produce second part of an adjacency pair after the user has produced the first part. Note that login-logout is not an adjacency pair, because a logout is not necessarily expected after a login, and even if it does occur, may be separated by a very large time lapse; in particular, the lack of a logout is not a noticeable absence, thus confirming its non-participation in an adjacency pair.

I would like to emphasize that there are many interesting instances of adjacency pairs in computer interfaces. For example, in UNIX when we say we want to erase a file, if we have properly redefined the "rm" command, then we will be asked if we really want to remove each file, and we must respond in order for the action to be accomplished. Logging in and logging out each provide an example of an adjacency pair. However, there are many examples of such pairs in graphical systems where the design is poor; for example, the user may be forced to acknowledge the occurrence of events that are basically trivial by clicking on "OK," or may be annoyed by popup windows that contain distracting or even irrelevant information. The careful empirical studies in ethnomethodological conversation analysis of how adjacency pairs are organized in ordinary conversation can provide designers with many useful examples, and with hints on how to do better.

Recipient design is a term from ethnomethodology that refers to the phenomenon that natural speech is always designed for its specific recipients in a specific social context, and usually bears specific evidence of that design. It is a good exercise to find examples of recipient design in natural language used in everyday life; almost anything can be seen in this light. Recipient design is as defined above is more precise than nuance, which refers to the contextualizations that people use to make signs (e.g., speech) work in everyday life; note also that nuance carries the connotation of being subtle. A brief webpage on speech act theory and mitigation has been written for this course; mitigation is a very interesting example of receipient design, and it is precisely what "The Coordinator" did not allow.

This paper is a short summary of points that are important for us, from the large literature on CSCW - which stands for Computer Supported Cooperative Work, a subfield of HCI that is particularly concerned with the social aspects of interface design. This paper is very condensed, and uses some terminology that may not be familiar. For example, the word "nuanced" refers to the very common tendency of people to match what they say and do to the particular situation that they are in; e.g., most people speak differently to babies, todlers, elementary school children, and native speaking adults; they also behave differently at a tuxedo-wearing formal dinner party than at a beach party. In fact, almost anything that humans do exemplifies nuance.

Many large systems - and even some companies - have failed through ignorance of points that Ackerman makes. For example, the UK National Health Service sponsored a number of multi-million pound information systems for hospitals that failed because the doctors and nurses who had to enter the data disagreed strongly with the philosophy of health care that was built into these systems, and therefore sabotaged them by not using them and/or by entering misleading information. "The Coordinator," an ambitious system intended to improve corporate communications, failed and brought down the company that built it, because it tried to impose a communication style on people that it turned out many of them hated, because it was impossible to frame many communications in an appropriately nuanced way. (This system is, for example, discussed briefly on page 484 of the third edition of Shneiderman.) There are many many more examples like these.

Change is inevitable, unending, and unpredictable, especially in user interface design. Many changes are related to (what has been called) convergence, which is the merging of computers with communications, plus of course "Moore's Law" (which is not a law at all). In user interface design, this can be seen in the evolution of HCI towards CSCW: whereas traditional HCI focuses on an individual user of a single system, CSCW addresses the social issues that necessarily occur when individuals communicate within communities, which of course they (nearly) always do. The effects of change are illustrated by the webnote Art and the Zen of Web Sites, much of which is now badly out of date.

One aspect of the original HTML philosophy (as developed at CERN, a physics research center in Switzerland) is that source texts should only use structuring commands and never use layout commands, so that browsers are able to choose the best presentation compatible with their capabilities, e.g., audio output for blind users. Now consider the HTML source code for the following clickable "button sign" constructed from a table with background:

Is this complex sign consistent with the original HTML philosophy described above? (The best way to learn more about HTML is to use your browser to look at source code.) Note that the HTML language has changed a great deal, in response to pressure from users, such as advertisers, who have very different goals than the original community of high energy physicists.

The paper Introduction to Methods and Generalizations, by Gilles Fauconnier, first outlines an entrenched traditional position in linguistics, associated with Noam Chomsky and his formalist school, then sketches some arguments against it, and finally sketches aspects of his own program of cognitive linguistics, and more generally in cognitive semantics. We will return to this paper and its issues later in the course.