The work of lunar habitat designers was studied in order to learn about the work process of innovative cooperative design in a complex domain. Lunar habitat design seems to call for computer support because of the volume of technical information and governmental requirements, as well as because of the other-worldly setting in which the designers’ tacit skills may be unreliable. It seemed wise to explore how lunar habitat designers work now without substantial computer support in order to envision new ways to support the old goals and to imagine how computer support would transform the tasks involved.[1]

The episode transcribed in Chapter 3 showed an important turning point in a design process: the application of the concept of privacy to the task at hand. The tacit notion of privacy was eventually operationalized with the idea of defining a privacy gradient, according to which public and private areas of a habitat are distributed based on their privacy ratings. The concept of privacy then provided a paradigmatic example for investigating the design rationale issue-base provided to lunar habitat designers by NASA: the Manned Systems Integration Standards (NASA, 1989a). Here it was seen that this important concept of privacy had largely eluded NASA’s extensive efforts to provide propositional rules for the design of space-based habitation. Although privacy was acknowledged to be an important issue, NASA failed to provide support for designers to take privacy into account.

The present section will build on the discussion in the transcript and the critic definitions to show how Hermes can respond to the challenge of providing computer support for considerations of privacy. A scenario will show how lunar habitat designers could use the Hermes system to define a powerful set of privacy critics using the hypermedia links, perspectives, and language of Hermes. The detailed explanation of how the critics are evaluated by the system will be saved for Chapter 10.

Desi’s perspective. Suppose that instead of sitting down together with pencil and paper, Desi and Archie had been part of a team that worked in a design environment built on the Hermes substrate. Desi, Archie, and two other team members (Phyllis and Sophia) are asked to design a lunar habitat for four astronauts to live in for 45 days. They decide to take turns working on the design in Hermes, starting with Desi.

Desi begins creating a perspective for his new work, which he names desi’s habitat perspective. He defines this perspective to include (inherit) the information collected in a number of specialties and domains that he considers relevant to the design task. Then he selects two other lunar habitat perspectives and copies individual items of graphics and design rationale out of them for the lunar habitat shell, bunk-bed crew compartments, and a wardroom (dining and meeting room) arrangement. He inserts these into design rationale and graphics in his perspective. Then he adds some rectangles to represent the bathroom and galley (kitchen). The resulting layout is shown in Figure 9-1 (reproduced from Figure 3-2 of Section 3.2).

The main functional areas of the habitat have been laid out in this sketch. This is an initial design concept. Because other team members will be reviewing this design and wondering why things are arranged the way they are, Desi adds some design rationale, arguing that the bathroom and galley have all been placed together in a “wet wall” configuration to minimize plumbing arrangements. Desi feels his design provides a good start for the team and he goes off to work on other projects.

Archie’s perspective. Archie is interested to see what Desi has designed and to critique it from his own viewpoint. However, he does not want to destroy Desi’s version. So Archie defines archie’s habitat perspective as a new perspective and lists desi’s habitat perspective as its inherited perspective. This means that Archie will start off with everything that is in Desi’s perspective, but as he makes changes to it the changes will only be in effect within Archie’s perspective and not within Desi’s. The inheritance is active in the sense that if Desi subsequently modifies something in his perspective that Archie has not changed in his then the modification will show up in Archie’s perspective as well (unlike if Archie had simply made his own copy of Desi’s design at some given time).

Archie also inherits a number of additional perspectives with useful technical information. The hierarchy of perspectives incorporated in Archie’s perspective—including those he inherits via Desi’s perspective—are pictured in Figure 9-2 (below).

Archie is concerned with spatial adjacencies. He likes the way the crew compartments have been separated from the rest of the habitat to provide relief from the daily activity. However, he dislikes the acoustic proximity of the toilet (which flushes loudly) to the beds. Even worse, he finds the opening of the bathroom into the eating and gathering area potentially offensive. Archie is unsure of how to handle the bathroom, so he switches to a perspective that he has not inherited, the perspective for residential (terrestrial) bathrooms and browses the issue-base section on the design and placement of bathrooms. This perspective inherits from several other cultural and domain perspectives, including European perspectives. Here he finds the idea that showers and toilets have rather different location and adjacency considerations in the European tradition.

