softwaredesign/raw/book/EssenceOfSoftware_Eng/concepts-241-270/concepts-241-270.md

ant, but our rst question should not be: what metadata elds are there and what is their structure? Rather, we should ask: what do people do with metadata? Can the metadata of a photo be changed? Can you change the capture time of a photo? Can the metadata be augmented with user-specic elds? What kind of sorting and searching can you do? When you share photos, can you erase metadata for privacy? ese are the essential questions that will impact the design of the photo library, and will likely lead to a richer concept of metadata than if we just assumed that the metadata of a photo was a static structure amenable to occasional updates.

Concepts have rich states. e structure of a concept's state, although secondary to its dynamic behavior, nevertheless plays a vital role. A trivial state structure may be evidence that a concept is degenerate and not really a concept at all.

Looking for state structure, as with behavior, can oen point us towards the real concepts. If the concept of password comprised just the password itself, along with some criteria for not being easily guessed, we wouldn't have much of a concept. But once we include the association between accounts and their passwords and usernames, we are moving towards a useful concept of authentication.

Occasionally, the state structure of a concept reveals something essential. In the style concept (see Figure 4.4 and Note 45), maintaining an association between elements and their styles is the key to propagating style changes back to elements. Without it, you have the "pseudo styles" of TextEdit that don't allow you to make changes to elements aer they've been formaed without reapplying a style to each element.

is is a nice application of an adage due to David Wheeler, a computer science pioneer at Cambridge University who worked on the original EDSAC computer and wrote the rst computer program ever to be stored in a computer's working memory. Wheeler said "ere is no problem in computer science that cannot be solved by introducing another level of indirection." e style concept achieves its eect—allowing multiple elements to have their format updated at once—by associating formats not directly with elements, but indirectly, through styles. In an email exchange that I had with Wheeler in 2001, he conrmed that he was the author of this adage, but noted that he usually followed it by something like "and this usually reveals new problems." (Another wise aphorism of his: "Compatibility means deliberately repeating other people's mistakes.")

I noted another example earlier of state structure revealing essential design questions: the upvote concept appears to most naive users to just associate a count—the number of votes—with each item. But to prevent double voting in which a user upvotes the same comment in a forum multiple times, say, the concept must track

not only the number of votes but also who voted for each item. Representing "who" becomes an interesting and dicult design question. To track users by their usernames, you'd need to have users be authenticated before they can vote; tracking them by an IP address gets around this, but would allow a user to vote twice by switching to a dierent network; using the browser identier overcomes that problem, but now allows a user to vote twice if they have a second browser; and so on.

Concepts localize data models. A big idea in soware development, from the earliest days of databases, is to start with a data model or domain model that reects the subject maer of the system being built. So if you were building soware for a library, you might model the card catalog, the shelf layouts, the borrowers, and so on.

e rst benet of a domain model is that it provides a single structure and vocabulary that can be shared by all programmers, so you can avoid the common situation in which two programmers develop dierent and conicting models of the same thing. A second benet is that the domain model, by reecting essential and unchanging aspects of the problem, provides a stable foundation for evolution: even as functions are added, the underlying domain doesn't change. Grounding a directions-nding app in a domain model of roads and intersections, for example, might allow you to evolve the app without having to make frequent changes to the model, since the layout paerns for roads have been xed for decades (in the US at least since the 1950s), and only change occasionally and in small respects (for example, with the advent of high occupancy lanes in the 1980s and 1990s).

On the other hand, the domain model may tempt you to include too much data. Should your library model include the kind of paper each book is printed on? e color of the cover? It depends, of course, on what functionality you intend to support. If the library is for book collectors, the kind of paper will be important. And it turns out that most readers recall books by the color of their covers, and the lack of this information in traditional library catalogs leads some librarians to use Google search for nding books (since it allows you to search for images by color).

Basing a design on concepts encourages you to do just the right amount of domain modeling. Each concept contains in its state denition whatever domain model structures are needed for that concept's behavior. It's always clear if the structure has more or less detail than the behavior requires. e domain model as a whole becomes just the composition of the state structures of all the concepts. By separating the model into smaller and clearly motivated structures, the role that each structure plays is evident, and you can grow or shrink the data model depending on which concepts are needed.

More subtly, as we'll see in Chapter 6, concepts also let you factor out dierent aspects of a complex behavior. For example, in a conventional data model of a help forum, you might associate a post both with its content and with the users who have registered interest in it. ese two associations belong to dierent concepts, however: the content association belongs to the post concept itself, but the user association is part of a notification concept.

Concepts are generic. You might have noticed that, in describing the three concepts of Chapter 4, there was a discrepancy between how the concepts were introduced and motivated and how they were dened in the gures. e trash concept was explained as a way to manage les; the style concept was for associating formats with paragraphs; and the reservation concept was for booking tables at a restaurant or books in a library. But in the gures, trash was about deleting and restoring "items"; style for associating "formats" with "elements"; and reservation for booking "resources." ese types—listed aer the name of the concept—are not real types but placeholders (or what computer scientists would call "type variables") for the actual types that will replace them in a real usage.

When we encounter a concept for the rst time, it's always in some specic context, and some concepts (such as style) are easier to understand in concrete terms. (Starting with the concrete and moving to the abstract is a standard pedagogical strategy known as "concreteness fading" [21].)

But almost all concepts are generic, and can be applied to dierent types of objects according to the context. So the trash concept handles deletion of les in the Macintosh Finder but messages in Gmail. e style concept is generic in both the format and element types, so it can be used to apply colors to graphical objects in InDesign, or text formats to paragraphs in Word. As revealed by its type parameters, the reservation concept is generic not only in the resources but also in the users. In a railway network, to prevent trains from occupying the same track segments at the same time, a reservation concept can be applied: in this case, the resources are the segments and the users are the trains.

(In the design of the Macintosh trash, folder structure does actually play a role. But this structure does not aect the essential behavior of the concept; more signicant than the fact that you can delete folders is that the trash itself is represented as a folder. For this reason, I see this not as a violation of the generic nature of the trash concept, but instead as a very skillful synergy of two distinct concepts, trash and folder. See Chapter 6.)

Not all concepts can be generic. Although the style concept is generic, treating elements and their formats as having no specic properties, the elements and for-

mats themselves will be very specic in any particular app, and therefore provided by more concrete concepts. So in a word processor, paragraph and format will be highly specic to word processing. Separating the generic and non-generic concepts also helps make the code cleaner and more exible.

By viewing a concept in its generic form, you can strip away accidental details and grasp its essence more clearly. Sometimes this is easy to do. A user already accustomed to upvoting content on a social media apps will grasp the idea immediately when encountering it elsewhere (for example, in the comments of a newspaper). Sometimes the generalization is harder, but the rewards are greater: once you realize that Apple Keynote, for example, oers styles not only for paragraphs but also for shapes, you see new possibilities for saving work and making your presentations more consistent.

Here's a powerful design exercise. When you're working on a concept, look for respects in which it might fail to be generic, and ask yourself if you can adjust the design to achieve full genericity. Suppose you were looking at the style concept, for example, in the context of a word processor. Your rst reaction might be to think that there's nothing generic about the concept at all, since the dialogs for dening styles contain so many typographic details. en you might realize that these details all belong to a dierent concept, namely format, and that the style dialogs are just dominated by format features. With this insight, you're now motivated to check that style and format are cleanly separated conceptually, even if their user interfaces overlap. Are all the format seings that are available within the style dialogs separately available for direct formaing, and vice versa? And if you can cut-andpaste formats, are all the same format seings available for that too?

