softwaredesign/raw/book/EssenceOfSoftware_Eng/concepts-061-090/concepts-061-090.md

#### 4: concept structure

such as booking tables at two dierent restaurants on the same night. Airlines have complex rules for detecting conicting reservations, which lead to strange anomalies.47

e *reservation* concept is so useful that it has applications in many dierent domains. In railway signaling, safety is achieved by requiring trains to reserve segments of track before entering them; that way, the system can ensure that no two trains have ever occupy the same segment at the same time. And in networking, there is a protocol called RSVP (Resource Reservation Protocol) that allows routers to reserve bandwidth so they can guarantee a certain level of network performance (called "quality of service") when they need it.

#### *Lessons & Practices*

Some lessons from this chapter:48

- · A concept denition includes its name, purpose, state, actions and operational principle. e operational principle, showing how the behavior fullls the purpose, is the key to understanding a concept, and may not be the simplest scenario.
- · Every concept was invented by someone at some time, for some purpose. Most concepts in widespread use have undergone extensive development and renement over time.
- · Most concepts are generic, and can be applied in many dierent contexts on dierent kinds of data. Genericity aords reuse, and helps distill concepts to their essence.
- · Concepts can be designed and understood independently of one another, simplifying soware design by allowing a design to be broken into distinct subproblems, many of which will be solvable by reusing existing concepts.

And some practices you can apply now:

- · To design or analyze a soware product, start by identifying the concepts. For each concept, choose a good name, nd a pithy summary of the purpose, and formulate an operational principle. To delve more deeply, list the actions, and gure out what state is needed to support them.
- · If your concept lacks interesting behavior—you can't come up with a compelling operational principle, or can't even list actions—it may not be a concept at all, or you may need to expand it to identify the real concept.

- · Take a database schema or class structure for a system, represent it as an entity-relation diagram, and then break it into smaller diagrams (overlapping on the entities but not the relations), each of which embodies some piece of functionality. ese smaller diagrams are the states of distinct concepts.
- · Conversely, to design a data model, rather than treating it as a monolith, develop local "micromodels" for each of your concepts independently, and then merge them on the common entities to form the global model.
- · As a fun and rewarding exercise, pick an interesting concept and research its history. It might be a concept (like *reservation*) that exists independently of soware, or it might be a concept in your favorite app. When was it invented and by whom? How has it changed over time?

# Concept Purposes

 Purposes maer in all aspects of life because they help us set direction, explain ourselves to others, and reach consensus in collaborations. Design is no different from any other activity in this respect: you can't design something well without knowing *why* you want it in the rst place.49

For concepts, purposes are essential too. For a designer, the purpose is what justies the eort of designing and implementing the concept. For a user, it tells you why you might want it—and if you don't know what something is *for*, it's hard to understand *how* you would use it.

Before you dismiss this as obvious, consider that the designers of soware rarely articulate purposes beyond those of the product as a whole. I'm proposing a more radical idea here. It's not enough to know why you're designing a product. You need to have a *why* for each element of your design, a purpose for every concept.

Finding purposes for concepts is hard work, but it's amply rewarded in the insights it gives you about the problem you're trying to solve, and in forcing you to focus on what maers.50 In this chapter, we'll see how subtle it can be to gure out the purpose of a concept, and how failing to formulate or convey a straightforward purpose can have nasty consequences. In soware especially, with its capacity for boundless complexity, it's easy to get mired in details and lose track of the big picture. inking about purposes helps you draw back and regain your bearings.

Once you have a purpose, you can ask whether your concept fullls it. As we'll see, that's not always straightforward, because a purpose isn't a simple description of an expected behavior. It's an articulation of a need, and that need can vary depending on the user and the context of use. *Mists*, in which forms fail to t their context—or in our case, concepts fail to fulll their purposes are oen unpredictable, because neither needs nor contexts of use can be fully anticipated at design time, let alone reduced to precise logical statements.

Concepts don't eliminate this problem; their value is that they give you a framework that mitigates it, by elevating the role of purposes, and by providing a structure for organizing the knowledge accumulated through experience of design and use. In this chapter, I'll show some of the benets of thinking in terms of purposes; later, in Chapter 9, I'll revisit the relationship between purposes and concepts and rene some of these ideas.

### *Purposes: First Step to Clarity*

To be easy to use, a concept must have a clear purpose. And the purpose can't be the designer's secret; it must be shared with the user.

When I upgraded to the most recent version of Apple Mail, I noticed a new VIP buon, and looked it up. Here's what Apple's help guide said:

*You can easily keep track of email messages om people important to you by making them VIPs. Any messages in the Inbox om a VIP (even sent as part of a conversation) are displayed in a VIP mailbox…*

In just two sentences, they've given me the purpose of the *vip* concept (tracking emails from people important to me), and most of the concept's operational principle (it seems I can make someone a VIP, and then, subsequently, messages from them will appear in a special mailbox).

In contrast, I wanted to understand what a section is in Google Docs, so I looked up the word "section" in the online help. e rst disconcerting thing was that no article about the *section* concept appears. e closest was an article entitled "Work with links, bookmarks, section breaks, or page breaks." I scrolled through that article and found this:

*If you want to break up ideas or set images apart om text in your document, you can add section or page breaks in Google Docs.*

at's it, as far as explaining the purpose goes. I might have guessed that sections could be used to break up ideas, so that doesn't help me. e reference to images made me a bit nervous, because it seemed to be suggesting that I couldn't have images that are "apart" from my text without having sections. In short, it le me no wiser about what sections are for.

