softwaredesign/raw/book/EssenceOfSoftware_Eng/concepts-031-060/concepts-031-060.md

#### 2: discovering concepts

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

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

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

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

fig. 2.7 *A design issue at the linguistic level: inconsistent interpretation of icons in Google apps and how new icons xed the problem. On the le, the original icons for opening apps and switching to grid view; on the right the new icons for the same actions, now distinguished.* 

interpret this (and might expect the prohibition to be expressed instead with a red diagonal bar).<sup>22</sup>

When user interface designers talk about the need for consistency, they're usually referring to the use of language at this level. Consistency includes ensuring that the same words are used in the same way throughout an interface for example, that containers for les aren't called "folders" in one place and "directories" in another—and that icons are used systematically. Figure 2.7 shows how Google violated this principle by using two near-identical icons for dierent functions (but xed the problem a few years later). Both depicted an array of black squares, but one opened a menu of Google apps, and the other switched to a view in which les appear in a grid.

e third, and highest, level of design is the *conceptual level*. It's concerned with the behavior that underlies the design: the actions that are performed by the user (and by the soware itself) and the consequences that they have on underlying structures. In contrast to the linguistic level, the conceptual level isn't about communication or culture, even though (as we'll see in Chapter 10) prior knowledge of a concept makes it easier to learn and use.

In programming, there is a familiar and important distinction between *abstraction* and *representation*. An abstraction captures the essence of a programming idea, and may be expressed as a specication of the observable behavior. A representation is the realization of that essence in code.

In the same way, a user interaction has an abstraction and a representation. e abstraction is the concept—the essence of the structure and behavior and is the subject of design at the conceptual level. e representation is the realization of the concept in a user interface, with all its physical and linguistic details, and is the subject of design at the lower levels.

Just as a single programming abstraction can have dierent representations, so a concept can be realized in dierent user interfaces. And just as programmers think rst about the abstraction and only second about the representation,

so designers think at the conceptual level before the lower levels. Until now, designers have not had a way to express conceptual design ideas without representing them in a concrete user interface. e goal of this book is to show that such ideas can be expressed directly, prior to and independently of representation choices.

## *Mental Models and Concept Design*

In most soware apps, the diculties that users have are rarely due to an app having too few features or too many. e more common problem is that users can't make eective use of the functionality that actually exists. is may happen because users don't actively seek out features, and assume that they're not there.<sup>23</sup>

More oen, though, users are aware of features but are just unable to use them successfully. e most common reason for this is that the user has a mental model that is incorrect—that is, incompatible with the mental model of the designer and implementer of the soware. Although research has shown repeatedly (and unsurprisingly) that users oen have vague, incomplete and even inconsistent models of the devices they use, they do develop conceptions that are similar, at least in form if not in every detail, to the conceptions held in the minds of the designers.24

But when users have grossly incorrect mental models they are unlikely to be able to use the functionality eectively, as we saw in our Dropbox example. ey may suer serious losses, or be so nervous of making a costly mistake that they use a tiny subset of functions.

A bad solution to this problem is to try and educate users. It won't work in general because most users will resist spending time learning how to use an app; they expect (not unreasonably) to pick it up as they go along. A beer solution is to design the concepts of the soware so that they are simple, exible and well suited to the user's needs, and to design the user interface to convey those concepts to the user.

e concepts themselves are then the basis both for the intended mental model of the user and the specication given to the programmer. e task of the user interface designer is to project what the usability researcher Don Norman calls a "system image" that corresponds faithfully to the conceptual model, so that users will acquire a mental model aligned with it.25

#### 2: discovering concepts

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

fig. 2.8 *e central role of concepts (le) in aligning the user's mental model (top right) and the developer's design model embodied in the code (boom right). By mapping the concepts carefully to the user interface (middle right), the concepts are not only fully supported but also conveyed implicitly to the user.* 

Figure 2.8 depicts this. At the top, there is the user; at the boom, the code wrien by the programmer; and between the two, the user interface. For the soware to be successful, we need to understand the user (by investigating her needs, working environment and psychological qualities); ensure that the code meets its specication (by testing, review and verication); and cra a usable interface. But most important of all is aligning the model in the head of the user with the model in the head of the programmer, and that is achieved by explicitly designing concepts that are shared by user and programmer alike, and conveyed clearly in the user interface.

## *Lessons & Practices*

Some lessons from this chapter:

- · Major usability problems in soware applications can oen be traced to their underlying concepts. In Dropbox, for example, confusions over whether deletions will aect other users is explained by Dropbox's adoption of a concept that originated in Unix.
- · Soware design is conducted at three levels: the physical level, which involves designing buons, layouts, gestures and so on that are matched to

the physical and cognitive capabilities of human users; the linguistic level, which involves designing icons, messages and terminology to communicate with users; and the conceptual level, which involves designing the underlying behavior as a collection of concepts. e two lower levels are concerned with representing the concepts in the user interface.

· For users, having the right mental model is essential for usability. To ensure this, we need to design concepts that are simple and straightforward, and to map the concepts to the user interface so that the concepts are intelligible and easy to use.

### And some practices you can apply now:

- · Take an app you have trouble using. Ask yourself what concepts are involved, and check that your hypotheses about how they work match the actual behavior. If not, can you nd dierent concepts that explain the behavior more accurately?
- · As the designer of an app, consider the functions that users nd hardest to use (or easiest to misuse). Can put your nger on one or more concepts that are responsible?
- · When designing, know what level you're working at. Start at the conceptual level, and move down. Sketching concepts out at the lower levels can help you grasp them more intuitively, but resist the temptation to polish the physical interface (for example, worrying about typefaces, colors and layout details) before you have a clear sense of your concepts.
- · When you hear complaints about an app that focus on physical or linguistic aspects, ask if the underlying issue may lie at the conceptual level instead.

# How Concepts Help

In traditional design disciplines, design evolves from a conceptual core. is core diers from eld to eld. Architects call it the *parti pris*: an organizing principle for the work that follows, represented by a diagram, a short statement or an impressionistic sketch. Graphic designers call it *identity*, and it typically comprises a few elements that capture the spirit of the project or organization. Composers build music around *motifs*—sequences of notes—that can be altered, repeated, layered, and sequenced together to form larger structures. Book designers start from a *layout* that species the dimensions of the text block and margins, and the typefaces and sizes in which the text will be set.

When the core is well chosen, the subsequent design decisions can seem almost inevitable. e design as a whole emerges with a coherence that makes it look like the product of a single mind even if it was the work of large team. Users perceive a sense of integrity and uniformity, and the underlying complexity gives way to an impression of simplicity.

For a soware application, the conceptual core consists of—no surprise here—a collection of key concepts. In this chapter, we'll explore the roles that such concepts play, such as characterizing individual applications, application families, and even entire businesses; exposing complexity and usability snags; ensuring safety and security; and enabling division of labor and reuse.

# *Concepts Characterize Apps*

If you're trying to explain an app, outlining the key concepts goes a long way. Imagine encountering someone who time-traveled from the 1960s and wanted to know what Facebook (Figure 3.1) was and how to use it. You might start with the concept of *post*, explaining that people author short pieces that can be read by others; that these are called "status updates" in Facebook (and "tweets" in Twier) is a small detail. en there's the concept of *comment*, in which one person can write something in response; the concept of *like* in which people

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

fig. 3.1 *A screenshot of Facebook in which three concepts are evident: post (represented by the message and the associated image), like (represented by the emoticons at the boom le), and comment (represented by the link on the boom right).* 

can register approval of a post, purportedly to boost its display ranking; and of course the concept of *friend* that is used both to lter what's shown to you and to provide access control so you can limit who sees your posts.

e dierence between apps that oer similar functionality can oen be explained by comparing their concepts. For example, a key dierence between text messaging and email is that text messages are organized using a *conversation* concept in which all messages sent to a particular recipient appear; email messages, in contrast, are typically organized using concepts such as *mailbox*, *folder* or *label*. is is partly because the senders and recipients of text messages are uniquely identied by their phone numbers, whereas email users tend to have multiple addresses, which makes grouping into conversations unreliable. It also reects dierent modes of interaction, with text messages relying on the context of the conversation and email messages more oen interpreted in isolation (and thus oen quoting previous messages explicitly).

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

| General                     |                         |           | Style N  | Name: body | ,         |            |
|-----------------------------|-------------------------|-----------|----------|------------|-----------|------------|
| Basic Character Formats     | Location:               |           |          |            |           |            |
| Advanced Character Formats  | Basic Character Formats |           |          |            |           |            |
| Indents and Spacing         |                         |           |          |            |           |            |
| Tabs                        | Font Family: A          | Arno Pro  |          |            |           |            |
| Paragraph Rules             | Font Style: R           | Regular   |          |            |           |            |
| Paragraph Border            | Size:                   | Ĉ 11.5 pt |          | Leading:   | 🗘 15 pt   |            |
| Paragraph Shading           | Kerning: N              |           |          | Tracking:  |           |            |
| Keep Options                |                         |           |          |            |           |            |
| Hyphenation                 | Case: N                 | Normal    |          | Position:  | Normal    |            |
| Justification               |                         |           | □ Unde   | rline      | Ligatures | □ No Break |
| Span Columns                |                         |           | C Strike | ethrough   |           |            |
| Drop Caps and Nested Styles |                         |           | Suike    | eunougn    |           |            |

fig. 3.2 *e style concept, in Adobe InDesign, showing one tab of the formaing seings for a style called "body," which is the style associated with regular paragraphs in this book.* 

Sometimes it takes experience and expertise to identify the key concepts in an app. Novice users of Microso Word, for example, might be surprised to learn that its central concept is *paragraph*. Every document is structured as a sequence of paragraphs, and all line-based formaing properties (such as leading and justication) are associated with paragraphs rather than lines. If you want to write a book in Word, you won't nd any concepts that correspond to its hierarchical structure—no *chapter* or *section*, for example—and headings are treated as paragraphs like any other. Word achieves its exibility and power through the *paragraph* concept and by the powerful way in which it is combined with other concepts.26

# *Concepts Characterize Families*

Concepts not only distinguish individual apps, but also unify families of apps. Programmers, for example, commonly use *text editors* (such as Atom, Sublime, BBEdit and Emacs) to edit program code; people use *word processors* (such as Word, OpenOce and WordPerfect) to create documents of all sorts; and professional designers use *desktop publishing* apps (such as Adobe InDesign, QuarkXPress, Scribus and Microso Publisher) to organize documents into nalized layouts in books and magazines.

e key concepts of text editors are *line* and *character*. e *line* concept embodies both powerful functionality (such as the ability to perform "dis" and "merges" which are essential to programmers for managing code) as well as limitations (notably that there is no distinction between a line break and a

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

fig. 3.3 *e text ow concept, in Adobe InDesign, showing this very page spread and its ows. e diagonal lines show the links between the text boxes that comprise a single ow.* 

paragraph break). To get around this, some layout tools (such as LaTeX) that take input from text editors adopt conventions, such as inserting a blank line to indicate a paragraph break.

e concepts of word processors include not only *paragraph* but also *format*, which lets you assign typographic properties such as "bold" and "12pt" to text, and the concept *style*, for bundling format seings and associating them with paragraphs, for example dening a "body" style that sets the type size, font, and so on for all regular paragraphs [\(Figure 3.2\)](#page-6-0).

Desktop publishing apps include the basic concepts of word processors, but add most signicantly the concept of *text flow*, which lets you set up boxes in dierent places in the document that are linked together so that imported text ows from one to the other. is is the concept you need to typeset a magazine, in which an article is split across pages, where you want to be able to adjust the dimensions of a textbox on one page and have the text ow automatically to another (see Figure 3.3).

Surprisingly perhaps, amongst these three families, only one includes the concept of *page*. It's there in a minimal form in word processors (which allow

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

fig. 3.4 *Layer and mask concepts in Photoshop; an adjustment layer has been added to darken the image, along with a mask that restricts the darkening to the area of the sky.* 

you to size the margins and set up headers and footers), but only in desktop publishing apps can you reorder, add, and delete pages independently of the text that ows through them.

# *Concepts Dierentiate Products*

When a soware product dominates a market, or hopes to, one or more new concepts are oen the root of its success (or aspiration to succeed). Photoshop became the dominant photo editing program due to its *layer* concept, which made non-destructive editing possible, and, in combination with the *mask* concept, allowed local edits (Figure 3.4).

Apple's *trash* concept was so central to its new desktop that an early advertisement for the Lisa computer claimed that "If you can nd the trash can, you can run a computer." In part, the trash was just the most stylish and quirky application of the WIMP (windows, icons, menus, pointer) interface idea pioneered at Xerox PARC, and it played this role in Apple's 1988 suit against Microso and Hewle Packard for copying the Macintosh's interface.

But despite all the aention paid to its charming icon, the *trash* concept was something more. Contrary to a common misunderstanding,27 the purpose of the *trash* is not deleting les but exactly the opposite—undeleting them. 
e *trash* therefore is an exemplar of something deeper: the operating system's

greater tolerance to user errors, now recognized as a fundamental principle of user interface design. (More on the *trash* concept in Chapter 4.)

e spreadsheet, invented by Dan Bricklin in 1979 and one of the most successful innovations in computing, brought a new model of computation inspired by accounting ledgers. But its crucial novelty was not an accounting feature, but a remarkable new concept: the *formula*, which allowed the value of one cell to be dened in terms of values in other cells. In fact, VisiCalc, Bricklin's product, was not an accounting app at all, and other apps that had been targeted directly at accounting failed. e *formula* concept was powerful because it allowed you to model all kinds of computations. It was also nontrivial, relying on the subtle partner concept of *reference* which, by distinguishing absolute and relative positions, made it possible to copy a formula from one cell to another.

As a more contemporary example, the scheduling company Calendly oers an app whose dierentiator is a concept called *event type*. In short, you dene a collection of types of events (such as 15 minute phone calls, hour-long in-person meetings, etc), each with its own characteristics, such as the length of the event, its cancellation policy, what kinds of notications occur, and so on. en you indicate what your availability is for each event type, and people book appointments based on the event types.

It's a fun and enlightening game to try and identify the linchpin concept in a familiar app or system. Take the World Wide Web, for example. You might guess *html* or *link*, but markup languages and hypertext had been around for a long time. e core of the Web is in fact the *url* (uniform resource locator) concept: the idea of giving globally unique and persistent names to documents. Without that, the Web would be no more than a collection of proprietary networks, each operating in its own silo.

# *Concepts Expose Complexity*

Many concepts are straightforward and easily learned. But others are more complicated. Some complications are not warranted and are just evidence of bad design (more on this below), but sometimes the power that a concept brings justies its complexity.

Photoshop's *layer* and *mask* concepts fall in this category. When I started with Photoshop, I tried to learn it by playing around and by watching videos showing you how to do specialized tasks such as removing red-eye. Eventually,

though, I realized that I needed to understand the core concepts more deeply, so I found a book that explained layers and masks (and channels, curves, color spaces, histograms, etc.) from a conceptual point of view, and I was then able to do whatever I wanted.

Some of the most complex concepts appear in apps that are widely used by non-experts. Browser apps include the *certificate* concept for checking that the server you're talking to belongs to the company you expect—your bank, for example, rather than an interloper trying to steal your credentials—and oer the *private browsing* concept to prevent your browsing information from being available to others aer you've logged out. Despite the critical importance of these concepts for security, they are poorly understood. Most users have no idea how certicates work and what they're for, and they oen think that private browsing allows them to visit sites without being tracked.

Worse, some of the most basic behaviors of browsers rely on complex concepts that are invisible to most users. e *page cache* concept, for example, is used by website developers to make pages load more quickly, by using previously downloaded content. But the rules for when old content is replaced (and how these rules are modied) are obscure even to some developers, so users and developers alike may be uncertain about whether content that appears in the browser is fresh or not.

Highlighting tricky concepts is helpful because of the focus it brings. It tells us, as users, what we need to learn: if you want to be a power user, just ignore all the details of the interface—those will come easily later—and master the handful of key concepts. It helps us, as teachers, to focus on the essence: so when we teach web development, for example, we can explain the important concepts—sessions, certicates, caching, asynchronous services, etc.—without geing caught up in the idiosyncrasies of particular frameworks. And it suggests opportunities to us as designers for innovation. A beer concept for server authentication, for example, might prevent a lot of phishing aacks.

## *Concepts Dene Businesses*

"Digital transformation" is a grandiose term for a simple idea: taking the core of a business and puing it online, so customers can access services through their devices. In my experience as a consultant, I've sometimes found that executives, seeking to refresh and expand their business, instead of trying to un-

derstand what that core is, look to cool technologies. ey hope to gain market share by moving to the cloud, or by incorporating machine learning or blockchains, oen without a clear sense of the problem being solved.

Investing in core concepts is less ashy but likely to be more eective. First, just identifying the core concepts of a business helps you focus on what services you provide now (and might provide in the future). Second, analyzing those concepts can expose friction and opportunities to streamline the business. ird, an inventory of concepts can be ranked to reect the value of each concept (to the customer and the company) and the cost of implementing and maintaining it, providing a basis for strategizing about the services the company provides. Fourth, by consolidating a set of core concepts, a company can ensure that customers have a uniform experience across technology platforms and company divisions, and can reduce the cost of having multiple variants of concept, each with its own implementation (and the concomitant headache of resolving dierences in schemas when data is transferred between parts of the company).

e best services revolve around a small number of concepts that are well designed and easy for customers to understand and use, and their innovations oen involve simple but compelling new concepts. In Apple's concept of *song*, for example, Steve Jobs saw the opportunity to provide every step of the experience of selecting, buying, downloading and playing music in a single unied concept.<sup>28</sup>

In contrast, consider what the airline business oers. Its key concept is arguably the *seat*, and yet few concepts are as obscure and hard to use. In an aempt to maximize prot, most airlines hide their pricing strategies for seats (so that only experts can tell how the price they are being oered compares to the price of other seats on the same plane, being sold now or in the past), divulge lile information about the details of the product (such as how much room you get, and how dierent seats on the same plane compare), and may not even let you choose your seat in advance. e *frequent flyer* concept is typically mired in caveats and exclusions, and oen employs a collection of misleading and dishonest tactics to ensure that customers derive as lile value as possible.29

| Q has:nouserlabels |                                                     |
|--------------------|-----------------------------------------------------|
| □ - C :            |                                                     |
| ☐ ☆ Alyssa, me 3   | Inbox hacking meetups javascript - Yes, it does.    |
| Alyssa P. Hacker   | Inbox   Social   buy this! - My new JS book is out! |

fig. 3.5 *Labels in Gmail. I've entered a search query to show messages with no user-dened labels, but the rst item seems to carry such labels ("hacking" and "meetups"). e explanation is that Gmail shows all conversations that contain messages satisfying the query, along with any labels aached to their messages. So a conversation containing one message without labels, and another message with labels, will appear in this search.* 

# *Concepts Determine Costs and Benets*

When you're planning the development of an app, you can use the list of candidate concepts to scope the app's functionality, and make trade-os between costs and benets. Of course, developers have been doing something like this for decades, using informal notions of functionality or features. What concepts bring is a clearer division of functionality into free standing units, each with its own value and costs.

Put another way, before including any concept in your design, you want to *justify* its inclusion by considering (a) the purpose of the concept (and how valuable that is to your users); (b) the concept's complexity (and thus the cost of developing it, and the cost to users in terms of potential confusion); and (c) the concept's novelty (and thus the risk it entails).

No doubt the 80:20 rule applies to concepts: that 20% of concepts deliver 80% of the benet. at does not mean that the less useful concepts are not important. Oen, a concept that is useless to one user is essential to another. But sometimes a concept that is central to the design of an app ends up being underused.

e *label* concept in Gmail, for example, is the key mechanism for organizing messages. It must account for a considerable portion of Gmail's development complexity. As we'll see later in the book, the concept is mired in complications, and seems to be a source of confusion to users (Figure 3.5). It's also the reason that Gmail users can't always distinguish which messages they've sent

and which they've received, because the *sent* label, like all others, is aached in the display to an entire conversation and not to an individual message. And yet it seems that less than a third of Gmail users create any labels at all!30

### *Concepts Separate Concerns*

What is the single most important strategy in problem solving? e prize, I believe, must go to *separation of concerns*, in which dierent aspects or "concerns" are addressed separately, even if they are not entirely independent.31

Concepts provide a new way to separate concerns in soware design. Suppose, for example, you're designing a group forum in which members post messages and share various kinds of assets (such as images). At rst sight, you might identify a *group* concept that embodies all the behavior of a group, such as joining the group, posting messages, reading other people's posts, and so on. But a more granular design might separate the functionality into several smaller concepts: a simpler *group* concept to capture the membership aspect and the way in which assets (such as messages and posts) are associated with groups; a *post* concept for the composing and formaing of messages; an *invitation* concept for inviting members to join; a *request* concept so that members can initiate membership; a *notification* concept that governs the messages members receive to notify them when certain status changes occur or when other members respond to their posts; a *moderation* concept for handling moderation of messages; and so on.

Such a separation is potent because it allows the designer to focus on one aspect at a time: you don't need to be thinking about whether membership invitations can be revoked at the same time that you're trying to shape the moderation pipeline. Each concept can be enriched arbitrarily, even becoming a small system in its own right—or it might be omied entirely if the designer decides that its cost is not in proportion to its benet.

e same breakdown that benets a single designer applies to a team. By assigning concepts to dierent team members (or subteams), you can make progress in parallel. With a distinct purpose for each concept, the individual eorts are unlikely to conict, and any incompatibilities between the designed concepts can be resolved when they are composed together.

## *Concepts Bring Reuse*

Breaking a design down into the most basic, elemental concepts exposes opportunities for reuse. In the group forum app, the designer, having identied the *moderation* concept, for example, would be wise to explore how moderation is achieved in other contexts. at posts in a forum are the subject of the moderation, rather than comments on a newspaper article, can initially be ignored. Once the variety of standard moderation options are ready to be considered, the designer can ask whether one might be more suited to the context than another. Even beer, the designer might discover that an o-the-shelf solution can be adopted in its entirety, thus reusing not only the idea of the concept but its implementation too.<sup>32</sup>

Many concepts are reused in almost an identical form across apps. Imagine a handbook of concept designs. Rather than reinventing the wheel, a designer could look up a concept, and read about all the tricky issues associated with it, along with their conventional solutions.

For example, almost all social media apps incorporate some form of the *upvote* concept, in which users register their like (or sometimes dislike) of an item, with an impact on its prominence in feeds and search results. If you were designing this concept for the rst time, you would probably realize early on that you needed some way to prevent double voting, and that this would depend on somehow identifying the user when they upvote an item.

But you might not know the range of ways to identify users and their relative advantages and disadvantages: whether you should make them log in and rely on their user names; or use their IP addresses as proxies; or install a cookie just for this purpose; and so on. You might not have thought to mitigate the cost of storing the identity of the user with each vote by freezing voting on archived items (so that the identities associated with prior votes can be discarded). Nor might you have considered weighting of votes: whether some users' votes should be more inuential, or whether more recent votes should count for more than older votes. A handbook of concepts would have an entry for *upvote* that lists all these design options and their trade-os, allowing you to save the eort of exploring design paths that others have traveled down many times before.

## *Concepts Help Identify Usability Snags*

Sometimes a soware app or service turns out to be very hard to use, frustrating some users so much that they reject it in its entirety. When this happens, the problem can sometimes be pinned on a single concept.

Apple oers cloud storage for data held on a user's devices: laptops, phones, etc. e cloud storage serves two distinct purposes. One is to synchronize data between devices. is makes it easy, for example, to maintain the same set of bookmarks in your browser irrespective of the device you're using. e other is to provide backup, so that if a device is lost or its storage damaged, the data can be restored from the copy held in the cloud.

Apple's design strategy has always favored simplicity and automation over manual control, even in cases where giving more control to the user seems essential. Its *synchronization* concept is a prime example of this strategy, and as a result is oen the source of complaints from confused customers.

Sometimes Apple's design seems to put the user in a catch-22 situation without any viable options. Consider the dilemma you face if your iPhone runs out of storage space. When this happens, you get a warning message telling you that your phone is about to run out of space, suggesting that you "manage your storage in Seings."

At this point, none of your options are very aractive. Suppose you nd that your photos are taking much of the space. You can delete the entire Photos application, with all its associated data and state. You can turn on "optimized storage" which converts photos to lower-quality versions (while keeping the higher-quality versions as master copies in the cloud). What you can't do, however, is simply to delete some of your photos from the phone, in the hope that they will remain on your other devices. If you do that, the photos you delete on your phone will also be deleted from the cloud. And then those deletions will be propagated to all your other devices, removing the photos from them too.

What's missing from Apple's *synchronization* concept is the idea of *selective synchronization*: the ability to indicate that some les should not be synchronized. With this feature, you would be able to delete old photos from your phone, while leaving copies in the cloud. Dropbox's*synchronization* concept, in contrast, does oer this feature, so it's certainly feasible.33

## *Concepts Ensure Safety and Security*

e popularity of the term "secure by design" reects a growing consensus that security—a concern for all soware systems today—is best achieved not by closing all security holes (an impossible task anyway) but by designing systems to be secure despite them.

Security design relies on a few key concepts to establish system-wide properties: *authentication*, to ensure that the actors (or "principals" as they are called in the security eld) who make requests are correctly identied; *authorization*, to ensure that those actors can only access certain resources; *auditing*, to ensure that every access is faithfully recorded (and bad actors can be punished accordingly); and so on.

Each of these concepts has many variants, and understanding the security of a system rests on understanding these variants deeply. If a concept is used casually, without carefully analyzing its purposes and assumptions, a system that appears to have all the right protections may turn out to be vulnerable.

Take *two-factor authentication*, for example. It works like this: a user logs in to a service, which then sends a special key to the user through another channel, usually by a text message to a phone; the user enters the key, and in return receives a credential (in the form of a cookie or some other kind of token) that grants the desired access. e user is conrmed by this scenario as the owner of the phone (say) and thus also as the legitimate account holder.

is design, however, is fraught with complexities. First, the assumption that access to a phone number implies ownership of the associated phone is questionable: Jack Dorsey, CEO of Twier, fell victim to a "SIM swapping" aack in 2019 when hackers took control of his phone number. Second, the design involves an additional concept—namely *capability*, in which a token is provided that grants access to anyone who holds it—and in the interaction between the two concepts lies a gaping security hole.

Suppose you receive a phishing email, asking you to conrm a LinkedIn connection, containing a URL that points not to the real LinkedIn site but to a server owned by a hacker. is server mimics the real server, and gives you the impression that you are talking to LinkedIn itself. When you enter the two-factor authentication key, the malicious server passes it on to LinkedIn, obtains

your access token, and passes the token on to you. All seems ne, but the hacker has the token too, and can now access your account as you.34

ese issues are contained within a few critical security concepts. Only the design of the concepts and their interactions is relevant; the code must implement the concepts correctly, of course, but the design problems are fundamental. e security of a system will thus oen rest on understanding its security concepts and their known vulnerabilities, and if an analysis suggests that stronger guarantees are needed, the concepts will need to be replaced or augmented. In short, security design is in large part about the design and use of appropriate concepts.

Concepts are central to the design of all critical systems.35 In the domain of safety rather than security, there are fewer standard concepts. Nevertheless, recurring incidents suggest opportunities for new concepts that would play a role similar to concepts in security, embodying conventional ways to encapsulate critical functions. For example, medical devices are rife with mistakes related to dosage calculations, and a *dose* concept that handles all the complications associated with units, concentrations and ow rates might eliminate many of the tragic accidents in which patients are injured or killed by preventable errors.36

# *Concepts Ground Design Critique*

In any eld of design, critique—in which designers review and analyze each others' work—plays a central role. A critique (or "crit") is not a formal evaluation in which principles are systematically applied, and its very informality can provide space for insights and inspiration. Moreover, critique is inevitably subjective, as dierent participants come with their own biases and interests. But eective critique is always deeply informed by experience and expertise, which the critic brings by speaking in a language of known principles and paerns.38

Such principles and paerns have developed around the physical and linguistic levels of design, but not so much at the conceptual level. Even the widely accepted idea that a system should have a clear conceptual model is oen interpreted as a principle at the linguistic level, focusing not on the structure of the conceptual model itself but on how faithfully and eectively the model is projected by the user interface.37

e rest of this book is aimed at lling exactly this gap. Part II provides a language for talking about concepts, and a structure for expressing them. Part III

presents three design principles that govern the selection of concepts and their composition.

Design principles can be used in dierent ways. ey oer a basis for shared understanding in design crits, or can be applied systematically in heuristic evaluations. But their more important role is in shaping the way designers think. Once you have grasped Norman's notion of "mapping," for example, which suggests arranging user interface controls in a layout that matches the layout of the objects being controlled, you'll intuitively create layouts that already have a natural mapping.<sup>39</sup>

Likewise, absorbing the language and principles of concepts should empower you to be a more eective soware designer: it should give you a way to express your ideas more directly and clearly; to solidify your intuition and experience in a more systematic framework; and to inform your judgment with heightened design sensibilities.

## *Lessons & Practices*

Some lessons from this chapter:

- · Concepts characterize individual apps, app classes, and entire product families. ey allow you to compare apps, highlight their essential capabilities, and learn how to use them eectively.
- · Concepts are oen product dierentiators, can bring focus to marketing efforts, and can reveal the reason for a product's success or failure.
- · Concepts can help a company engaged in "digital transformation" map a path forward. More than extending the platforms through which customers can access services or adopting hot technologies, digital transformation is about identifying, consolidating, and extending core business concepts, so that customers have a rich and uniform experience that brings real value.
- · Concepts give a new granularity that lets soware designers separate concerns, exploit reuse, and divide engineering labor more eectively.
- · Concepts are the essence of design for safety and security, where picking the right concepts and understanding their implications is paramount.
- · Concept design oers rules that can be applied when reviewing a design, to avoid problems that might otherwise not be discovered until much later; a designer who internalizes these rules is likely to produce beer designs even if not considering them explicitly.

## And some practices you can apply now:

- · Take an app that you are familiar with and identify a small number of core concepts that characterize it. Consider similar apps, and see if you can explain the commonalities and dierences in terms of their concepts.
- · Try to identify the concepts that are responsible for the success (or failure) of soware products that you have been involved in creating or using.
- · Using the *group* concept as an example, nd a complex feature in some so ware you're familiar with, and break it down into separate, smaller concepts. Does this reveal connections to other products, or opportunities to apply a concept more uniformly?

# Concept Structure

So far, I've talked in rather vague and general terms about concepts. But what exactly *is* a concept? To use concepts eectively, we'll need to go beyond generalities and look at specics. In this chapter, I'll show you how to structure the denition of a concept. is structure will clarify what concepts are (and are not); it will give you a roadmap for designing concepts; and it will allow you to dene each concept precisely.

I'll use three concepts as exemplars, concentrating on their structure but also telling the larger story of their invention and use, and pointing out some of their design subtleties.

Concepts don't make all design problems go away, of course. ey do, however, help you *localize* challenges by recognizing them as specic to a particular concept. A concept becomes a container not only for the behaviors that it embodies but also for all the accumulated knowledge about its design, the issues that have arisen in practice as it has been deployed, and the various ways in which designers have dealt with them.

# *Apple's Killer Concept: Trash*

e *trash* concept was invented by Apple for the Lisa computer, the predecessor of the Macintosh, in 1982. e trash icon (and its cute bulging version when you put something in it, and the niy crunching noise it made when you emptied it) became the emblem of the Macintosh's claim to being a more friendly and usable operating system (Figure 4.1). Since then the *trash* concept has become ubiquitous, appearing not only in the le system managers of other operating systems, but also in many other applications.

At rst glance, the trash icon appears to oer no more than an intuitive gesture for deleting les and folders—by dragging them to the trash rather than executing a more conventional deletion command. e real innovation, however, is not that you can move things *into* the trash, but that you can then move

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

fig. 4.1 *e original Macintosh desktop, with trash at boom right (1984).*

them *out*. e trash holds a collection of items, which can be viewed by opening it; you can then restore items by moving them from the trash to some other location. We might therefore say that the *purpose* of the *trash* concept is not *deletion* but the *undoing* of deletion.40

Of course, you have to be able to delete les permanently too, in order to make space for new les. is is accomplished by "emptying" the trash. So, in summary, you move an item to the trash when you want to delete it; you take it out of the trash when you want to restore it; and you empty the trash when you run out of space and want to permanently remove the items it contains.

To make concept design practical, we need a way to describe concepts succinctly and precisely. Figure 4.2 shows how the *trash* concept can be described. e parts correspond exactly to the explanation I just gave you.

First comes the *name* of the concept.41 Along with the name is a list of the types—here, just one type, *Item*—that can be specialized when the concept is instantiated. So in one instantiation, the items might become the les of a le system; in another, they might be the messages of an email client.

e name is followed by a pithy summary of the concept's *purpose*. en comes the *state*, which organizes the things that comprise the concept into various structures. In this case, there are just two sets: *accessible*, the set of items that

#### 4: concept structure

```
1 concept trash [Item]
2 purpose
3 to allow undoing of deletions
4 state
5 accessible, trashed: set Item
6 actions
7 create (x: Item)
8 when x not in accessible or trashed
9 add x to accessible
10 delete (x: Item)
11 when x in accessible but not trashed
12 move x from accessible to trashed
13 restore (x: Item)
14 when x in trashed
15 move x from trashed to accessible
16 empty ()
17 when some item in trashed
18 remove every item from trashed
19 operational principle
20 after delete(x), can restore(x) and then x in accessible
21 after delete(x), can empty() and then x not in accessible or trashed
```

fig. 4.2 *e trash concept dened.*

are accessible (outside the trash), and *trashed*, the set of trashed items, namely those that have been deleted but not yet permanently removed.42

e *actions* describe the dynamics, the behavior of the concept. Actions are instantaneous—that is, take no time—but any amount of time can pass between them. e description of an action says how the state is updated when the action occurs—for example, that deleting an item moves it from the set of accessible items to the set of trashed items. It may also include a precondition that limits *when* the action may occur—for example, that you can only delete an item if it is accessible but not trashed. (In addition to the actions that came up in the informal overview, the full description includes a *create* action for completeness, since the items that are deleted must somehow come into being.)

Finally, there's the *operational principle*, which shows how the purpose is ful lled by the actions, and comprises one or more usage archetypal scenarios. In this case, there are two scenarios. One is for restoring: it says that aer you delete an item *x*, you can restore it and that item is then accessible. e other is

for permanent removal: it says that aer you delete an item you can empty the trash and the item will be neither accessible nor in the trash.

In a narrow technical sense, the operational principle doesn't add anything, because you can infer any scenario from the action specications. But for understanding *why* the concept is designed the way it is, and *how* it's expected to be used, the operational principle is fundamental.43

is can all be made more precise, with a mathematical model of behavior, and a formal notation for dening actions and operational principles. e details won't maer to most readers, so I've relegated them to the endnotes.44

## *e Trash Concept: Design Flaws Finally Fixed*

is *trash* concept has been very successful, and is widely used. It appears in all graphical le managers (Mac, Windows, and Linux), in email clients (such as Apple Mail and Gmail), and in cloud storage systems (such as Dropbox and Google Drive). Not all instances of the concept oer the exact same behavior; in one common variant, items are permanently removed from the trash when a certain amount of time (say, 30 days) has elapsed since they were deleted.

On the Macintosh, there is only one trash for the entire system, which has some unfortunate consequences. First, as you insert and remove external drives the contents of the trash grow and shrink as the deleted items belonging to those drives come and go. is can be mildly disconcerting: you might see an item in the trash and intend to restore it, but then nd that it has disappeared (because the drive has been ejected).

A more substantive problem arises in the following scenario. Suppose you insert a USB key (a small external ash drive) and try to copy a le to it, but there's not enough room. So you decide to make some space by trashing some les already on the key. You aempt to copy the le to the key a second time, but it fails again. Trashing the les, you then realize, didn't actually make space by removing them permanently; to do that, you need to empty the trash.

But now you have a dilemma. If you don't empty the trash, you won't be able to copy the le to the USB key. But if you do, you'll lose all the les you previously deleted from your hard drive, eliminating the option to restore them in the future.

Amazingly, this problem was le unresolved for over 30 years, and was nally addressed in OS X El Capitan, the version of Apple's operating system issued

#### 4: concept structure

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

fig. 4.3 *Style concept in Microso Word (le) and Apple Pages (right).* 

in 2015. e resolution, which is perhaps more a workaround, was to oer a "delete immediately" action that allows you to permanently remove select items in the trash in one click.

Another design aw involved how les in the trash were listed. For decades, there was no way to sort items in the trash by date of deletion. is meant that if you deleted a le accidentally, and then went to the trash hoping to restore it, you might be out of luck. If you wisely let the trash grow until you really needed the space, your trash would contain thousands of les. If you deleted a le and couldn't remember its name, you had no way to nd it.

In 2011 (with OS X Lion), Apple let you sort items in a folder by their "added date," which, for the trash, corresponds to the date of deletion. (In Chapter 6, I explain this design in more detail, and show how it involves a clever fusion of concepts.)

# *e Concept Behind Desktop Publishing: Style*

Our second example is the concept of *style*, previously mentioned and shown for Adobe InDesign in Figure 3.2 and for Microso Word and Apple Pages in Figure 4.3. Its purpose is to make it easier to achieve consistent formaing.

To use it, you assign styles to paragraphs in your document. For example, you might assign the style *heading* to each of the paragraphs that corresponds to a section heading. Now if you want to make all the headings bold, say, you change the format seing of the *heading* style to *bold*, and all the heading paragraphs will be updated in concert.

at is the operational principle. It's actually a rather elaborate scenario, which involved creating multiple paragraphs, assigning a single style to more

```
1 concept style [Element, Format]
2 purpose
3 easing consistent formatting of elements
4 state
5 assigned: Element -> one Style
6 defined: Style -> one Format
7 format: Element -> one Format = assigned.defined
8 actions
9 assign (e: Element, s: Style)
10 set s to be the style of e in assigned
11 define (s: Style, f: Format)
12 set s to have the format f in defined
13 create s if it doesn't yet exist
14 operational principle
15 after define(s, f), assign (e1, s), assign (e2, s) and define (s, f'), e1 and e2 have format f'
                        fig. 4.4 e style concept dened.
```

than one of them, and then modifying that style. e operational principle is not always the simplest scenario, but it *is* the smallest one that demonstrates how the purpose is fullled. Obviously, to demonstrate consistent formaing of paragraphs, you need more than one paragraph. In the concept denition, the operational principle says that if you dene a style *s* to have format *f*, assign it to two elements *e1* and *e2*, and then redene *s* to have format *f'*, both *e1* and *e2* will now have that new format.

To make this magic work, the concept state (see Figure 4.4) has to be quite complicated. ere are two mappings, one (which I've called *assigned*) that associates with each element the one style that is assigned to it, and the other (which I've called *defined*) that associates with each style the format that it de nes. In this description, a "format" is an abstract thing which you can think of as embodying all the formaing properties (bold, 12pt, Times Roman, etc.). A third component of the state, called *format*, is introduced as a shorthand, and stands for the combination of these two mappings (wrien *assigned.defined*), so that if an element *e* is assigned a style *s*, and style *s* is dened to have format *f*, then element *e* has format *f*. 45

I've dened two actions: one that assigns a style to an element, and one that denes the format for a given style. is second action is used both to create a style with a given format, and to update an existing style with a new format. ese might have been listed as separate actions; both approaches are valid.

#### 4: concept structure

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

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

fig. 4.5 *Style concept applied to slide themes in Microso PowerPoint (le) and color swatches in Adobe apps (right).* 

## *Stylish ings: Not Always Genuine*

e concept of *style* is widely used. It appears in word processors such as Microso Word and Apple Pages, and desktop publishing tools such as Adobe InDesign and QuarkXPress, not only for styling paragraphs but also for styling ranges of characters. It's used in Microso PowerPoint for "color themes," which comprise a collection of predened styles for coloring the various kinds of text (e.g., titles, hyperlinks, body text) and backgrounds that appear on slides (Figure 4.5, le). e "classes" of the web's formaing language, Cascading Style Sheets (CSS), are styles too, where they provide a clean separation of formatting from content.

Sometimes the use of the style concept is not immediately apparent. In Adobe InDesign and Adobe Illustrator, you can color elements by applying a color swatch (Figure 4.5, right). What you might not notice at rst is that the color swatches are modiable. If you color several elements with a red swatch, they will all become red—no surprise there. But now if you open up the red swatch and adjust its sliders to make it green instead, you'll see that all those red elements now become green. is is tremendously useful of course, because it

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

fig. 4.6 *Two concepts that look like style but are not: the Apple color picker (le) and styles in Apple TextEdit (right).* 

makes it easy to maintain a consistent palee, without having to sele on the palee's colors at the start.

Other times, you come across something that appears to be an instance of a concept but turns out not to be. Apple's color picker, used in all of Apple's apps for selecting colors, looks very similar to the Adobe color swatches (see Figure 4.6, le), so we might guess that it's an instance of the *style* concept. But if you play with it, you'll discover that while you can delete a swatch or add a new one, you cannot *change* the color of an existing swatch. is ability to modify the format of a style is essential to the *style* concept. Without it, the concept cannot work at all—that is, its operational principle fails. Adding a new style has no eect on elements associated with an old style, so there's no way to change elements in concert once their format has been dened.

Another near miss is the "style" of Apple's rudimentary word processor, TextEdit (Figure 4.6, right). e name suggests the *style* concept, and you can indeed not only create and delete named "styles" but you can modify them too. When you apply a style to a paragraph, however, it updates the formaing of the paragraph, but the style does not stick: there is no persistent association of the style with the paragraph. Changing a style thus only impacts its future uses, and not the paragraphs that it was applied to before.46

e *style* concept has been enriched in various ways, many of which involve layering of formats one on top of another: for example, partial styles, whose formats only set some properties (say making text italic but not aecting its size); style inheritance, in which one style is dened as an extension of another; and overrides, in which the format of an element is dened by a style with some overriding format.

#### 4: concept structure

```
1 concept reservation [User, Resource]
2 purpose
3 manage efficient use of resources
4 state
5 available: set Resource
6 reservations: User -> set Resource
7 actions
8 provide (r: Resource)
9 add r to available
10 retract (r: Resource)
11 when r in available and not in reservations
12 remove r from available
13 reserve (u: User, r: Resource)
14 when r in available
15 associate u with r in reservations and remove r from available
16 cancel (u: User, r: Resource)
17 when u has reservation for r
18 remove the association of u to r from reservation and add r to available
19 use (u: User, r: Resource)
20 when u has reservation for r
21 allow u to use r
22 operational principle
23 after reserve(u, r) and not cancel(u,r), can use(u, r)
```

fig. 4.7 *e reservation concept dened.*

## *A 19th Century Concept: Reservation*

For our last example in this chapter, let's consider a familiar concept that existed long before soware. e *reservation* concept (Figure 4.7) helps to make e cient use of a pool of limited resources. e provider wants the resources to be used as much as possible; the consumer wants a resource to be available when they need it.

It works like this. A consumer wanting to use a resource aempts to make a reservation. If there isn't already a reservation for that resource, the aempt succeeds. en later when the consumer comes to use the resource it will be available to them.

To run this concept, you need to track the set of reservations, each being associated with the resource being reserved and the consumer who reserved it. In addition to making a reservation and then eventually using the resource, it's

usually also possible for the consumer to cancel the reservation if they decide they don't need it aer all.

Of course, this is belaboring the obvious. You've reserved tables at a local restaurant, books at a library, seats at a concert, etc., so none of this is new. But it's worth noting the form the explanation took. I started with the purpose (making ecient use of resources); then I gave you the operational principle (how a reservation is made and fullled); then the state (a set of reservations); and then nally the actions (*reserve*, *use* and *cancel*).

e description of this concept uses a set (to remember which resources are still available) and a mapping from user to resources for the reservations. is mapping, unlike the mappings in the denition of the *style* concept, is one-tomany: a single user can reserve multiple resources.

e actions also include those performed by the owner of the resources (the restaurant, for example), for providing and retracting a resource. Retracting a resource is tricky if it's been reserved. For simplicity, the denition says that you can't retract in this case, but in practice a beer design would allow the retraction, with an implicit canceling of the reservation. Finally, the operational principle adds a caveat that was missing in my informal account: you can only use the reservation if, having made it, you don't then cancel it before you use it.

# *A Designer's Reservations*

Like any other concept, *reservation* has many variants and additional features. Oen the resource is tied to a period of time. In a restaurant reservation system, the consumer chooses only the start time and the end time is implicit, determined by the restaurant owner (a tricky business, because seing dining times that are too long will mean serving fewer customers, but seing them too short will result in making people with reservations wait). e resource may be associated with a particular physical object (a seat on a plane, for example) or it may represent a fungible member of a class (such as a table anywhere in a restaurant, or any copy of a particular book).

Because reservations are oen free, the provider may need to protect against users who reserve a resource but never use it. Restaurant reservation systems do this by adding a *no-show* action that is executed by the restaurant owner; if a customer has too many no shows, their account is suspended. Another strategy is to prevent consumers from reserving resources that cannot be used together,