In Adobe InDesign, for example, the format seings that can be applied directly to paragraphs are the very same seings available for paragraph styles—even though, disconcertingly, the two have very dierent user interface dialogs (and even when they share a menu, the menu items appear in dierent orders). I have found one non-generic aspect of InDesign's paragraph style concept: its next style feature, which lets you set a default for the style of the next paragraph. is relies on the fact that paragraphs appear in sequence, and introduces a tricky coupling between concepts. To nd the style of a paragraph, the style concept alone is not enough; if the paragraph has no assigned style, you need to check to see if its predecessor has an assigned style.

is is not necessarily bad. e next style feature is certainly useful. But the principle that concepts should be generic whenever possible highlights the price

paid for this benet: a coupling that I suspect introduces some complexity in the code.

Concepts are freestanding. Perhaps the most signicant quality of concepts, and the one that makes them a good basis for soware design, is their mutual independence. Each concept is freestanding, dened by itself without reference to other concepts.

So our style concept, while mentioning elements and their formats, doesn't depend on their properties in any way. e trash concept doesn't depend on any properties of the items being deleted. And the reservation concept doesn't depend on the resources being reserved.

A key tenet of programming is to make the code modules as independent of each other as possible. All the reasons for doing this in code apply equally to concepts. If the concepts are independent, they can be worked on independently; a designer working on one concept can't have their work undone by a mistake or assumption made by a designer working on another. e design work itself becomes easier, because you only need to think about the concept you're working on, and not how it might interact with others. And if concepts are independent, you have the exibility to add and remove concepts, and to create variants of the design containing subsets of the concepts.

Concept independence is essential for incremental design. When you're faced with the design of an entire app, you need some way to get started, to break the design problem into pieces. If you break the design into the wrong pieces, you'll nd that you can't work on them one at a time, because when you adjust one it breaks another, like a game of whack-a-mole. By identifying the concepts, you can approach a design piecemeal, even if you nd yourself revising the overall set of concepts (which is, of course, inevitable).

Sometimes, in working on the design of a concept, you may nd yourself drawn down complicated side alleys. For example, in the design of a restaurant reservation concept, you might want to say that a notication is sent to the customer aer a reservation has been accepted. is risks taking you down a rabbit hole into questions of how you notify the customer, what happens if the notication fails, and so on. A much beer approach is to treat notification as its own concept, and to design it and the reservation concept completely independently of one another. en, with the two concepts in hand, you can ask yourself: which actions in a reservation should produce notications? Not only does this neatly separate concerns, but it also leads to a more exible implementation. (How concepts are joined together in this way is explained in Chapter 6.)

When concepts are composed in an application, dependencies arise in the sense that including one concept in the design may make sense only if another concept is included too. For example, in a social media app, the comment concept may depend on the post concept, because comments only make sense if there is something to comment on. But this form of dependence, which is explained in Chapter 7, does not vitiate the fundamental freestanding nature of concepts and their independence, since the dependencies belong to the context of use (that is, the app) and not to the concepts themselves.

How concepts dier from abstract types and objects. Abstract types (or abstract datatypes, ADTs) are soware modules that provide a collection of objects along with associated functions. Two related but distinct concerns motivated their invention. First was the realization that programming languages came with a collection of built-in datatypes, such as integers and strings, but there was no way to add new datatypes. If your program manipulated vectors, for example, it seemed unreasonable that adding and subtracting vectors should be so dierent from adding and subtracting integers. A second concern was that complex data structures oen became obstacles to change: so many parts of the program depended on the exact form of the data structure that any adjustment to it would ripple across the whole program. e solution in both cases was the idea of the abstract type: a module that provided a collection of values, and operations that could be performed on those values, but which hid the way in which the values were represented.

Abstract types dier from concepts in two key respects. First, abstract types are most potent when they embody collections of immutable values, such as the pixels of a photo editing app or the email addresses of an email client. ese are generally not concepts, because the behaviors that they support are associated with larger structures: pixels are good for image editing, but that requires pixelated images or channels, and email addresses are good for communication, which requires messages.

Second, abstract types—like the objects of object-oriented programming—are a code-level and not a design-level notion. Consider, for example, the concept of comment. is concept would encapsulate the behavior of creating, editing, and deleting comments, and its state would associate comments with their targets (which might be social media posts, or newspaper articles, etc.). In code built with abstract types, we could introduce a comment type with operations for creating and editing comments, but connecting comments to their targets would be hard. e comment values themselves might point to their targets, but this would not allow you to nd the relevant comments given a target. e target type itself, say post,

could contain a reference to the comment datatype, but that would be undesirable since it would introduce a dependence of post on comment, violating the Parnas criterion discussed in Note 81 (namely that if post depends on comment there should be no useful subset that includes post but not comment).

e conventional solution to this dilemma is to build a mapping from targets to comments. From a concept design perspective, this mapping belongs to the comment concept. In a program structured with abstract types, it would probably be implemented as its own type. Some programmers might place such a mapping inside the comment type, but the resulting module would hardly be an abstract type any longer. And even as an object it would violate an o-cited principle of object-oriented programming that objects should not have static components.

How concepts dier from features. A "feature" is an increment of functionality. A family of products may be described by a set of possible features, with each member of the family characterized by those features it possesses. Sometimes the term is used for a large aggregation of functions (as in the "photo cataloging feature" of Adobe Lightroom), but it may also represent something smaller (as in the "automatic page numbering feature" of Microso Word).

One of the best known frameworks for soware development using features is Don Batory's GenVoca [8]. Each feature is viewed as a transformation on the program that augments it by adding new elements; the construction of a system can then be understood as a sequence of transformations starting with an empty program (which might be regarded as the most basic feature!) and ending with the nal version of the program. A product family can be viewed as a set of features, with all the possible programs that can be obtained from them. is framework makes it easy to manage such a family, and can even allow the code for dierent feature combinations to be generated utomatically.

A concept might be viewed as a kind of feature, in the sense that it brings an increment of functionality to an app. But the converse is not the case: not every feature is a concept. Features are rarely freestanding, and, unlike concepts, are not designed to be used in dierent product families and domains. Instead, the features of a family are more akin to a domain-specic language designed expressly for that family. Features therefore do not generally have their own purposes, but rather are characterized by the way in which they extend the functionality of other features, layered one on top of another.

Features, in Batory's sense, unlike concepts, are not primarily user-facing, so a user need not be aware of the feature boundaries. Whether some functionality is added in one or two features, for example, aects only the space of programs that

can be built; for concepts, in contrast, the identity of a single concept in the user's mind is essential. Moreover, one feature can replace or modify the behavior of another feature, whereas concepts always retain their behavior when composed (Chapter 11).

e term "feature" is used somewhat dierently in the context of telecommunications to refer to the variety of services—automatic callback, call forwarding, call waiting, and so on—oered by a system that can be sold as distinct products to customers, and congured for them individually. ese features, unlike Batory's features, are very much user-facing, and are implemented not as code transformations but as separate modules.

A major concern of such features is "feature interaction": the problem that features may behave unexpectedly when combined. e x is usually either to disallow certain combinations, or to introduce modications of behavior (such as precedence rules that favor one feature over another). Glenn Bruns provides a helpful classication of feature interactions that uses a simple formalism to clarify the main distinctions [22]. I'll return to feature interaction when we look at integrity, its analogue for concepts (Note 110).