It turns out that the purpose of *section* is to allow dierent parts of your document to have dierent margins, headers and footers, and to have subsequences of pages with their own page numberings. You *can* have images separate from

text without using any sections; what sections let you do is change the margins of an image independently of the margins of the text around it.

### *Criteria for Purposes*

Dening compelling purposes for concepts is hard. Because purposes are about human needs in a human context, they cannot be assessed in a logical or mathematical way, but must always be informal and rough-edged. Nevertheless, here are some criteria that can help:

*Cogent*. A purpose must be a cogent expression of an intelligible need, and not just a vague hint about some desires the user might have or tasks she may want to perform. e phrases used in the explanation of the purpose of the Google Docs *section* concept—"break up ideas" and "set images apart from text"—give us only a hazy idea of what the user is trying to do. In contrast, "allowing dierent margins on dierent pages" is prey clear.

*Need-focused*. A purpose must express a need of the user, and not just recapitulate a behavior whose signicance is unclear. Take the *bookmark* concept that browsers oer. It's not helpful to say that the purpose of a bookmark is to "mark a page" or to "save a favorite page": these just beg the question of why you would want to do such things. Instead, the purpose might be to "make it easier to revisit a page later," or perhaps to "share a page with another user." Don't worry if a purpose isn't precise initially; if your formulation immediately raises questions (may "revisiting later" be on a dierent device?), that's a good sign of progress!

*Specic*. A purpose must be suciently specic to be relevant to the design of the concept at hand. You could say that any concept's purpose is to "make the user happy" or "let the user work more eectively," and such expressions are indeed cogent (since we know exactly what they mean) and need-focused. But clearly such purposes would not be a helpful basis for a concept design because they are not specic enough to distinguish one concept from another.

*Evaluable*. A purpose should provide a yardstick to measure a concept against. You should be able to take the operational principle and easily assess whether it fullls the purpose. For the *trash* concept, the purpose "allow undoing of deletion" is clearly supported by the scenario in which a le is deleted and then restored from the trash. In contrast, the purpose "prevent accidental

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_5_Picture_1.jpeg)

fig. 5.1 *Call forwarding: a design puzzle (top) and two solutions (below). If A is forwarded to B, and B is forwarded to C, does a call to A get forwarded to B or to C?* 

removal of les" would not be very helpful, because we'd need additional information about user behavior, notably whether users might not only delete les accidentally but also empty the trash accidentally.

## *Purposes Resolve Design Puzzles*

Sometimes, a design you're working on presents multiple options that seem equally plausible, and there seems to be no rational basis for selecting one over another. In many cases, this dilemma is a result of not understanding the purpose deeply. Once the purpose is understood, it becomes clear which option is the right one.

Take *call forwarding*, a telephony concept that allows calls to one line to be automatically transferred to another. Suppose we have three users with phone lines *A*, *B* and *C* (Figure 5.1). Now imagine that our rst user forwards her line to *B*, so that calls to *A* are now redirected to *B*. What if the second user now forwards to *C*, so that calls to *B* go to *C*? If a call comes in to *A*, should it be forwarded to *B* (based on the rst user's forwarding request), or should it be forwarded to *C* (based on the requests of both users)?

e solution to this dilemma is to recognize two distinct purposes for call forwarding. One, which might be called *delegate*, is to allow a person to delegate their calls to somebody else. In this case, if the owner of *A* has delegated to *B* and *B* has delegated to *C*, then clearly a call to *A* should be forwarded two steps

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_6_Picture_1.jpeg)

fig. 5.2 *A physical analogy: do faucet controls have purposes?* 

to *C*. e other, *follow me*, is to allow a person to transfer calls when they are working in a dierent location. In this case, if the owner of *A* has moved to the location of *B*, and the owner of *B* is now in the location of *C*, a call to *A* should clearly be forwarded only to *B*. 52

Articulating these two distinct purposes reveals that there are two distinct concepts, *delegate forwarding* and *follow-me forwarding*, each serving its own purpose. eir behaviors may dier in other respects too. e *delegate forwarding* concept, for example, might support an option in which the call rings rst at *A* and is only transferred to *B* if unanswered.

### *Concepts without Purposes: Faucets & Editor Buers*

A concept may have no compelling purpose at all. is casts some doubt on its utility, but people can nd value even in dubious concepts. e *poke* concept was one of Facebook's earliest, and nobody ever really knew what it was for.53

Concepts more commonly lack purposes because their design was motivated not by a genuine user need, but because it was easier to build it that way. A physical analogy illustrates the point. Compare two kinds of common mixer faucets (Figure 5.2). In both kinds, there is a single outlet pipe that mixes the hot and cold water.

In the older kind (on the le), this pipe is fed by two separate faucets, marked "hot" and "cold." Viewed as concepts, these two faucets have no compelling purposes. It's clear what they *do*; opening the hot faucet increases the amount of hot water mixed in. But the user wants to set the temperature and ow of the water emerging from the pipe, and the controls have no simple relationship to those needs. If you want to increase the temperature, you can open up the hot

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_7_Picture_1.jpeg)

| New             | ₩N          |
|-----------------|-------------|
| Open            | <b>%</b> O  |
| Open Recent     | <b>&gt;</b> |
| Close           | ₩W          |
| Save            | ₩S          |
| Duplicate       | 企器S         |
| Rename          |             |
| Move To         |             |
| Revert To       | <b>&gt;</b> |
| Export as PDF   |             |
| Share           | •           |
| Show Properties | <b>7</b> ₩P |
| Page Setup      | ΰ₩Ρ         |
| Print           | ₩P          |
|                 |             |