Note that Archie has access via Desi’s perspective to information in the lunar, space-based, habitats, noise, vibration, and dust perspectives, as well as additional information related to housing and galleys.

Applying these ideas in his mind to how he projects life in the habitat, Archie concludes that the shower should be near the sleep areas, but the toilet should be near the other end of the habitat, by the entrance. Moving the shower gives him the idea of elaborating the separation of the sleeping and working areas by forming a dressing area incorporating personal stowage. He redesigns the galley based on other ideas he finds and feels he has reached a stopping point. (See Figure 9-3.) He copies the rationale from the bathroom perspective concerning the separate location of the shower and toilet, revising the rationale to apply to the lunar habitat.

The toilet and shower functions have been separated using the European perspective on bathroom design.

Archie revises the design rationale for the habitat. Within his perspective, he can modify or add to (annotate or author) anything in the issue bases he has inherited from Desi or from the other domains. He does this in preparation for the up-coming team meeting. Before the meeting, the team members each review Archie’s design and its rationale by displaying it in Hermes. First, they discuss the over-all design. They like the creation of the dressing area between the shower and the personal stowage, but argue that it blocks traffic flow. A consensus is reached when Phyllis drags the dressing area to the other side of the crew compartments in the Hermes construction area.

As a group they deliberate about the issues in Archie’s rationale section and agree that habitation issues must be the primary focus of their designing on this project. In particular, privacy is a key concept. In order to make the notion of privacy operational for evaluation by interpretive critics, they decide to label the parts of the habitat with privacy ratings. They agree on the following scale with values from 1 to 9:

They define a link type, privacy rating, and use this type to link each area of the habitat to a node with one of the above numeric values (or their equivalent label). This process is facilitated by the Hermes interface: clicking on an area like the shower in the habitat brings up the same Navigating the Hypertext dialog seen in Figure 8-3 (in Section 8.3). Selecting the Author or Annotate option allows them to define a new numeric node with the value 8 or quite private and to connect it to the shower with a privacy rating link automatically. Figure 9-4 below shows the lunar habitat design the team has come up with, labeled with the agreed upon privacy ratings.

At the end of the meeting, Sophia and Phyllis agree to develop a suite of privacy critics that can be used for this and future lunar habitat design assignments.

Sophia’s perspective. Sophia sets up her perspective to inherit all of Archie’s work (and, indirectly, Desi’s). Now Sophia must define the terminology to be used in her critics. She is interested in determining problem areas in which private areas are too near to public areas. By “too near”, Sophia decides she means less than five feet. So she defines a “Measure” in the Hermes language named too near as:

Then, she defines public and private areas in terms of the ends of the privacy scale:

private areas: parts that have privacy ratings that are more than somewhat private

problem areas: private areas with public areas of that (last subject) that are too near those items

Then, Sophia defines a message for her critic to display if no problem areas are found:

This critic, privacy check, is a predicate that can be applied to any node or list of nodes in the database. When Sophia applies it to her lunar habitat design, it lists the name of the design and then lists all the problem areas in the habitat by their names; if no problem areas are found, it displays the privacy message. Figure 9-5 shows the output from applying privacy check to the design of archie’s lunar habitat shown in Figure 9-4:

Note that all private areas are listed by name. Under each of them are the public areas that are too near to them. The way this critic is defined it supports the designer’s review of the information. Sophia gets a complete listing of private areas from which she can check just what problematic adjacencies each has so she can also make sure the critic is doing exactly the computation she wants it to.

Debugging of critics is an important process, particularly since much of the computation is implicit in the language expressions. The privacy check is a fairly complex critic that Sophia has developed and debugged gradually. Once she is sure it is working, she can use it as a basis for more complicated evaluations. For instance, the display of the lunar habitat design in Hermes does not actually include the privacy ratings that were shown in Figure 9-4. So Sophia decides she wants to print these values out along with the listing of areas. To do this, she defines a new critic that prints out both the name and the privacy rating of each listed area:

The result of applying this critic to archie’s lunar habitat is shown in Figure 9-6. (The names of the privacy ratings are shown in bold.)