(anks to Don Batory for help preparing this note.)

How concepts dier from mental concepts. Mental concepts exist in the mind alone. When user interface designers talk about the mental models of users, they raise the issue precisely because these mental models oen dier from the designer's intent. A naive user of a thermostat may have a mental model that suggests that turning the thermostat up or down more will cause faster heating or cooling. And many people, it seems, think that pressing elevator buons multiple times makes them come faster. People use the term "concept" to describe the mental images that these models comprise as distinct from the reality. In this book's usage of the term, however, concepts are very real—and when they are well designed, generate mental images that correspond exactly to the reality.

e relationship between concepts and the eld of conceptual modeling is discussed at length in Note 14.

Chapter 5: Concept Purposes

49. Purposes in design thinking: neednding. In the design of soware, the question of purpose arises before concepts are considered with the larger question of what the entire system or app is for. at question has been extensively explored by researchers in dierent elds under dierent names.

In the eld of design, the term used is "neednding," and generally involves empirical investigations of potential users, which might include interviews, observation, and ethnographic studies. e term was probably coined by Robert McKim in the 1960s, who argued that designers needed to be involved earlier in the process if they were to have more inuence. (McKim, incidentally, became a mentor to David Kelley, a founder of the design company IDEO and Stanford University's d.school, and a leading proponent of design thinking.)

In 1984, Rolf Faste joined the faculty of mechanical engineering at Stanford, took over from McKim as the director of the Design Program, and continued his work in neednding. In an entertaining and insightful paper [39], he outlined the neednding techniques that he taught students in the program, as well as a list of "blocks to perceiving needs" that included a recognition that neednding, while being a critical and creative act, is usually undervalued. In a wry philosophical observation, Faste noted: "e need itself is a perceived lack, something that is missing. Neednding is thus a paradoxical activity—what is sought is a circumstance where something is missing. In order to nd and articulate a need, this missing thing must be seen and recognized by someone."

Purposes in soware engineering: requirements. In the eld of soware development, the term used is "requirements engineering," also the title of a major annual conference. Requirements engineering has placed less emphasis on the experiences of individual users, recognizing that in many systems, the key requirements may be associated with "stakeholders" who are not always users themselves. Indeed, in many such systems, users and operators are best treated as components of the designed system that fulll requirements in collaboration with soware and hardware. e requirements of a trac light system, for example, are to achieve safe and ecient ow of trac, and the individual drivers are relevant only to the extent that the design must account for their behavior in ensuring that the requirements are met.

A coherent theory of soware requirements was developed by Michael Jackson and Pamela Zave in a collaboration in the 1990s that began by focusing on telephone switches (5ESS in particular) but soon expanded to soware systems in general [155]. eir ideas were expanded in Jackson's book, Soware Requirements and Specications [69], and crystallized in a reference model developed with Carl Gunter and Elsa Gunter [49]. e central tenet of this work is that requirements are not merely "high-level specications," and oen cannot be expressed in terms of inputs and outputs of the system being built. In research circles (especially in requirements engineering), these ideas are now widely understood, but in indus-

try a more primitive view of requirements may still obtain. It is not uncommon to hear of systems that have "thousands of requirements," which turn out not to be requirements at all, but rather fragments of interface behavior. us "the system shall terminate immediately when the emergency stop buon is pressed" might purport to be a "requirement," but actually is no more than a partial specication of a system function. Formulated in this way, it fails to address the real requirements issues, such as how pressing the stop buon might impact ongoing processes in physical peripherals.

Another leading thinker in requirements engineering is Axel van Lamsweerde [89], who developed an approach based on goals [87] that can be formulated as temporal logic properties, can be checked systematically against the behavior of agents (which include system components, users, operators, etc.), and can even be used to synthesize soware. An interesting aspect of the goal-driven approach is the identication of "obstacles" [127, 88], which are unanticipated behaviors that prevent goals from being fullled (and which are typically resolved either by changing the agents or by narrowing the goal).

Concept design can benet from almost all the ideas that have been developed around requirements and neednding, with two shis of perspective. First, requirements are not formulated monolithically, but are broken down into the purposes of individual concepts (much as goals are assigned to agents in Lamsweerde's approach). Second, before exploring a purpose, the concept designer looks to see if a concept already exists that might serve it, hoping that the existing concept will embody the accumulated knowledge not only of its design but also its requirements.

• 50. Benecent diculty. Michael Jackson coined the term benecent diculty to capture his insight that design methods that make things too easy are suspect [69]. Encountering diculties can be a positive sign that you are really engaging with the problem and making progress.
• 51. Concept metaphors aren't helpful. One common way to explain concepts is to appeal to metaphors. But these are more oen than not misleading. In explaining the layer concept in Adobe Photoshop, for example, people oen liken layers to the acetate sheets that graphic designers used in the past to build up an image layer by layer. But this metaphor misses the point. Acetate sheets were used for color separations (which in Photoshop are done with channels, not layers), and for animation. e purpose of the Photoshop layer concept is very dierent: it's to allow non-destructive editing. You can create a layer that darkens an image, say, and modify it later, increasing or decreasing the eect, or even throw it away, without ever

modifying the pixels of the image itself (and having to rely on old versions or undo if you made a mistake). Until you understand that, you won't be able to understand layers or use them eectively. (See also Note 40 for why the Apple trash is not like your kitchen trash can.)

is is not to say, by the way, that soware concepts should never be explained in terms of real-world concepts—but that's usually because they're the same concept. e reservation concept in the OpenTable restaurant reservation app isn't like the restaurant reservation concept in which you call on the phone and someone writes your name in a book—it is that concept! e only dierence is the hardware on which the concepts are executed (a computer for one and a notebook for the other).

• 52. Secrets of call forwarding. e analysis of the call forwarding problem is due to Pamela Zave [154], whose work has helped clarify many fundamental questions about the design of communication systems, and which—unusually—combines powerful use of formal methods with deep aention to conceptual issues.
• 53. e mysterious Facebook poke. e lack of a compelling purpose for the poke concept was part of its allure. According to an article in Slate [148] the Facebook help page originally said: "When we created the poke, we thought it would be cool to have a feature without any specic purpose."

According to Urban Dictionary, the poke "allows users to say hello to or show interest in a friend without having to go through the tedious process of craing coherent sentences."

at same Slate article investigated the purpose of the poke by interviewing users to nd out what they did with it. e author was evidently not convinced, and concluded: "By now it's clear that the Age of the Poke is behind us." Facebook seemed to lose condence itself, and buried the poke buon deep in menus.

But then, thrillingly, a few years later (in 2017), the poke buon made a proud return in a prominent position. Now (in 2021), poking has been exiled again, and as far as I can tell, is not reachable through any menu. But it has been resurrected at a special URL with its own page that oers "suggested pokes" and allows you to search for a friend to poke. ank goodness!

54. Norman's refrigerator. A more compelling, but more complicated physical example of concepts without purposes is given by Don Norman [110]. Many refrigerators have two separate controls, one marked "fresh food" and one marked "freezer." e labels give the impression that these controls set the temperatures in the two

compartments, and can be adjusted independently. In fact, one controls the compressor and the other adjusts the ratio of cold air between compartments!

As with the old faucet, there is no alignment between the user's purposes and the concepts that are provided. If you want to make the fresh food compartment colder, you can turn down that seing, but it will aect the temperature of the freezer compartment too. And, like the faucet, a series of adjustments of both controls is needed to converge on the desired state, but in this case it's even worse because the temperatures change slowly, and the adjustments must be made over a period of several days.

Where does the diculty reside? Norman's diagnosis of the refrigerator's design problem is subtly dierent from mine. His primary concern is that the refrigerator does not convey the conceptual model eectively, and so the user's mental model and the actual model are inconsistent. My objection, in contrast, focuses on the conceptual model itself: the design would still be bad even if the controls were accurately labeled.

To Norman, operating the refrigerator is an example of the "surprisingly large number of everyday tasks" for which "the diculty resides entirely in deriving the relationships between the mental intentions and interpretations and the physical actions and states." His language is revealing, and points to his origins as a psychologist: indeed, Norman's book [110] was originally titled e Psychology of Everyday ings and was only later renamed e Design of Everyday ings.e incompatibility he sees is between a physical world (that seems immutable the way he describes it) and the more malleable world of "mental intentions and interpretations," which can be shaped by the user interface.

In my analysis, while the user's diculty may reside in the psychological gulf between mental model and physical mechanism, its resolution resides somewhere else: in the design of the refrigerator's concepts, which are simply not t for purpose. e user's purposes—adjusting the temperatures of the fresh and frozen compartments—exist independently of any mental intention, and it is the fundamental misalignment of purposes and concepts that makes the design bad. is is not to say, of course, that Norman fails to recognize the troubling design of the refrigerator itself, and wouldn't prefer a design with beer concepts, but that his work has focused more on identifying the psychological barriers to usability.

Gulfs of execution and evaluation. An inuential paper [60] by Edwin Hutchins, James Hollan and Donald Norman described the distance between the user's mental model and the actual conceptual model in terms of two "gulfs." e Gulf of Ex-

ecution separates the intentions of the user from the provided actions of the system; and the Gulf of Evaluation reects the eort the user must exert to interpret the state of the system and determine how well the intentions have been met.

Both gulfs are evident in the refrigerator example: the intention to lower the temperature in the fresh food compartment but not the freezer has no directly corresponding action, and the eects of adjustments cannot even be observed until many hours later when the temperatures have stabilized.

e gulfs helpfully identify certain common diculties that users face, and sometimes suggest immediate remedies. Providing an intuitive action that corresponds exactly to the user's intent may eliminate the Gulf of Execution, for example. In pre-graphical operating systems, moving a le between directories meant knowing the syntax of the move command and dealing with absolute and relative paths; in the WIMP (windows-icon-menus-pointer) interface, moving a le between folders became a literal move, with the user dragging the le icon from one window to another.

In other cases, however, an eective design may require teaching the user to perform an action that may seem unintuitive at rst. In some early car radios, to assign a radio station to a preset buon, you had to follow a series of steps. In the beer designed devices, instructions appeared on the LCD display, seemingly shrinking the Gulfs of Execution and Evaluation. But the design was actually terrible, because it was so inconvenient and tedious to modify the presets, and, worse, one was tempted to do it while driving. A much beer solution emerged. To assign the currently playing station to a preset, you simply hold down the desired preset button until it beeps—hardly an action that comes naturally.

In other cases, a beer design might change the set of expected actions. Suppose you want to update the formaing of many of the paragraphs in a document, say changing all the section headers to bold. You could select each paragraph in turn, and apply the new formaing to it. Noting how laborious this is, you might complain that there is no easy way to select all the paragraphs you want rst, and then apply the formaing to them together. In other words, you experience a Gulf of Execution between your mental intention (select an arbitrary collection of paragraphs) and what the application oers (the ability only to select one at a time).

A good solution to this problem, as we've seen in Chapter 4, is not to bridge the gulf for this particular intent, but rather to introduce a concept (style) that fullls the user's purpose, albeit by requiring new behaviors and mental intentions (involving dening styles and pre-assigning them to paragraphs).

In summary, the notion of gulfs is invaluable for exposing usability snags, but in discovering a gulf between a user intention and a system action, one should not regard either the intention or the action as given, and the best design solution may involve changing both.

55. Purposeless concepts in Git. e editor buffer example is nice because it shows a concept lacking a compelling purpose (even if it had a rationale for the implementor). But the price paid for the lack of purpose was merely some needless complexity (and a risk of losing data prior to the buer being saved to le).

A more compelling example is provided by Git, a widely used version control system that is known both for its power and for the complexity of its design. Many of the foundational concepts of Git appear to have no intelligible purpose. Some appear to exist only as workarounds for design aws; stash, for example, compensates for problems with branch.

Others expose the underlying mechanism but don't fulll any signicant purpose, even if they can be put to use in various ways. In particular, the index (also called the staging area) sits between the working area and the repository and almost provides tracking of les, selective commit, and reversion to old le states. But it does none of these things fully or consistently, and is a stumbling block for novices, in large part because none of the introductory materials explain what this concept is for.

It was studying Git, in fact, that led to the realization that purposes were crucial to understanding and designing concepts. My student Santiago Perez De Rosso performed an analysis of Git's design using my emergent theory of concepts, and developed a conceptual redesign called Gitless that eliminates many of Git's usability problems by reshaping the concepts to align more closely with user purposes [118]. When we were trying to understand the index concept, we read many online explanations and were struck by the fact that nobody really knew exactly what it was for. And to the extent that they did, each explanation proposed a dierent purpose, oen incompatible with the others! is led not only to the idea that purposes maer, but also that claiming multiple purposes for a single concept is problematic (as explained in Chapter 9).

Purposeless concepts in programming languages. Examples of purposeless concepts introduced as workarounds can be found also in programming languages. e boxing concept of the Java programming language, for example, makes up for a spurious distinction between primitive values and objects (which had been eliminated in the design of CLU in 1977!).

Likewise the complicated and confusing concept of this object in JavaScript, which introduces a strange form of dynamic scoping at variance with the lexical scoping of all other identiers, was motivated by the desire to support an object-oriented programming style, even though the dynamic scoping that this object introduces has nothing to do with object-oriented programming (and creates new problems of its own).

• 56. How to nd the old "save as" command in the Apple le menu. Many users were unhappy about this change, not because they missed the buer, but because they preferred save as to duplicating and renaming. Responding to complaints, Apple returned "save as" as an optional command (in OS X Mountain Lion), accessed by holding down the option key while opening the menu.
• 57. Stars, hearts and Twier games. Twier explained in an online announcement in 2015: "We are changing our star icon for favorites to a heart and we'll be calling them likes. We want to make Twier easier and more rewarding to use, and we know that at times the star could be confusing, especially to newcomers. You might like a lot of things, but not everything can be your favorite."

is completely failed to address the question of what the concept of favorite was actually for. Twier adjusted the design at the linguistic level (Chapter 2) but the problem was in the conceptual level.

In fact, some expert Twier users had already noted the unclear purpose of the concept, and had found their own purposes. Mahew Ingram explained: "e problem for Twier is that the 'favorite' function had developed a range of uses over time, many of which are known only to the journalists and social-media experts who spend all their time on the service." Ingram went on to say that he used the concept precisely in the way Melania Trump intended, apparently unconcerned about the results being public: "For some (including me), clicking the star icon was a way of saving a tweet for later, or of sending a link that was being shared to a service like Instapaper or Pocket."

Another blogger, Casey Newton, reported a completely dierent purpose that exploited its public nature: "I've favorited more than 60,000 tweets over the years, and in that time I've come to appreciate how versatile that lile buon is. I use it as a kind of read receipt to acknowledge replies; I use it whenever a tweet makes me laugh out loud; I use it when someone criticizes me by name in the hopes that seeing it's one of my 'favorite' tweets will confuse and upset them."

Perhaps most revealing was a comment made by Chris Saca, a Twier board member, explaining the change from a star to a heart: "If Twier integrated a sim-

ple heart gesture into each Tweet, engagement across the entire service would explode. More of us would be geing loving feedback on our posts and that would directly encourage more posting and more frequent visits to Twier."

58. New concepts for image sizing. Here's how I might apply the idea of purposes to the redesign of image size and related concepts for photos. I'd start by identifying the most pressing purpose, which seems to be: downsizing photos to meet quality and space constraints.

en I might start imagining an operational principle. Maybe I'd ask the user what physical size the image is to be displayed at (three inches across for a phone, or three feet across for a gallery wall?), and would show a sample of the image at that size with an indication of whether its quality is sucient, insucient, or even excessive for this size. I'd also show the le size, with an indication of its suitability for dierent uses (sending in email, displaying on a web page, etc.). You'd be able to choose a use, or a particular target le size in megabytes, and the display would be updated to show you the new quality. Once satised with the balance of quality and le size, you would export the image to a le.

is exploration is focused on a single purpose. Other purposes might be valuable to some users too, such as upsampling images (interpolating new pixels so they can be printed at larger sizes) and seing default printing or display size. My contention is that bringing in all these purposes was responsible for the complexity of the Photoshop design, and that limiting the design exploration to just the one basic purpose (of downsizing) would likely lead to a more robust and usable concept, allowing the other purposes to be addressed in an expert mode or in concepts of their own.

Sizes in CSS: a complicated tale. e image size concept might seem obscure, but once you understand the purpose (seing a default size for physical printing and layout), it makes sense. And the operational principle is trivial: if you set the image size of a photo to be 4 × 6 inches, and you then print it (without scaling it or changing the size), the physical size of the photo will be 4 × 6 inches too. It's a nice case of the operational principle being easier to grasp than the purpose.

e size concept in CSS (Cascading Style Sheets, the layout language for web pages) is baing in comparison. e following explanation is taken from an anonymous blog [113].

e concept's complications arise from two very real problems. e rst is one that you may have thought about if you gave a slide presentation and were asked to use fonts "no smaller than 18pt." What on earth does that mean? It's clear what 18

points means on the printed page—it's about a quarter of an inch. at's presumably not the intended size on the screen, and slides themselves don't have physical dimensions. In practice, what it means of course is "choose a type size of 18pt in your slide presentation app," but that just makes the problem someone else's (and may not work if you use a dierent app). is suggests that the meaning of "18pt" should be display-dependent, and correspond to a larger size on a larger display.

e second problem arises with pixel measurements. Obviously "18 pixels" can't literally mean a distance that covers 18 physical pixels in the display, because that would mean that if you bought a new phone with double the screen resolution, the text in your browser would halve in size. On the other hand, pixels can't be converted into inches (say), because you wouldn't want a one pixel border to turn out to have a width that is a non-integral number of pixels (and produce a blurry line).

e CSS standard resolves these issues as follows. It denes a "reference pixel," which is a pixel on a 96 dots per inch monitor positioned at arms length from the viewer (the typical web viewing setup from the 1990s). It recommends that the designer of the "user agent" (the app, such as a browser, that is going to translate the measurements into commands for a physical display) select a size for a one-pixel measurement that corresponds to an integral number of device pixels that will produce the same apparent size as the reference pixel, at the expected viewing distance.

is one-pixel measurement that is set in the user agent is called the "anchor unit" because all the other units of measurements are dened from it. If you're familiar with typographic measures, you'll know that one pica is 12 points, and that there are six picas or 72 points to the inch. What you probably did not know is that the anchoring specied in CSS sets one pixel to be equal to 0.75 points.

e upshot of this complicated story is that measurements in CSS work reasonably well. But the operational principle (which I just explained informally) is tricky, and has some surprising implications. In particular, 12pt text on your screen will not be the same size as 12pt text in a book (and an inch on the screen won't correspond to an inch on a ruler); 12pt text on your phone and monitor will have dierent physical sizes; and a one-pixel border will likely span more than one device pixel.

e practical advice that follows from all of this is straightforward: specify borders in pixels, ignore the display size when you choose your type size, and don't worry about whether you give font sizes in points or pixels (since they're in a xed ratio).

A more important issue in practice is knowing when to use relative sizes (measured in em and rem), but that's a story (or an operational principle) for another day.

• 59. Chip and PIN. e weaknesses of chip-and-PIN were reported in [104].
• 60. Notes on the Synthesis of Form. e idea of mists in this section is drawn from the work of Christopher Alexander, who has been described as the "programmer's favorite architect," mainly due to the inuence of his idea of "design paerns" (see Note 104).

In his book Notes on the Synthesis of Form [3], he explains why the idea of "complete" requirements is nonsensical, and how mists can help: "Such a list of requirements is potentially endless… But if we think of the requirements from a negative point of view, as potential mists, there is a simple way of picking a nite set. is is because it is through mist that the problem originally brings itself to our aention. We take just those relations between form and context which obtrude most strongly, which demand aention most clearly, which seem most likely to go wrong. We cannot do beer than this."

In my own research, I have found Alexander's idea of "t" (and mists) to be very compelling and helpful. It crystallizes a key aspect of what makes design hard, especially when addressing security issues or for safety-critical systems. For both, obscure and rarely encountered mists become central: for security because attackers seek them out and make the rare inevitable, and for safety because rare occurrences cannot be ignored if they are catastrophic.

Alexander's method for discovering structure. Most of Alexander's book is concerned with a systematic method for discovering structure in requirements. First, all the known potential mists are enumerated, and expressed as positive requirements. A graph is then constructed in which two mists are linked if they interact (that is, mitigating one has a positive or negative eect on mitigating the other). Mists are then grouped so that all the mists in one grouping interact, and there are no (or few) interactions across groupings. ese groupings can furthermore be arranged hierarchically by classifying the mists into broad areas. With this structure in hand, the designer can then consider design decisions for each group independently, condent that all the factors relevant to a particular decision are accounted for.

is idea is related to Herb Simon's "nearly decomposable systems" [135]. Alexander never pursued it further, although it inuenced others, notably Larry Constantine, who made coupling a key metric in his work on structured design (1975), and maybe also Don Steward, who invented the design structure matrix (1981). Much later, the idea of identifying couplings between requirements was a central element of Eric Yu's i* framework [152] in which links between requirements are

marked with a plus or minus to show whether meeting one requirement is likely to make it easier or harder to meet another.

It would be interesting to apply Alexander's decomposition method to concept design, and to see if the clusters of requirements that emerge correspond to concepts (or reect needed synchronizations between them).

61. Why verication does not prevent mists. Verication, in which a mathematical proof is constructed to show that the code meets its specication, is no beer at eliminating mists than testing, and may even be worse, because mists correspond to aws in the specication itself.

By broadening the scope of the verication so that the property to be checked is not the specication (that is, the behavior of the system at the interface with the world) but rather the desired outcome in the environment, it does become possible to detect mists—at least those that arise from inadequate consideration of the environment (what Donald Rumsfeld would have classied as "known unknowns"). e outcome relies on assumptions about the environment; simply articulating such assumptions can reveal mists.

e desired outcome of a trac light setup at an intersection, for example, might be that cars do not collide; the assumptions might be that drivers obey the lights and that cars cross the intersection at a certain minimum speed. If the traf c light is being designed for an Amish village, a consideration of the minimum speed assumption might reveal the mist in which the lights change too quickly for horse-drawn carriages.

e structure of such arguments has been a focus of Michael Jackson's work [69, 49, 71] and is central to dependability (or assurance) cases [65, 64].

62. Blaming the user for accidents. A fuller story of the Afghanistan PLUGR accident is described in a contemporaneous article in e Washington Post [97]. At that point, it was the deadliest "friendly re" incident of the war.

As inevitably happens when poor design is the real culprit for a lethal accident, investigators looked elsewhere. An Air Force ocial interviewed for the article said he was unsure whether disciplinary action would be taken, and that he considered the incident "an understandable mistake under the stress of operations." Revealingly, he aributed it to a training problem.

Beer training was probably the right workaround in the short term. But the general tendency to cast blame on operators and exculpate designers and manufacturers prevents real progress. e problem is especially acute in medical devices,

whose poor designs routinely kill large numbers of patients by overdose and other preventable errors [142].

63. Catastrophic concept interactions. e PLGR example illustrates a design aw not in a single concept but in the interaction between concepts. In Chapter 6, I'll explain how concepts are composed and will give many examples of problems that can arise.

e particular case of the battery concept is interesting because its interactions with other concepts are linked to potential failures. Ideally, interactions would be minimized—for example, by using persistent storage so that concepts relying on state are not disrupted when power is lost. At the very least, especially for critical devices, it would be wise to consider, for every concept, how its behavior would be aected by intervening baery replacement events.

Concept composition provides a nice framework for ensuring robustness in the presence of troublesome (but necessary) concepts such as battery, because it allows the analysis to be factored into a collection of pairwise compositions.

Chapter 6: Concept Composition

64. Semantics of composition. In the spirit of Note 44 which introduced a semantics for concepts themselves, here are some notes on how to make precise the composition mechanism described in this chapter.

e concepts of a composition run in parallel, so its traces are just all the possible interleavings of the individual concept traces. e state aer a trace of the composition is just the product of the states of each of the individual concepts. e eect of the synchronizations is to further constrain the possible traces. A synchronization of the form

sync action1 (x)
action2 (e)

adds a constraint that, for every trace of the composition, every occurrence of the trigger action1 is followed immediately by an occurrence of the response action2. e eect of this constraint is to rule out the interleavings in which the rule is not obeyed. (A note for experts: as formulated, this composition rule makes the trace set no longer prex-closed.)

e argument x of the trigger action is like a quantied variable (or function argument): it gets bound to whatever the actual argument of the action instance is, and then constrains the response action to have the argument given by the expression e. In most of the synchronizations I've given, e is simply x, so the synchronization constrains the actions to have the same arguments.

More generally, a synchronization may be predicated on a condition on the argument to the trigger action (and optionally also on the state of one or more concepts). us the synchronization

sync label.detach (t, 'pending')
todo.complete (t)

only triggers when the label being detached has the value 'pending'. e arguments of the response action may be dened not only by the arguments of the trigger action but also by the state. For example,

sync email.receive (todo-user, m)
todo.add (m.content)

sets the argument of the response action to be the content of the email message m that is obtained by looking up m in the content relation of the email concept. (You might have expected the message m to be a composite object with a eld called content, but all state and structure is localized within the relevant concepts—see Object mutability in Note 44.)

e semantics of synchronization is easily extended beyond a single response action to a sequence of multiple actions.

Composition preserves concept behaviors. Suppose we observe an app that is a composition of concepts, looking only at the actions of a particular concept. Since every trace of the composition, by denition, is an interleaving of traces of the individual concepts, the trace we observe must be one of the traces of the original concept. at is, composing concepts never changes the behavior of any of the constituent concepts.

is is an essential property of concept composition. It's what makes concepts comprehensible: a concept behaves the same way, irrespective of context. When concepts are not properly composed, or are adapted to work together in a way that undermines their individual specications, we have a violation of concept integrity, which is discussed in Chapter 11.

ere is one respect in which a legitimate composition may seem to alter the behavior of a concept. You might interpret a concept specication not only to tell you that certain traces are not possible, but rather that certain traces are possible. In computer science terms, you might assume that a concept specication asserts not only safety but also liveness. I have assiduously avoided any such interpretation, because it is important for synchronizations to be able to restrict liveness: just consider an access control concept, for example, whose very purpose is to inhibit actions of other concepts when permission to perform them has not been granted.

You may wonder whether asserting in an operational principle that an action can occur vitiates the guarantee that composition preserves specications. For example, in the trash concept (Figure 4.2), the principle included

after delete(x), can restore(x)

which seems to insist that you can always restore an item aer it has been deleted. As explained above, however (see A logic of operational principles in Note 44), this assertion only requires that the precondition of the restore action hold, in terms of the state of the trash concept. In other words, the operational principle asserts that the trash concept makes the action available, but is consistent with another concept inhibiting it. (Nevertheless, it might be surprising if this happens, and an analysis tool might warn the designer of such cases.)

Generated inputs. Readers familiar with programming languages might have expected the task argument of the add action of the todo concept (Figure 6.2) to have been treated as an output of the action. Adding a task to the todo list involves creating a new task, so it might seem wrong for it to be supplied as an input.

In its most general form, a concept action takes some inputs and the current state of the concept, and produces a new state and an output (or perhaps multiple outputs). e output and the state aerwards are determined by the inputs and the state before. Some inputs come from other concepts. For example, when the action label.affix (i, l) occurs, the item i is assumed to have been created previously by some other concept. But other inputs can be generated by the concept itself. In the label.affix (i, l) action, the label l (unlike the item i) did not necessarily exist previously. You can think of the label as being selected or formed by the label concept, under the direction of the user.

It may help to think about this mechanistically. In an implementation, a concept would include the user interface widgets and code for specifying each input. at input might be a boolean value, dened by a simple checkbox; a short string (for example, one that forms our label input), entered in a text eld; a long string, created with a text-editing plug-in; a date selected with a calendar widget; and so on. Each of these inputs, irrespective of complexity, is created with the concept's assistance.

In the add(t) action of the todo concept, then, the task argument t is such an input. In our rather abstract description, we haven't specied what a task actually looks like. In the simplest case, it's just a string. Either way, it plays the role of an asset (see Object roles in Note 44). A dierent todo concept might separate the name of a task (t1, say) from its content ("file taxes"). In this case, the task exposed in the

add action would be a name rather than an asset, but would still be an input created with the concept.

In summary, there are two kinds of inputs to a concept. Some are generated with the help of the concept itself; others are provided by other concepts (in a composition). To distinguish these, we can mark the generated inputs with a special keyword. So the add action (Figure 6.2) would be declared more fully as

add (gen t: Task)

and likewise the affix action of the label concept (Figure 6.3) becomes

affix (i: Item, gen l: Label)

In the email concept (Figure 6.5), a message and its content are generated by the action that sends it

send (by, for: User, gen m: Message, gen c: Content)

Finally, in the examples of Chapter 4, we would mark the style argument of the action that denes styles in the style concept (Figure 4.4)

define (gen s: Style, f: Format)

and the resource argument of the action that registers a new resource in the reservation concept (Figure 4.7):

provide (gen r: Resource)

Trace constraints on inputs. In dening composition, I said that the traces of the composite were any interleavings of the traces of the individual concepts, so long as they satised the constraints imposed by the synchronizations.

e astute reader might wonder what would forbid a trace starting with the action label.affix (t, l) followed by todo.add (t), in which a label is axed to the task t before the task has been created.

e solution to this dilemma is provided by the notion of generated inputs explained in the preceding note. We add a constraint on every trace that every input to an action must be either generated by that action, or generated or output by an earlier action in the trace. In this case, since t is not generated in label.affix (t, l), and there is no earlier action to produce it, it cannot be used there. If the actions were reversed, the trace would be allowed, because t would have been previously generated in todo.add(t).

Origins of composition semantics in CSP. e idea of a composition that preserves the behavior of the individual components is taken from Tony Hoare's CSP (Communicating Sequential Processes) [58]. e theory of concepts as described here diers from CSP in a few respects. First, because concepts are deterministic, CSP's "refusals" (which model the idea that a process might arbitrarily refuse to participate in an event) are not needed. Second, states are observable in concepts,

and can be used to constrain synchronizations, but play no role in CSP. ird, concept composition is dened as interleaving, with synchronizations constraining the interleavings with trigger/response pairs; in CSP, processes are synchronized on shared actions.

Concept composition might be cast in CSP terms by representing the synchronizations as a process in their own right, which is then combined with the processes representing the concepts proper. For example, a synchronization in which action a1 triggers the reaction a2 might be represented as the process

SYNC = a1 \rightarrow a2 \rightarrow SYNC \mid a2 \rightarrow SYNC

which allows, repeatedly, either a1 followed by a2, or a2 by itself.

65. Bruno Latour's theory of inscription. e philosopher and sociologist Bruno Latour uses the term "displacement" (as well as "translation" and "shiing") for the way in which a machine may enact a task that was previously performed manually. But far from seeing this as just one aspect of the design of machines, Latour sees it as their very essence, with the users and builders of a machine "inscribed" in its mechanism [90].

Latour's understanding of technology is especially apt for concepts, many of which (the restaurant reservation, for example) originate in the world of human protocols and policy and only later become embedded in soware. Human concepts that are implemented in soware are not a metaphor; they are literal "inscriptions" of a social protocol in code. e misleading claim that the Macintosh trash is a metaphor arises, ironically, not from going too far in relating the virtual to the physical, but in not going far enough and recognizing that it is the very same concept at play (see Note 40).

Dijkstra and anthropomorphism. To Dijkstra, talking about computers as if they were human actors was a cardinal sin [35]. He objected to it because it seemed to undermine the abstract, axiomatic view of soware that he preferred, in which code was characterized by its invariants and not by its behaviors. In his defense, invariant-based reasoning was one of the great advances of programming theory, giving programmers a powerful abstraction much like the notion of an orbit in planetary mechanics. But his rejection of operational thinking threw the baby out with the bath water, not only denying us a potent tool for thinking about soware, but perhaps missing the very point of what soware is about. In concept terms, the state of a concept and its invariants are crucial, but the operational principle is closer to the essence.

66. Permission based on prior actions. Another common use of synchronization is to inhibit certain actions in one concept until some actions in another concept have been performed. In the OpenTable restaurant reservation system, you can't post a review (an action of the review concept) unless you were previously seated (an action of the reservation concept).

Such synchronizations oen suggest the addition of actions to a concept, precisely to allow coordination with another concept. Your reservation concept, for example, might not have an action corresponding to a reservation actually being used—in the restaurant case, someone who made a reservation being seated at a table. Even if the action is not strictly necessary to fulll the purpose of the reservation concept itself, it is valuable to other concepts it is likely to be composed with, and therefore worth including (see Figure 4.7). e same rationale applies to including a no-show action (as I mentioned in Chapter 4), which allows the reservation system to punish users who routinely make reservations but fail to turn up.

67. Bridging separated concerns: pages and paragraphs. Here is a richer, more interesting—and more dangerous—example of collaborative composition being used to bridge between concerns that were separated into distinct concepts.

In Adobe InDesign, there is a clean separation between the formaing of pages and the formaing of paragraphs. A master page lets you set the dimensions of the text area, and include common elements such as running headers and page numbers. By creating multiple masters, you can customize the layout of each page. In this book, for example, there is a master for each chapter with its own running header, and another one for chapter openings that have no header or page number. At the same time, paragraph styles let you dene common typographic formats and apply them consistently.

e two concepts, master page and style (explained in detail in Chapter 4) are mostly independent, and this brings clarity and simplicity to the design. eir independence does, however, produce some inconvenience that leads to extra manual work for the user. Whenever I add some text to a chapter in this book, there is a risk that the chapter will spill over onto a new page. If it does so, the last page of the chapter will now be laid out with the chapter-opening master, and the rst page of the next chapter will have the chapter-middle master.

is is not hard to x. You can add a new page in the middle of the chapter; you can also reassign masters to pages. But both of these require manual intervention. My own preference (which many users of InDesign share) is to edit the text of my document externally; InDesign supports linkage to Microso Word for this purpose, as well as to third-party editing tools (although I use a pre-processor that I

wrote for myself that allows me to prepare my text in a text editor). is means that you can edit your text externally, and InDesign will detect that the linked text has changed and reimport it. In this context, having to manually adjust pages is a major annoyance.

Mastermatic is an InDesign add-on that addresses precisely this problem. It lets you specify which masters should be used for which paragraph styles. So, for example, you might say that the chapter-opening master should be applied when the page contains a paragraph styled with the chapter-heading style.

is provides welcome automation, but it does not come without costs. e coupling between the master and style concepts is now rather complicated. What happens if a page includes paragraphs with two dierent styles that are assigned to dierent master pages? In this case, Mastermatic resolves the clash by requiring that the style/master bindings be given in a single list, with an implied priority order. I wonder also what would happen if switching to a master with a smaller text box would cause the paragraph whose style dictated the use of that master to spill o the page. I suspect it's for reasons such as this that Adobe did not include this synchronization in InDesign itself.

68. Subtleties in Gmail's synergistic composition of trash and label. e designers of Gmail understandably wanted to inhibit the display of deleted messages, so they introduced some ad hoc rules that aect which messages are shown in response to label queries. If your query does not mention the deleted label explicitly, it seems to exclude deleted messages from the result; if you mention that label, deleted messages are then no longer suppressed.

is makes sense, although it does violate the integrity principle (Chapter 11) because, strictly speaking, the label concept no longer obeys its specication. Gmail does show a warning saying "Some messages in Trash or Spam match your search" with a link to display them, mitigating this problem, but unfortunately, this warning is not shown consistently when messages have been excluded—perhaps an example of trepanning (Note 89).

69. A synergy trade-o in MIT's Moira app. Representing administrative groups as if they were mailing lists in Moira is a smart design move, but it's not perfect. Two types of users can be added to mailing lists: MIT users, who have MIT accounts (and thus access to the Moira app itself) and are specied by user names, and external users, who do not have MIT accounts, and are identied by full email addresses. You can include external users in an administrative group too, but it has no eect,

because they can't even log in to the system! is illustrates the kind of trade-os that synergy may require.

70. Teabox, synergy and an amusing mist. Teabox is a wonderful company that sells Indian teas directly to customers overseas. eir web app employed the synergistic composition I've described, in which free samples are added to the shopping cart as items with zero cost.

is led to a funny anomaly. One time I was purchasing some of my favorite teas, and I entered a coupon code that Teabox had sent me previously. It did not give the discount that I expected. I eventually gured out what was going on. e coupon concept used a clever rule that didn't just apply a percentage discount, but rather applied it to a maximum of three items in the shopping cart—and not just any three, but the three with the lowest prices. Two of these items, it turned out, were free samples. e remedy was to remove the free samples from the cart, aer which the total cart price dropped precipitously, since two additional and much more expensive items were now being discounted.

is is a nice example of a mist (Chapter 5) in which a concept itself—in this case, the coupon concept—is perfectly plausible, but placed in an unanticipated context has undesirable behaviors.

71. e remarkable synergies of Photoshop. Photoshop presents a fascinating example of synergy in concept design. e way this works is undoubtedly complicated, but very instructive from a design perspective. is note might also help those seeking to understand how to use Photoshop more eectively.

In Adobe Photoshop, the central concept, which we might call pixel array, involves an array of pixels that can be edited by applying adjustments. An image can be viewed not only in this form as a two-dimensional array of colored pixels, but also as three separate arrays, called channels, one for each base color (for example, red, green, and blue).

e channel concept allows you to edit an image in each of these colors separately. For example, you might use the blue channel to select pixels that correspond to the sky, or you might boost the darker pixels in the red channel to counter the tendency of shadows to be too cool. Another common use is to split an image into channels in the "Lab" color space, whose dimensions are lightness (L), red-green (a), and blue-yellow (b), and to apply sharpening to the lightness channel alone (which many people believe produces superior results to applying sharpening to the original color image). When editing a channel, the image appears without any

fig. E.5 e layer and mask concepts in Photoshop. I've created a layer to whiten the apple in the image; its associated mask ensures that the adjustment is applied only to the apple and not its surroundings (note the white spot in the mask corresponding to the apple).

colors, since the entire channel only corresponds to a single color. In short, a channel is a gray-scale image.

Another concept in Photoshop is the selection, which allows you to select a collection of pixels, and then apply adjustments only to those pixels. What is unusual about this concept, and what distinguishes it from other variants of the selection concept (as used, for example, to select a subset of les or email messages for subsequent moving or deletion), is that the selection is not binary: a pixel can be partially selected. When an adjustment is applied, it is aenuated in proportion to the selection: applied in full to the pixels that are fully selected, not applied at all to pixels that are not selected, and applied in part to pixels in between. To make partial selections, the user can apply a brush, with each sweep of the brush increasing the degree of selection (using a feature called "ow"); they also arise naturally when the user denes a selection by drawing a boundary, along with a "feathering" option that produces so edges so that subsequent adjustments blend in. e essential point is that a selection assigns a value between 0% and 100% to each pixel, and this can be treated as a lightness value. In other words, a selection is a grayscale image.

Photoshop's layer concept, which I highlighted in Chapter 3 as the concept that, more than any other, led to the product's success, allows you to apply an adjustment to an image in a non-destructive way. A collection of adjustments can be built as a stack of layers, and each layer can be turned on and o, activating and deactivating its adjustment. You can associate with each layer a mask that determines

which pixels of the underlying image the adjustment is applied to (see Figure E.5). You can probably guess where this is going: the selection can be partial, and the mask is itself… a gray-scale image.

e synergy of these concepts—the fact that channels, masks and selections are all gray-scale images—brings enormous power to the Photoshop user. As an example, suppose you wanted to lighten the skin in a portrait without aecting detail areas such as the eyes, hair, lips, etc. You could open a channel and apply the "nd edges" lter to it; this gives a gray-scale image in which the detail pixels are dark. You can now save this image into the copy buer, and paste it into the mask of a brightness adjustment layer. Don't worry if this seems complicated: it is. But it's what you need to understand to be a Photoshop guru.

Synergistic composition, synchronized states and views. All the compositions I've described can be understood in terms of action synchronizations. For example, the composition of channel and pixel array in Photoshop synchronizes each edit of a channel with a corresponding edit of the associated pixel array, and vice versa.

But in some of these examples, the net eect of the synchronization might be more easily understood as a synchronization of states. us in Photoshop there is an invariant that relates each color pixel to its corresponding gray-scale pixels in the channels; in the RGB case, for example, the lightness value of a pixel in the red channel is exactly the red value of the pixel in the color image.

is suggests an alternative, or additional, form of synchronization, in which concepts are combined by constraints not on their actions but on their states. In this approach, concepts might be identied by projecting the full state of an app into components, and formulating invariants that relate them. In a word processor, for example, the state of a document might be broken into a text component comprising just the characters, and a formaing component that assigns a format to each character independently. More interestingly, a view of the document as a sequence of paragraphs might be separated from a view as a sequence of characters. Inserting a paragraph break adds a new paragraph in the former, but just adds a character in the laer—from an action synchronization perspective, a pinning together of the add-paragraph action in one and the insert-character action in the other.

is kind of synchronization is related to view structuring, an active area of research in the past which sought to nd beer ways to modularize systems as overlapping views of a single state in specications [2, 153] and implementations [109]. In an early paper preguring these ideas about concept composition, I used text editing as an example, showing how breaking the specication into two views linked by an invariant makes it possible to write simple specs for actions such as in-

serting a character and moving the cursor up or down, neither of which could be described easily in one canonical view [61].

• 72. Early design of the trash in Windows. Microso introduced the "Recycle Bin" in Windows 95, but, in contrast to Apple's trash, it was not able to store entire folders, and when a folder was deleted, it was disaggregated into individual les. If, however, the user selected for restoring the entire batch of les that had belonged to a folder, the folder was apparently restored with its contents. (See: hps://en.wikipedia.org/wiki/Trash\_(computing))
• 73. More composition glitches: when emptying doesn't remove trashed items. Here's another example of a problem with the trash/folder synergy in macOS. Recall from our discussion of the unix folder concept (in Note 15) that an item can have more than one parent folder. Since this is the folder concept used in the Macintosh, it means that a le that has been trashed may remain in another folder. Emptying the trash will remove the le from the trash folder itself, but the le will not have been permanently deleted, and its space will not be reclaimable.

is is an example of an integrity violation (Chapter 11), but it's not especially troublesome because it's not possible (in macOS) to put a le in two folders through the graphical user interface—you need to issue a Unix ln command in the console. at said, it is possible that some installed soware might come with les linked in two places, and to get rid of them you'd need to track them down in both.

An unwise synergy in Outlook. Aempts at obtaining synergy can also miss the mark. In Outlook, Microso's email system, when synchronization between the email client and the message server fails, an error message is wrien to a log. To store this log and its messages, the designers of Outlook chose to use the existing structure of email folders and messages.

is might have seemed to be a promising synergy between the log and folder concepts, since it allows the log to be manipulated using the existing tools available for email messages. But the decision created a ra of new problems. Users are surprised to see new mail folders spontaneously appear, and nd themselves confused by the large number of messages generated, and frustrated that they can't remove them. Some users have complained that they get into a situation in which their email client aempts to synchronize these error log folders with the server which fails, of course, because the folders were created as a result of synchronization not working correctly! And system administrators are frustrated because the error logs are generally kept only at the client, so they cannot access them to di-