fig. 5.3 *Apple le menu: the "save as" action in the old menu (le) reected the buer concept, no longer present in the new menu (right).* 

faucet, but then the ow will increase, and you'll need to close the cold faucet. Likewise, if you just want to increase the ow, you need to open up both faucets, adjusting them carefully to reestablish the desired temperature. In both cases, a series of multiple adjustments is generally needed.

In the newer design (on the right), there is a single faucet that has two independent controls: rotating it adjusts the *temperature* and moving it up and down adjusts the *ow*. ese controls thus have clear purposes that match the user's needs.<sup>54</sup>

Moving to a soware example, the familiar concept of the *editor buffer* once fullled a need, but it's no longer a compelling one. At one time, disks were slow and the only way to make a fast text editor was to have the user edit text in a buer in memory, periodically saving the buer to a le. But this buer had no apparent purpose to the user, and indeed it was confusing to non-technical users that the text in the buer was vulnerable to being lost if the application crashed, or were closed before saving to le.

Presumably this is why Apple changed the behavior of all its applications (in OS X Lion, 2011) so that changes are wrien to disk from the start, and "saving" to a le just entails naming the le. In other words, the purposeless *editor buffer* concept was eliminated.55 With buers gone, the *save-as* action (in which the contents of the buer were saved to a new le of a given name) no longer made sense; users were now expected to duplicate the le and rename it (Figure 5.3).56

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_8_Picture_1.jpeg)

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_8_Picture_2.jpeg)

fig. 5.4 *An unaering tweet unintentionally endorsed due to a misunderstanding over the purpose of Twier's favorite concept.* 

In all of these examples, the purposeless concepts are the result of an underlying mechanism being exposed to the user. ere's nothing wrong with a text editor being implemented with a buer. On the contrary, by applying edits rst to a buer kept in memory, and writing them out to a le on disk in the background, the editor may be able to oer much beer performance. What's wrong is burdening the user with these complications.

In short, concepts, unlike internal mechanisms, are always user-facing, and must have purposes that make sense not only to the programmer but also to the user.

# *Concepts with Unclear Purposes: Twier's Favorites*

If the purpose of a concept is unclear to the user, it will likely be used in a way that the designer did not intend. Twier's *favorite* concept oers a compelling example of this problem.

In May 2017, Andy Ostroy, a political analyst who writes for *HuPost*, joked about the president's relationship with this wife in a tweet (Figure 5.4). She responded by clicking on the tweet's heart icon, apparently (and presumably unintentionally) signaling to the Twier public that she liked the tweet. Needless to say, when she realized what had happened, she retracted her endorsement.

At issue here is Twier's *favorite* concept. Twier had in fact changed the visual design of the concept in 2015, replacing a star icon by a heart.57 Apparently

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_9_Picture_1.jpeg)

fig. 5.5 *Twier's response to problems with the "favorite" concept: a new "bookmark" concept, accessible through the share menu (on the right), and the original concept, renamed "like," still represented by a heart icon (on the le).* 

they thought this would resolve users' confusions about the concept, but it evidently didn't help this particular user. e real problem was a confusion about the very purpose of *favorite*.

Many users, it seems, thought that *favorite* oered a way to save tweets for your own reference. is was a reasonable assumption given that the term "favorite" is usually applied to a concept that has exactly this purpose. It turned out, however, that the actual purpose of *favorite* was to record your approval of a tweet for others to see—which is the purpose of the concept more commonly called *like* or *upvote*.

Twier solved the problem in 2018 by renaming the *favorite* concept, calling it *like*, a name appropriately aligned with its purpose (Figure 5.5). To address the other purpose of allowing users to mark tweets to be saved for (private) future reference, they introduced a new concept called *bookmark*, which is accessed (confusingly) through a tweet's "share" icon (presumably on the grounds that bookmarking a tweet is sharing it with yourself?).

# *Exploiting Confusing Concepts: e Nanny Scam*

A concept whose purpose is misunderstood is likely to be misused. e concept of *available funds* was well intentioned, but has made a rich target for scammers. When a check is deposited, some portion of the value of the check appears in the depositor's account and is immediately available for withdrawal.

In the US, this was mandated by an Act of Congress passed in 1987 designed to prevent banks from delaying the processing of deposits.

Unfortunately, many people confuse this concept with the concept of a *cleared check*, and seeing the increase in balance, believe that the check has been irrevocably validated. Criminals ruthlessly exploit this confusion. In one version known as the "nanny scam," a newly hired home help expecting an initial payment for moving expenses (of say \$1,000) receives a check for a much larger amount (say \$5,000) and deposits it. e employer then sends a message asking for the excess to be wired back. Aer the money has been sent back using the available funds, the check bounces. e deposit is retracted, eectively withdrawing the previously available funds, leaving the poor employee \$4,000 in the red.

# *Can is Concept Really Be So Hard? e Story of Image Size*

Sometimes a single concept with an unclear purpose can produce ripples of confusion. Take the concept of *image size* and the associated idea of "resolution." Even organizations that sponsor photographic contests—which you'd assume would understand these things—sometimes get this wrong, and stipulate that images must have a minimal resolution.

e problem is that the resolution of an image tells you nothing about its quality unless you also know its size. A resolution of 360 pixels per inch might seem impressive, but if the image is only the size of a postage stamp, that's not enough to get a sharp postcard-sized print.