Now that Sophia has gotten her critics working the way she wants them to, she decides to make them general enough to apply to lists of objects. Then, as more habitats are developed in the Hermes database and are labeled with privacy values, designers can use Sophia’s privacy critics to display catalogs of interesting habitats. This is illustrated in Figure 9-7. This way Sophia can quickly find examples of problem areas in past habitat designs to help her deliberate about when such adjacencies might in fact be acceptable.

Phyllis’ perspective. Phyllis is a super-user of the Hermes language. To test its power, she tries to define a critic that involves a complex series of computations. By using an advanced feature of the language (explained in Section 10.3 below), she succeeds. Phyllis recalls previous discussions between Desi and Archie (from Chapter 3) that proposed the concept of a privacy gradient. That meant that the arrangement of the habitat should gradually change from private areas to public areas. To operationalize this notion, Phyllis introduces a test to see if any two areas of the habitat that are near each other differ in their privacy values by more than two.

Phyllis defines the following set of definitions to compute problem parts in her sense:

are incompatible: have privacy ratings that are more than privacy ratings of that (last subject) + 2 or are less than privacy ratings of that (last subject) -2

problem parts: name and privacy ratings of other parts that are too near that (last subject) and that are incompatible

These definitions illustrate the limits of the Hermes language, calling upon advanced features of the language that only experienced users of Hermes would feel comfortable using to create new expressions. The wording of some of Phyllis’ expressions are no longer intuitive because their computations refer outside of the expressions used to define them. In fact, the wording in such cases is designed to interrupt tacit understanding and to stimulate reflection on the explicit computational relations. Fortunately, this complexity is generally encapsulated in the names of the expressions so future users need not always be concerned with it.

Note that Phyllis has defined a measure with the same name (too near) as one of Sophia’s, but with a different value. This is not a problem since they are working in independent perspectives (even though they inherit much of the same information from other perspectives.)

To complete the privacy gradient critique, Phyllis defines a format for listing problem parts and she specifies a message for the case in which no problem parts are found in a habitat:

privacy gradient message: “The parts of this design are arranged along a privacy gradient.”

privacy gradient critique: either privacy gradient listing of parts or privacy gradient message

Like Sophia, Phyllis wants to apply her critique to all habitats in the database. Note that in the following definition for this procedure Phyllis first filters the list of habitats to just those for which privacy ratings have been defined. This produces a list of habitats for which issues of designing for privacy are most likely to have been thought through and to provide relevant ideas and rationale.

For these habitats, it is indicated which meet the criteria of following a privacy gradient and where the problem areas are in those that do not. A sample result is shown in Figure 9-8. Here is Phyllis’ final critic rule or display expression, privacy gradient catalog:

name with privacy gradient critique of habitats that have parts that have privacy ratings

The team perspective. When the team comes back together, they are enthusiastic about the power of the privacy critics to automate some complex analysis of habitats for them. Desi says, “I never tried to define anything in the Hermes language; I just make little adjustments to the display definitions and critics that I find already in the system. They usually meet my needs. But these new critics do things I could never do before. And I think I understand them well enough to use them and maybe even tweak them.” “Yeah,” chimed in Archie, “I never used the advanced syntax options for dealing with graphics and distances. Maybe I can learn how to do that by playing around with these privacy critics. Can you put them all in a perspective where we can experiment with them?”

Sophia was happy to oblige: “Sure. The thing we need to be careful about is the definition of too near, because Phyllis and I disagree on that. Let’s make the default for that 5 feet, okay?” She created a perspective called lunar habitat design team that anyone could inherit from to experiment with the critics or to pursue their design work further. She had the new perspective inherit from both the sophia perspective and the phyllis perspective, making sure she listed the sophia perspective first so that its definitions would override in case of conflicts, as with the definition of the expression too near.

Figure 9-9 shows the dialog box for creating the new perspective. Figure 9-10 shows the new hierarchy of defined perspectives.

[1] This “dialectic of tradition and transcendence” in work-oriented design of computer support systems is a central theme of Ehn (1988). The transformation of tasks as a result of computer support is also emphasized by, for instance, Hutchins (1990) and Norman (1993).

9.1. A Scenario of Cooperation