Despite its title, Chapter 15 of Shneiderman 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, although this is a hot area today. It may sound far out now, but virtual reality interfaces to large databases could well be important in the future.
Shneiderman's (mostly implicit) criticisms (pp.515ff) of the interface designs 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. Shneiderman's classification of task actions (pp.512-3) is suggestive but a bit 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 important today, e.g., in scientific visualization, of course for the temporal dimension, but also for others. It is important to note that what Shneiderman classifies as 1D (i.e., linear) structures can have a great deal of additional sturcture attached to them, as his examples (p.524) clearly show: textual documents, program source code, and alphabetical lists of names. In particular, each of these can profitably be seen as having a tree structure (e.g., programs have parse trees).
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) might seem obvious, but as Shneiderman says, it has wide applicability and is easy to forget. On the other hand, there are also many situations where it does not apply.
Some of the data visualization schemes seemed 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 (obviously) supported by commercial web search engines (they are implicit). I was surprised to see what may be a joke (however lame), on p.523. What he calls "collaborative filtering" is part of what Ackerman considers more thoroughly in his Answer Garden paper. Except for the brief discussion of collaborative filtering, the social dimension is largely absent from this chapter, which is why we are reading Ackerman's Answer Garden piece.
One very instructive and important class of applications for semiotic morphisms is the construction of overviews, summaries, or visualizations for bodies of information, such as scientific data. Here the source sign system is for information structured in some particular way; examples include books, source code for programs, and websites. The approach that I recommend is to first determine the highest priority constructors and selectors of the top level; then design a target sign system to display this information in the required medium; and then design a morphism to preserve the selected structure and omit the rest; if more information is desired, then consider other levels with their highest priority constructors and selectors. Remember that the whole point of an overview of a large dataset is to delete most of the information while preserving enough to survey the key points. Principle F/C is relevant here, saying that when something must be sacrificed, it is more impotant to preserve form than content. It is very likely that some experimentation with the output will be required to achieve good results; user trials, interviews, etc. are recommended.
Let's first consider books. If you look at the physical structure of a book, you will see that it has the most important information printed on its front cover and spine, and that inside it has pages; basic information on the cover and spine include title, author, edition number, and publisher; this information also appears on the title page inside, along with the date of publication (or possibly this is on the back of the title page - publishers may want to make the date harder to find, with the hope that users may not realize that a book has become old). Looking at the contents, you will see that chapters are (usually) the main structuring device, and that their main selectors give a chapter number, a title, and a page number; chapters are (usually) divided into sections, and possibly subsections, each of which also has a number, title, and page. I think these are the things that anyone would eventually discover, even if they were not already familiar with books. Taking them as constructors and selectors, with target medium a small number of printed pages, yields exactly the very familiar form known as an outline. Notice that the entire content of the book has been lost (unless you count titles as content).
Another example is source code. Surely the most important structuring device is the division into files (if there is more than one file). To see what attributes (i.e., selectors) are important, we can check what the unix ls command displays under various options. For example, ls -lat will display the files in a directory, with their name, owner, size, and date of last modification. If we preserve these and display them in a natural way in a color graphics window, taking account of human perceptual capabilities, we can get something much like the display of Plate B1 (just after p.514) in Shneiderman, which displays the age of a file using color, and its size using length. Notice that the entire content of the program, i.e., all of its code, has been lost (however, it can be viewed with the zoom feature that this system also provides).
It is easy to find many other examples. Please recall also the detailed analysis of scrollbars that was given in class (and is briefly summarized in section 6 of the class notes). The conclusion is that algebraic semiotics provides a powerful tool set for designing and evaluating user interfaces in general, and database interfaces in particular.
The following outlines a recommended semiotic methodology for using semiotic tools for the analysis of an interface:
Perhaps the deepest point about this paper is signified by the numeral "2" in its title: the system described here is the result of an iterative design process, in which an earlier system, named Answer Garden, was subjected to a careful evaluation, based on the experience of actual users, and then the results of this evaluation were carefully analyzed, pinpointing certain weaknesses in some underlying assumptions, such as a sharp distinction between experts and ordinary users, leading to new assumptions and a new design based upon them. The result is a typical example of what ethnographers call situatedness, and what designers call site specificity: one learns important and interesting things by evaluating a system in the context of a particular community, but those things may not generalize to other communities. For example, distinguishing experts from users might be valid in a different context, and the "escalation hierarchy" that Ackerman designed for this particular community might well not work for a different community. On the other hand, Ackerman's software tools could be valuable for building systems for many other communities.
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. For a commercial example, Amazon.com makes clever use of several forms of collaborative filtering.
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 significant social issues is Napster, which shares MP3 files over the internet. Over its short lifetime, this system has caused severe disruption of several campus computer networks, drawn huge lawsuits from the music industry, and has recently been absorbed by a large media industry conglomerate. However, this is far from the end of the story, since many informal peer-to-peer databases are still operating, and the music industry is being very agressive and paranoid.