To grasp this, you need to understand two concepts. e rst is a concept I'll call *pixel array*, the ubiquitous (but once radical) idea that a picture can be represented as a two-dimensional array of colored pixels. Its purpose is image editing, and its actions include adjustments (say to contrast or lightness), which change the values of pixels, and resampling (a much more complicated action), which changes the *number* of pixels, usually to reduce the quality (by replacing several pixels with one) or to increase the quality (by interpolating additional pixels to make the image print beer at larger sizes).

e second concept you need to understand is *image size*. Its purpose, which is to allow a physical size to be associated with the image, is straightforward but also strange, since we don't tend to think of digital images as having physical sizes. e image size determines the default size of the image when printed, and

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_11_Figure_1.jpeg)

fig. 5.6 *Image size dialog in Photoshop. If you check the resample box (top le), and change the resolution om 300 to 600, the pixel dimensions double (boom le). If you change the resolution with the resample box unchecked (top right), the pixel dimensions stay the same but the width and height are halved (boom right).* 

its size on the page when imported into a desktop publishing app such as Adobe InDesign. In all these applications, however, the image can usually be manually scaled, so this makes *image size* a concept with a tenuous purpose.

Finally, image resolution is not a concept in its own right, but rather is a measure of printing quality assuming the image is printed at its given image size. So if the *pixel array* is 1,000 pixels square, and the *image size* is 10 inches square, the resolution is 100 pixels/inch.

If you're not already confused by this, take a look at the dialog in Photoshop (Figure 5.6) for modifying image size, dimensions and resolutions. At the top le, you can see the various parameters and conrm their relationships: at a width of 20 inches and 6000 pixels, the resolution is 300 pixels per inch. e symbol of a lock and vertical bars indicate which parameters are mutually constrained. When *Resample* is selected (the default, on the le), doubling the resolution doubles the pixel dimensions; when not selected (right), it halves the image width and height instead.

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_12_Figure_1.jpeg)

fig. 5.7 *e tagging concept in Facebook: no mention of why you should do this.* 

Even for experts, these controls are complicated and error prone. e concept of *image size* with its questionable purpose seems to be the source of all this complexity.58

### *Whose Purpose? Mine or Yours?*

If you're trying to understand the purpose of a concept, a good question to start with is: *whose* purpose exactly is being served?

In social media apps, many concepts purport to be for the user's benet, but in reality are designed to raise the company's prots, by expanding the social graph, increasing usage, or by selling more advertisements.

e *notification* concept, for example, purports to provide users with timely updates to keep them informed. But its purpose is oen instead to increase "user engagement." A clear tip-o, in Facebook's case, is that while a panoply of options is available to control which events produce notications, there is currently no option to turn notications o completely.

e concept of *tag* likewise may seem to serve a straightforward purpose: making it easier to nd posts that are about particular people. Note that when Facebook prompts you to tag someone in a photo, tellingly neither the purpose nor consequences of tagging are explained (Figure 5.7). Again, there is a hint to the real purpose if you are aentive. By default, tagging a post makes it visible not only to the friends of the person doing the tagging (as you'd reasonably

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_13_Figure_1.jpeg)

fig. 5.8 *Quora's disingenuous explanation for why reading posts requires sign-in.* 

expect) but also to all the friends of the person tagged. is neatly encourages links between two groups of friends, adding connections in the social graph.

e "Chip and PIN" security mechanism for credit cards involves two concepts with apparently distinct purposes. e *chip* concept seems designed to reduce fraud from fake cards (since it's harder to make a card with a chip inside than a card with a magnetic strip); and the *pin* concept is presumably for reducing fraud from stolen cards (since a thief will not know the PIN).

It turns out, however, that the underlying protocol is trivially broken and is susceptible to a man-in-the-middle aack. e reluctance of banks to x (or even admit to) such problems suggests that the purpose of the *chip* concept may never have been to eliminate fraud, but rather—by giving a misleading impression that their systems are secure—to shi the blame for any fraud to consumers and retailers, and thus reduce costs to the banks themselves.59

# *Deceitful Purposes*

Sometimes designers actively misrepresent the purpose of a concept, hiding a more insidious purpose:

· All question-and-answer sites have a concept of *user*, whose purpose is presumably to deter spam and low-quality answers. But many limit access so that it isn't even possible to view existing questions and answers, let alone post new ones, without rst logging in. In explaining this, Quora (Figure 5.8) says: "Why do I need to sign in? Quora is a knowledge-sharing community that depends on everyone being able to pitch in when they know something." is dissembling hides purposes that are less likely to appeal to the user, such as collecting data about them, creating a more sticky experience, or pitching more focused advertisements.

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_14_Figure_1.jpeg)

fig. 5.9 *A ight reservation app showing non-stop and direct options: note the parenthetic explanation of the direct ight concept next to the checkbox at the boom le.* 

- · A *push poll* presents itself as if it were a standard poll, whose purpose is to derive some useful information by aggregating responses. But instead its purpose is to win you over, usually for political gain, by asking you suggestive questions that are craed to shi your viewpoint.
- · e concept of *direct flight* was invented by airlines in response to early reservation systems that favored routes with a single ight number. By maintaining the same ight number across segments, "direct ights" allowed airlines to make those trips more prominent and thus more likely to be purchased. But the poor consumer misunderstanding this purpose may not realize that a direct ight is not necessarily non-stop. Nowadays, most ight aggregation sites have dropped this confusing concept, and those that use it at least add an explanation for unwary customers (Figure 5.9) and promise no change of plane, which the original concept did not guarantee.

# *Mists: When Purposes Aren't Fullled*

