Despite its title, this chapter is mainly about user interfaces for databases, with an emphasis on direct manipulation graphical interfaces. The kind of visualization done in scientific and engineering applications, such as aerodynamic flow over a wing, is not discussed at all, but should have been; this is a very hot area today. Though it may sound far out now, I believe that virtual reality interfaces to large scientific databases are likely to be important in the future.
Shneiderman's (mostly implicit) criticisms (pp.515ff) of popular web search engines are interesting and insightful, and the pictures are nice, especially the color pictures. The concise summary of database terminology (p.512) is good, especially if you never had a database course. As usual with Shneiderman's taxonomies, the classification of task actions (pp.512-3) is suggestive but vague. I like his four-phase framework (p.516 and the box on page 517); also his idea of organizing the discussion of interfaces by their underlying data structures (listed in the box on page 524) is genuinely helpful, though I dont think the organization is the best, and animation (i.e., changing the display over time) is not mentioned, though it is certainly very important today, e.g., in scientific visualization, of course for the temporal dimension, but also for others. Shneiderman's point about history (p.518) is good, though not always applicable, e.g., probably not much use for web search engines. (The idea he calls "dynamic queries" is almost too obvious to deserve a name.) The "mantra" (p.523) seems obvious, but as Shneiderman says, it has wide applicability and is easy to forget; but as he does not say, there are also many situations where it is not applicable.
Some of the data visualization schemes seemed a bit obscure; did anyone understand Figures 15.11 or 15.16? The parallel coordinates idea is great - but only if there aren't too many lines or dimensions (Fig 15.9); I also like hyperbolic trees (Fig 15.14) and treemaps (Fig 15.15). Shneiderman's explanation of why AND and OR are hard for users is right on the mark (p.542), and helps explain why boolean queries are not supported by commercial web search engines. What he calls "collaborative filtering" is part of what Ackerman does much more nicely in his Answer Garden paper. I was surprised to see what may be a joke (however lame), on p.523. The social dimension is almost entirely ignored in this chapter, which is why the Ackerman paper is relevant.
This paper addresses the important problem of integrating user communities with their computer systems. The old view of databases envisions a single user with a well formed query about a well understood and well structured collection of data. Just as HCI has evolved from a technical ergonomic level through pyschology to a social collaborative level, so databases are evolving towards taking better account of the communities in which they are embedded, including their shared goals and potential conflicts. The new view emphasizes the social side of sharing, restructuring and distilling information, and helping users help each other in various ways. Such tasks are especially important for huge databases of badly understood, poorly structured data. Thus, designing database systems is far from purely technical, and can easily fail from a lack of understanding the user community's structure and needs. Moreover, successful systems will evolve, because their user's needs (and many other things) will evolve; therefore they should be designed from the beginning to support evolution. Iterative prototyping, user scenarios (more generally "use cases"), usability testing, interviews, etc. are needed. All this was done by Ackerman in moving from his first version of Answer Garden to the second (AG2), which is based on a collection of modules that can be assembled in a variety of ways using Tcl/Tk.
A similar expansion of horizons is happening in many other areas of computer science, as people come more and more to realize that systems exist and must function within a social context, and that they can draw on that context to improve their operation in various ways. Ackerman's reconceptualization of a help system as a collective memory system illustrates the kind of rethinking that is going on in many areas. This trend is highly consistent with recent trends in software engineering, including generic architectures, modularization, libraries of reusable code, plug-ins, etc., with the evolution of HCI, and with the evolution of computer science as a whole.
Some specific techniques used in AG2 include an answer escalation hierarchy, anonymization, an engine to find experts, a statistics collection service, and support for collaborative authoring. All these have applications in many other areas, though they are far from exhausting the range of potentially useful modules.
A recent dramatic example of a large distributed database system with obvious social issues is napster, which shares MP3 files over the internet. Over its very short lifetime, this system has caused severe disruption of several campus computer networks, and has inspired lawsuits from the music industry.
The following is a general essay on the importance of the social for user interface design, 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 trande-offs among such factors.Edison and Westinghouse, in their competition about AC vs. DC for mass power distribution, toured the country, giving dramatic demonstrations in theatres. Also, Pasteur, who today would be called a "bioengineer," had to work very hard to get his "germ theory" accepted, and then found that innoculation was even harder for the public to accept than pasteurization. (Bruno Latour has a good book on Pasteur.)
It's the "people factors" that always cause the most trouble.
Engineering is all about finding the right compromises.
Companies often spend a great deal of effort training employees in social skills such as conducting a meeting, ethics, management skills, group skills, etc., and that they claim that such skills are essential for advancement. Moreover, there is a recent trend in engineering education to include courses like "Engineering ethics" and "Engineer in Society". UCSD has just started a course in "Team Engineering" (ENG 101), and CSE is starting a "Computers in Society" course.
There have been many famous large scale computer disasters, including the $8 billion FAA air trafic control modernization default, the Atlanta Games sports data fiasco, the Denver Airport baggage failure, the DoD database modernization default, the London Stock Exchange modernization collapse, and the UK National Health Service information systems disgrace, indicating in each case how social issues were deeply implicated. These disasters have in common that they were impossible to hide, so that they are in fact the tip of an enormous iceberg of failures, including the near failure of Bank of America in the late 80s, which was never made public.
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. And the final nail in the coffin, so to speak, is that most 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 is obvious, as well as 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 even more likely to fail. Note that speaking of "social issues" as separate from "technical issues" is highly suspect, because in fact, they cannot be fully separated. However, they can often be partially separated, and in any case it is convenient to speak of "social factors" even though they never exist in isolation.
The following is a little background on modern research in sociology of science and technology. In contrast to 19th century trend of making heroes out of a small number of individuals, late 20th century research often looks for the work that was done to make something happen, in particular, this may be the kind of "infrastructural" work that is usually left out in traditional accounts, e.g., the work of people who actually build that instruments used in physics experiments, or the people who somehow obtain the money to build a skyscraper. The research strategy that consciously looks for these omissions is called infrastrucural inversion (Susan Leigh Star) and the omissions themselves are called infrastructural submersions. One major example is that the hygiene infrastructure (especially sewers) of cities like London and Paris made possible the medical advances of the mid to late nineteenth century. And of course the experimental work of Newton would have been impossible without the advances in technology that made his experimental apparatus constructable. The same is true of high energy physics today, where (for example) low temperature magnets are an important and highly specialized support for particle accelerators.
Despite the mathematical character of the formal definitions of sign system and semiotic morphism, these concepts can be used very informally in practice, just as simple arithmetic is used in everyday life. For example, to see if we have enough gas left to drive from San Diego to Los Angeles, we make some assumptions, use some approximations, and only do the divisions and multiplications roughly. It would not make much sense to first work out an exact formula taking account of all contingencies, then do a careful analysis of the likelihoods, and finally calculate the mean and variance of the resulting probability distribution (though this is the sort of thing that NASA does for space shuttle missions). In user interface design, our goal is often just to get a rough understanding of why some design options may be better than others, and for this purpose, assumptions, approximations, and rough calculations are sufficient, especially when there is time pressure.
Recall Saussure's idea that signs always come in systems, with examples like the vowel systems for various accents within the same language, and the tense systems for verbs in various languages. The vowel system example illustrates how the same sign system can be realized in different ways; we call these different models. The vowel system example also shows that two different models of the same sign system can have the same elements but use them in a different way; so it is how elements are used that makes the models different, not the elements themselves. Models of sign systems are not just sets, they are sets with structure given by sign system that it models, including its operations, sorts, etc. Alphabets provide examples where the sets that underlie models may overlap; for example, the Greek, Roman and Cyrilic alphabets have some letters in common and others that are different. You cannot convey any information if your sign system has just one element (technically, the Shannon information content is zero).
Sign systems have an aspect of abstract data types, because the same information can be represented in a variety of different ways; for example, consider dates, times, and sports scores. This leads naturally to the idea that representations are mappings between abstract data types, as illustrated in the UCSD Semiotic Zoo, where exhibits show how some structure was not being properly preserved by some mapping. This is perhaps the most important idea of algebraic semiotics.