e essence of design is the challenge of creating a *form* for a given *context*. e desired outcome is a perfect "t" between form and context, in the way that a piece in a toddler's wooden puzzle board ts snugly into its hole.60

Following this analogy, the purposes of soware design describe the shape of the hole. e problem is that this shape is complex and not fully known, so it cannot be described fully or accurately. Ultimately, the only way to learn about

the shape of the hole is to design a puzzle piece, aempt to insert it, and discover the *mists*: the ways in which the piece doesn't quite t.

Because the exact shape of the hole is unknowable, testing is essential. It is simply not possible to predict the eectiveness of a design in full until you try it in the real world. But at the same time, because of the complexity of the shape—and the fact that any given test only reveals some aspects of it—testing cannot be a panacea.61

You can never fully predict all the potential mists of a design, but you can at least build on your experience of nding mists in the past. So while a full enumeration of requirements is impossible, an enumeration of negative requirements—mists to avoid—is feasible.

Concepts mitigate the risk of mist in two ways. First, by breaking a design into concepts, the challenge of achieving t for the design as a whole is reduced to a set of more manageable subproblems.

Second, concepts embody needs that occur repeatedly, and provide commonality across contexts. e mists that are learned in one context for a concept usually apply in another. For example, a mist of the *reservation* concept is that someone might hog multiple slots and not intend to use them all. If you're building a system that includes reservations, it helps to be reminded of this potential snag at design time, and to consider the various features that are typically used to mitigate it, such as penalizing no shows and preventing overlapping reservations (for example, of tables at dierent restaurants on the same night).

In the next few sections, we'll study some informative mists. I've selected examples that illustrate the variety of mists that can arise, and that suggest different strategies for preventing them.

# *A Lethal Mist due to Poor Design*

In December 2001, an American soldier in Afghanistan called in an air strike on a Taliban outpost, using a device called a PLGR (Precision Lightweight GPS Receiver, pronounced "plugger") to generate the coordinates of the target. While he was aempting to perform the calculation, the device's baeries died, so he replaced them. What he restarted the device, it seemed that the calculated coordinates were still available.

What he hadn't realized was that the device was designed to default to its own GPS location on restart. Consequently, the hapless user called in a strike

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_16_Picture_1.jpeg)

fig. 5.10 *A GPS receiver (le) similar to the one that caused the accident in Afghanistan in which the operator unwiingly set the target of a bombing run to his own position, and the warning messages (right) that are now displayed.* 

on his own position, and a 2,000-pound, satellite-guided bomb landed not on the Taliban outpost but on an American position, killing three soldiers and injuring 20 others.62

In this case, the mist might have been predicted had the device designers considered the interactions between the *battery* concept and the *target* concept.<sup>63</sup> Any number of straightforward modications to the design might have averted disaster; the one chosen and implemented in later versions of the device was to display a warning message in this scenario. (e replacement device, known as the "DAGR," is shown with the new warning messages in Figure 5.10.)

# *A Mist om a Changing Context*

With the advent of the pandemic, people began to give all their slide presentations online through communication apps such as Zoom, Google Hangouts and Microso Teams. An annoying mist appeared. When you played your presentation, the slide presentation app would switch to full screen mode. e panels of the communication app either disappeared—leaving you disconcertingly giving a talk without knowing if you still had an audience—or obscured the slides, making it hard for you to see what you were showing.

Apple's elegant solution to this mist was to augment the *slideshow* concept in Keynote, its slide presentation app, with a "play in window" mode, in which the slides appear in a regular window that no longer occupies the entire screen.

|   | A                    | В      |
|---|----------------------|--------|
| 1 | Item                 | Cost   |
| 2 | Apples               | \$3.00 |
| 3 | Bananas              | \$1.50 |
| 4 | Milk                 | \$2.00 |
| 5 |                      |        |
| 6 | Total billable hours | \$6.50 |
| ⊜ |                      |        |

fig. 5.11 *Dening a range in Apple Numbers: range highlighted (le) and formula (right).* 

is example shows how mists arise when the context of use evolves. A similar mist arose in the problem I mentioned earlier (in Chapter 4) in Apple's *trash* concept—being unable to recover space on a USB key without permanently removing all the les deleted from the main drive of your computer. When the trash was designed forty years ago, personal computers did not have external drives (let alone tiny thumb drives).

# *An Old Mist Returns*

In a spreadsheet, a formula that computes its result from a contiguous series of cells can be expressed using the *range* concept. Instead of dening a sum of three cells as *B1 + B2 + B3*, for example, you can write something like *SUM(B1:B3)* (Figure 5.11).

e purpose of *range* is not to save typing when you enter the formula, or to make the formula more succinct when viewed—both of which could be achieved (at the linguistic level) without introducing a new concept. Rather, it's to allow the formula to accommodate the addition and deletion of cells in the series. If you add a row between rows 1 and 2, in order to include a new cell in the series, the explicit version of the formula would have to be changed manually to read *B1 + B2 + B3 + B4*, but the range formula would adjust automatically to *SUM(B1:B4)*. e operational principle of *range* may thus be stated as:

*If you create a formula that depends on a range, and then update the spreadsheet by adding a row or a column within the range, the formula is automatically adjusted to include the new row or column.*

e catch is how "within the range" is dened. You might think of the range as bounded by two markers, one before the rst cell in the range, and one aer the last cell. An addition "within" the range, therefore, could include adding a row

<span id="page-18-0"></span>

|                      | Task                | Time (hours) |
|----------------------|---------------------|--------------|
| Jan 1, 2018          | Interviewing client | 4            |
| Jan 3, 2018          | Making slides       | 5            |
| Jan 7, 2018          | Writing report      | 3.5          |
|                      |                     |              |
| Total billable hours |                     | 12.5         |

fig. 5.12 *A workaround for the range problem: by adding a dummy row, you can add new rows to the end of the range by inserting them above the dummy row.* 

below the last row in the range (between that last row and the marker) and or adding a row above the rst row.

Apple's spreadsheet app, Numbers, oers two separate actions for adding rows in general, one for below the current row and one for above (and correspondingly for adding columns). ese actions are bound to keyboard shortcuts, so extending a range should be quick and easy.

Selecting the last row of a range and adding a row *below* it should include the new row in the range, but selecting the row one below the range and adding a row *above* it should exclude the new row from the range. is might sound complicated, but it's actually very intuitive: if your selection is on one of the rows in the range, then whatever action you perform, whether adding a row above or below, the new row should be in the range. But if you start outside the range, the new row should also be outside.

is in fact was exactly how Numbers *used* to behave (in the 2009 version). e current version treats the rst and last row of the range dierently. If you add a row above the rst row or below the last row, it will not be in the range, irrespective of which row was selected and which row addition action (add above or add below) you performed.

is mist is a major annoyance in practice. I have a spreadsheet in which I track my billing for consulting projects (Figure 5.12). Each row of the sheet corresponds to a billable period of work, with a summary row that gives the total amount of time spent. Every time I complete a piece of work, I add a row to the sheet. In the old Numbers, I would just select the row representing the last period that I completed, issue the *add row below* command, and complete the elds in the new row.

In the new Numbers, this no longer works. I can add the new row just before the last in the range, and then drag the last row up, placing it before the new row. Or I can add a spurious, empty row aer the last entry, and include it in the formula (see the shaded region denoting the formula's scope i[n Figure 5.12\)](#page-18-0). is happens to work, but only because the formula that sums the time periods happens to treat the empty cell in the dummy row as a zero. Microso Excel, incidentally, has exactly the same aw (and lacks separate actions for adding rows above or below the current row).

e mystery of this mist is not so much why Apple got it wrong, or even what it might have done to catch it (a careful consideration of the operational principle might have revealed it). More surprising is that Apple's designers knew the right design, and then apparently forgot about it. Perhaps if Apple's designers had recorded their insights in a concept catalog their best ideas would have more readily survived the transition from version to version.

### *Lessons & Practices*

Some lessons from this chapter:

- · Concept design begins by asking, for each proposed concept, the simple question: what is it for? Answering it can be hard, but pays dividends.
- · For users, knowing a concept's purpose is a prerequisite to using it. Many manuals and help facilities explain details of behavior but not purposes, with unhappy consequences especially for novices.
- · A concept's purpose should be cogent, need-focused, specic and evaluable. Metaphors are rarely useful for explaining what concepts are for.
- · A concept without a purpose is suspect. When this happens, it's usually because the concept isn't really a concept at all, but a vestige of an internal mechanism that should not have been exposed to users.
- · Confusion about the purposes of concepts leads to misuse, and can be exploited to trick users into engaging in behaviors they will regret.
- · e mists that prevent a concept from fullling its purpose are not easily anticipated, because the context of use evolves over time. Concepts help by giving a structure for recording experience.

And some practices you can apply now:

· If you're having trouble using a concept, rst look for evidence that you may have misunderstood the concept's purpose.

- · When you're explaining a concept to someone, whatever the context, start with the purpose.
- · When you propose to add a concept to a product you're working on, rst formulate a compelling purpose and check that it resonates with your users.
- · When your team starts work on a concept, before you even make any user interface sketches, write down a terse concept description, and make sure all the designers and engineers are aligned around the purpose and operational principle.

| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
|----------------------------------------------------------------|--|--|
|                                                                |  |  |
|                                                                |  |  |
|                                                                |  |  |
|                                                                |  |  |
|                                                                |  |  |
|                                                                |  |  |

# Concept Composition

 Until now, we've talked in detail only about concepts individually. But even the simplest app involves more than one concept, so we need to understand how concepts t together.

In this chapter, we'll see how to combine concepts using a new kind of composition in which the actions of dierent concepts are tied to one another, so that when an action of one concept occurs, the associated action of another concept occurs too.

More exciting than this rather simple mechanism is what you can do with it. I'll show you a variety of compositions, starting with a trivial kind in which the concepts run largely in parallel, fullling their individual purposes without much interaction; then a richer kind in which the concepts are more connected and produce new functionality; and nally, the richest, in which a synergy is achieved that oers a simpler and more unied user experience than the concepts would have oered by themselves.

When you design with concepts, you can choose to synchronize them more or less tightly with each other. Tighter synchronization means more automation but also less exibility. I'll illustrate the pitfalls of geing this wrong with some examples of both over- and under-synchronization.

# *Why Traditional Composition Won't Work*

Soware components are usually assembled in a client-and-service arrangement, in which one component plays the role of "client" and one or more others play the role of "services" provided to the client. is applies from the smallest programs (in which the client may be a function that computes the average of a list of numbers, and the services the built-in libraries that provide basic arithmetic and list manipulation) to the largest systems (in which the client may be a payroll application and the service a relational database).

is client-and-service composition allows components with more complex functionality to be built from simpler ones, and it allows components to be layered. A client only sees the components it uses in terms of the services they provide; it can't tell that those components themselves may be using other services.

For concepts, this form of composition won't work. Since concepts are by denition user-facing, we would not want one concept to be hidden behind another. Moreover, concepts must be freestanding; this is what allows them to be understood independently of one another, and reused in dierent contexts. In client-and-service composition, the client cannot operate independently of the services, and its behavior can't even be predicted unless the behavior of the services it uses are known.

### *A New Kind of Composition*

Concept composition is less familiar but simpler. e concepts run, by default, independently of one another. eir actions can be invoked in any interleaving and any order, so long the individual concepts permit it.

ink of a row of snack and drink machines you might nd in a railway station. You can walk up to any machine, insert a coin, and make your choice; and you can also put a coin in one machine, then put one in another machine, go back to the rst machine and make a choice there, and so on. e only constraint on the order of actions is imposed by the machines themselves: that you can't get a drink before inserting a coin, for example.

To make concepts work together for joint functionality, we'll synchronize their actions. is will involve constraining both the order in which actions happen, and the relationships between the values that are passed in and out.

We could hook up the change machine with a drink machine, so that when you insert a dollar bill into the change machine and obtain four quarters in return, the four quarters are automatically used to buy a soda in the drink machine. is is a synchronization.

If we just observe the sequence of actions, each machine still behaves as before. But in composition, some sequences of actions can no longer happen—namely those in which geing change is not followed by buying a drink. Automation doesn't do new things that you could not previously have done manually; it just makes them inevitable.

#### 6: concept composition

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_24_Picture_1.jpeg)

fig. 6.1 *A todo app showing the tasks carrying the label "chores."*

### *Free Composition*

e loosest kind of composition is *ee composition*, in which the concepts are merged in a single product, but operate mostly independently of one another.

Todoist is a simple but elegant to-do app (Figure 6.1). It augments the basic functionality of to-do lists with a small number of additional features, such as organizing tasks into projects and subprojects, and aaching labels to tasks. Let's look at one of these additions, labeling, and see how it can be expressed as a concept composition.

We'll consider the *todo* concept and the *label* concept in their most rudimentary forms (Figures 6.2 and 6.3). e *todo* concept maintains a set of tasks partitioned into *done* and *pending* (these comprise the state); a task starts out as *pending* aer you *add* it, and becomes *done* when you mark it as *complete* (the operational principle).

e *label* concept associates labels with items, and includes an action *find* that produces all the items that carry a given label. ere's also a *clear* action that removes all the labels associated with an item. e operational principle says that if you *affix* a label to an item, and then invoke *find* with just that label (and do not *detach* the label from the item in the meantime), that item will be included in the results; and conversely, if you never *affix* a label to an item, or you detach the label, that item won't appear in the results when you query for that label.

**concept** todo **purpose** keep track of tasks **state** done, pending: set Task **actions** add (t: Task) when t not in done or pending add t to pending delete (t: Task) when t in done or pending remove t from done and pending complete (t: Task) when t in pending move t from pending to done **operational principle** after add (t) until delete (t) or complete (t), t in pending after complete (t) until delete (t), t in done fig. 6.2 *e todo concept dened.* **concept** label [Item] **purpose** organize items into overlapping categories **state** labels: Item -> set Label **actions** affix (i: Item, l: Label) add l to the labels of i detach (i: Item, l: Label) remove l from the labels of i find (l: Label) : set Item return the items labeled with l clear (i: Item) remove item i with all its labels **operational principle** after affix (i, l) and no detach (i, l), i in find (l)

if no affix (i, l), or detach (i, l), i not in find (l)

fig. 6.3 *e label concept dened.*

In practice, these concepts provide more functionality: *todo* might associate deadlines with tasks for example, and display them accordingly, and *label* might oer richer queries (on combinations of labels, for example). For understanding composition, however, these would be needless complications.

#### 6: concept composition

- <sup>1</sup> **app** todo-label
- <sup>2</sup> **include**
- <sup>3</sup> todo
- <sup>4</sup> label [todo.Task]
- <sup>5</sup> **sync** todo.delete (t)
- 6 label.clear (t)

![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_26_Picture_7.jpeg)

fig. 6.4 *A ee composition of todo and label concepts. In the diagram (right), the circles on the le represent actions provided to the user, and the black arrow denotes the synchronization.* 

e composition is shown in Figure 6.4. It gives a name (*todo label*) to the little "app" formed by the composition, lists the concepts that are included in the composition (*todo* and *label*), and then species the *synchronizations*. Note that the inclusion of the *label* concept specializes it for labeling tasks, by instantiating it with the *Task* type of the *todo* concept.

In this case, there is just one synchronization, which says simply that deleting a task in the *todo* concept causes the labels of that task to be cleared in the *label* concept. at is, when a task is deleted, its labels disappear too. Without this synchronization, a task that no longer existed from the point of view of the *todo* concept might still have labels in the *label* concept. is would result in some anomalous behaviors: if you axed a label to a task, deleted the task, and then searched for the label, the task would appear in the results.

In case you nd this underwhelming, let me reassure you that this is indeed a boring composition. We're just geing set up for some more interesting examples. What you need to understand is that puing two concepts in composition allows the user to invoke their actions in any order. Without synchronizations, the only constraints are those imposed by the concepts themselves (for example, that you can't delete a task before you've added it).

In free composition, the concepts are largely independent of one another, but there may still be some bookkeeping to do to ensure that nonsense executions are ruled out. In this case, puing the concepts together without any synchronization would allow an execution in which you *delete* a task (in the *todo* concept) and it then appears in the results of a *find* (in the *label* concept). With the synchronization, *todo.delete* is always immediately followed by *label.clear*. You can still perform the *find*, but the *clear* action will already have happened, so the *find* will not display the task that you just deleted.

```
1 concept email
2 purpose communicate with private messages
3 state
4 inbox: User -> set Message
5 from, to: Message -> User
6 content: Message -> Content
7 actions
8 send (by, for: User, m: Message, c: Content)
9 when m is a fresh message not in a user's inbox
10 store c as content of m
11 store 'by' as user m is from, and 'for' as user m is to
12 receive (by: User, m: Message)
13 when m is to user 'by' and not in inbox of 'by'
14 add m to inbox of by
15 delete (m: Msg)
16 when m belongs to some user's inbox
17 remove m from that inbox
18 forget from, to and content of m
19 operational principle
20 after send (by, for, m, c) can receive (by, m),
21 and m in inbox of by and has content c
```

fig. 6.5 *e email concept dened.*

Paradoxically perhaps, synchronization never adds new executions. It merely *removes* some executions: in this case the ones that don't make sense. Every other execution that can be obtained by interleaving executions of the two concepts remains. For example, the composition admits a behavior comprising the following actions: *todo.add (t)*, *label.affix (t, l)*, *todo.complete (t)*, *label.find (l): t*—that is, adding a new task *t*; axing a label *l* to it; marking the task as completed; querying for all tasks with that label and obtaining that same task *t*. 64

Because the purpose of the synchronization in cases like this is to ensure that the same set of things exists from the point of view of each concept that the *label* concept doesn't reference tasks that the *todo* concept doesn't know about—we might say that the concepts are "existence coupled." In every other respect, the concepts are orthogonal. e *todo* concept is oblivious to the axing and detaching of labels, and the *label* concept is oblivious to whether tasks are pending or done.

Examples of this loose form of composition are common, especially in apps built on platforms that do not easily support richer synchronization between

#### 6: concept composition

- <sup>1</sup> **app** todo-label-mail
- <sup>2</sup> **include**
- <sup>3</sup> todo
- <sup>4</sup> label [todo.Task]
- <sup>5</sup> email
- <sup>6</sup> **sync** todo.delete (t)
- <sup>7</sup> label.clear (t)
- <sup>8</sup> **sync** email.receive (todo-user, m)
- 9 todo.add (m.content)

<span id="page-28-0"></span>![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-061-090/_page_28_Picture_10.jpeg)

fig. 6.6 *A collaborative composition of todo and email concepts. e diagram describes the synchronization only partially: the arrow om receive to add does not imply that every email.receive leads to a task.add; as the text says, only messages to todo-user are relevant.* 

their components. For example, the web services and content-management plug-ins that oer concepts such as commenting and upvoting work precisely because all they require to connect to a site is some shared identiers (for the items being commented on or upvoted), just like the tasks in our example.

### *Collaborative Composition*

A tighter form of composition connects the concepts together to provide new functionality that neither concept provides by itself. One of the nice features of Todoist is that you can add a task without even opening the app by sending an email message to a special email address associated with your Todoist account.

Viewed as a concept composition, this is just a synchronization of the receiving email action of the *email* concept and the task addition action of the *todo* concept. To make this a bit more concrete, let's dene the *email* concept rst [\(Figure 6.5\)](#page-27-0). e state comprises a mapping from each user to the messages in that user's inbox; a record of whom each message is from and to; and the contents of the messages.

e *send* action forms a new message with some content; the *receive* action takes a message that has been previously created for the recipient, and adds it to their inbox. e operational principle expresses the idea of message transfer: aer a user has sent a message with some content, the recipient can receive it, resulting in its being added to the recipient's inbox and having the content that was associated with it when it was sent.

is time, the composition [\(Figure 6.6\)](#page-28-0) is a bit trickier. It incorporates the previous synchronization, along with a new one that ties the *receive* action of the *email* concept to the *add* action of the *todo* concept. I've given the name *todo-user* to the special email account that receives the task messages. By constraining the *receive* action to be performed by this user, we ensure that the receiving of emails by other users is unaected by this synchronization. Note also that the *add* action binds the task being added to the content of the email message, as expected.

In the real app, the synchronization is more elaborate: you can format the subject and body of the email message to separately set the task's title and description, and you can even ax a label to the task using a hashtag notation. But the simplied synchronization that I've proposed should convey the essence of the design.

e new functionality is really just a convenience that automates a step. In principle, you could send yourself an email every time a task you wanted to add to your todo list came to mind, and then at some later point, read all those emails and add them as tasks in the todo app. e synchronization spares you this extra work.65

Here are some of the ways in which collaborative composition can be used: *Logging*. A concept that tracks occurrences of events can be composed with other concepts. e tracking may be for diagnosis (determining why a failure happened by keeping and later analyzing the sequence of events that led up to it); performance analysis (checking the responsiveness of a service); analytics (collecting data on the users of a service and their usage paerns); intrusion detection (by searching for paerns of requests that might suggest that an aack is underway); or auditing (recording which hospital employees access health records, for example).

*Suppression*. In a security context, a concept may be added solely to suppress certain actions in other concepts. An *access control* concept could prevent actions by unauthorized users, by synchronizing its *grantAccess* action with the action to be authorized, so that if *grantAccess* cannot occur (as determined by *access control*), the action tied to it won't be able to occur either. e same idea can be used to limit access more generally, for example composing a *friend* concept in a social media app with a *post* concept in such a way that one user can only read another user's post if the two users are friends.66