feat: Essence of Software wiki 컴파일 + raw 원본 추가

raw/book/EssenceOfSoftware_Eng/ — Daniel Jackson (2021) 원본 11개 폴더 추가

wiki/sources/ EOS 챕터별 한국어 페이지 8개:
- EOS-overview: 전체 개요, 설계 3수준, 핵심 원칙
- EOS-part1: Ch1-3 동기 (Backblaze/Dropbox 사례, 개념 역할)
- EOS-ch4: 개념 구조 (5요소: 이름·목적·상태·행동·운영 원칙)
- EOS-ch5: 개념 목적 (좋은 목적 4기준, 미스피트 사례)
- EOS-ch6: 개념 조합 (동기화, 시너지, 과잉/과소 동기화)
- EOS-ch7: 개념 의존 (의존 다이어그램, 제네릭 개념)
- EOS-ch8: 개념 매핑 (다크 패턴, UI 매핑 딜레마)
- EOS-part3: 원칙 Ch9-11 (특정성·친숙성·무결성)

wiki/index.md Sources 섹션 EOS 8개 등록, wiki/log.md 기록

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

raw/book/EssenceOfSoftware_Eng/concepts-091-120/concepts-091-120.md

@@ -0,0 +1,478 @@
+*Staging*. e composition may bring together dierent stages of an activity. When making a call on a mobile phone, for example, the user may enter not the number to be called but the name of the person; a composition of the *contact* and *phone call* concepts then handles the looking up of the number and the placing of the call respectively. is kind of separation into stages allows features such as *call forwarding* to be treated as concepts. A similar paern arises in the browser request pipeline, which starts with a lookup using the *domain name* concept that translates a domain name to an IP address, which is then used by the *http* concept for the request itself.
+
+*Notication*. Most apps and services oer notications to users: calendars send reminders; help forums let you register to be notied of replies to a question you asked; online stores send acknowledgments of purchases; shipping companies send delivery updates; social media apps tell you when your friends have posted new content. All these can be done with a *notification* concept that oers an event tracking action that is synchronized with the actions of interest in the other concepts, and notication actions that follow spontaneously (and whose timing, medium, and frequency can oen be congured by the user).
+
+*Mitigation*. Sometimes, free composition gives too much latitude to users, leading to undesirable behaviors that can be mitigated by a collaborative composition. Many social media platforms, for example, compose a *post* concept with an *upvote* concept that lets users rate individual posts. If the *post* concept allows editing, this creates a dilemma, because a user might receive lots of positive upvotes for a post only to then change its content entirely, giving the misleading impression that the new content received all those approvals. One common x for this (used in Slack, for example) is to add an indelible marker to posts that have been edited. Another is to synchronize the *edit* action of the *post* concept with an action in another concept that undoes some of the approval. In YouTube, for example, a user can *pin* a favorable comment to a video of theirs. But if the comment is edited, it will be automatically unpinned, by a synchronization between the *comment.edit* and *pinning.unpin* actions.
+
+*Inference*. Sometimes a user's actions are not executed directly, but are inferred from other actions. Most communication apps distinguish between read and *unread* items, and allow users to toggle their status. But to mark an item as read for the rst time, an app typically synchronizes another action (such as opening the item, or scrolling through it) with the action that marks it as read.
+
+*Bridging separated concerns*. By separating concerns with free composition, concepts usually improve the clarity and usability of an app. On a mobile phone, for example, the *cellular* and *wifi* concepts let you manage your use of cellular data and local networks independently of each other, and of the apps that use the data. Sometimes, though, the need arises to couple concepts that have been separated. Apple's Podcasts app, for example, gives you the option of preventing a *podcast* from being downloaded using the cellular connection (and thus consuming data against your quota when you might instead have obtained it free through Wi-Fi).67
+
+### *Synergistic Composition*
+
+In free composition, a soware product is assembled from largely orthogonal concepts, each bringing its own functionality, with synchronization being used only for bookkeeping. In collaborative composition, synchronization creates connections between concepts that provide automation, and thus some new functionality that the individual concepts do not provide by themselves.
+
+In synergistic composition, something more subtle occurs. By synchronizing the concepts even more tightly, the functionality of one concept comes to enhance another concept's fulllment of its own purpose. e overall value of the composition is now more than the sum of the values of the concepts.
+
+To illustrate this phenomenon, suppose that, in the composition of the *todo* and *label* concepts, we were to represent the pending/done status of tasks with a built-in label *pending* that is axed automatically when a task is added and detached when the task is completed. is can be described with two synchronizations (Figure 6.7): one to ax the label when a task is added, and one to detach it when the task is marked as complete. For consistency, I've added a third synchronization that causes the task to be marked as complete when the label is axed.
+
+e advantage of this composition is that the label query functionality now incorporates whether tasks are pending or not. ere's a single uniform interface, and in a richer version of the *label* concept that oers a logical query language, you could ask for tasks that are "pending and urgent," for example. Moreover, the state component of the *todo* concept that remembers whether a task is pending or done is no longer necessary, since that information is now stored in labels.
+
+**app** todo-label-syn <sup>2</sup> **include** <sup>3</sup> todo label [todo.Task] **sync** todo.delete (t) label.clear (t) **sync** todo.add (t) label.affix (t, 'pending') **sync** todo.complete (t)
+
+- add delete complete affix detach find clear **todo label**
+- <sup>10</sup> label.detach (t, 'pending') <sup>11</sup> **sync** label.detach (t, 'pending') <sup>12</sup> todo.complete (t)
+
+fig. 6.7 *A synergistic composition of todo and label concepts.*
+
+is simplied seing can only hint at the benets that this kind of composition can bring. In the next section, we'll study an example that's more powerful but also surprisingly complicated, showing how subtle synergistic composition can be. Before that, some other examples of synergistic composition:
+
+*Gmail labels and trash*. Google's email app, Gmail, uses labels synergistically in exactly the way I just described. When an email message is sent, the label *sent* is axed to it automatically, and the buon labeled "sent" that opens a list of sent messages is simply bound to a query for messages carrying the *sent* label. e same idea is extended to the *trash*: deleting a message axes the *deleted* label to it, and removing that label restores the message.<sup>68</sup>
+
+*Moira lists and groups*. MIT uses a system developed internally in the 1980s called Moira for managing mailing lists. To let multiple users maintain a mailing list, you can create a second list of those users; that list can then be assigned as the owner of the rst list. To grant or withhold control, you can simply add or delete a user from the second list. is is a lovely synergy in which the *mailing list* concept is composed so thoroughly with an *administrative group* concept that the laer requires no interface of its own.69
+
+*Free samples and shopping carts*. Some online stores include in their shopping carts items such as a free samples (or catalogs, etc.) that have *not* been purchased by the user. is is a synergistic composition between the *shopping cart* concept and the *free sample* concept; the action that adds a free sample to the order is synchronized with the action that adds items to the shopping cart. is is good for the user (who sees all their items, including the free ones, in
+
+one place), and it makes things easier for the developer (eliminating the need to store the free samples separately). But, as with many synergies, unexpected snags can arise.<sup>70</sup>
+
+*Photoshop channels, masks and selections*. e preeminent example of synergy appears in Adobe Photoshop, in which the *mask*, *selection*, and *channel* concepts work together with remarkable power.71
+
+### *e Beautiful Synergy of Trash & Folder*
+
+You may have been surprised that when I introduced the *trash* concept in Chapter 4, I treated the trash as just a set of items. In the most familiar instances of the concept (on the Macintosh or Windows desktops), the trash is not a set of items but a *folder*.
+
+In some early versions of the concept, the trash *was* just a set, and if you deleted a folder, its contents were disaggregated and placed individually in the trash. Obviously this made restoring folders dicult, and the beer design (which Apple had used from the start) fused together the two concepts.<sup>72</sup>
+
+e modern design can be understood as a very skillful composition of these two distinct concepts, *trash* and *folder*. By viewing it in these terms, we can separate out the various aspects of behavior. To understand the essential idea of the trash—that items can be deleted and later restored, or permanently removed by emptying—you only need to know about the *trash* concept; to understand how the items in the trash appear, you only need to know about *folder*.
+
+e synergy this creates is evident in the parsimony of the user interface. No special actions are needed to list the items in the trash, since in this respect, it's just a regular folder, to which you can apply sorting, searching and so on in the regular way. Nor is a special control needed for restoring an item; you just move it out of the trash folder. And of course, the synergy is what allows the trash to retain the structure of a deleted folder so that it can be restored in one piece.
+
+e synchronization that makes this possible is not complicated. Moving a le to the trash (in the *folder* concept) is synchronized with deleting the le (in *trash*); moving a folder is synchronized with deleting all the folders and les it contains; and likewise, moving a folder out of the trash is synchronized with restoring all those folders and les.
+
+| • • •                    | Trash                                                                        | n              |                       |
+|--------------------------|------------------------------------------------------------------------------|----------------|-----------------------|
+|                          | <b>≅ ∨ ☆ ∨ ≡</b>                                                             | Q Search       |                       |
+| Trash                    | None                                                                         |                | Empty                 |
+| Weston                   | ✓ Volume                                                                     | fied           | Date Added            |
+| photos for dropbox examp | Kind Application Date Last Opened Date Added Date Modified Date Created Size | 018 at 2:23 PM | Yesterday at 1:31 PM  |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 7:20 PM  | Yesterday at 10:43 AM |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 7:20 PM  | Yesterday at 10:43 AM |
+| Screen Shot 202020 a     |                                                                              | at 10:40 AM    | Yesterday at 10:43 AM |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 3:28 PM  | Yesterday at 10:39 AM |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 3:28 PM  | Yesterday at 10:39 AM |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 3:29 PM  | Yesterday at 10:39 AM |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 3:30 PM  | Yesterday at 10:39 AM |
+| Screen Shot 2020-07-17 a |                                                                              | 20 at 3:33 PM  | Yesterday at 10:39 AM |
+
+fig. 6.8 *Synergistic composition of the trash and folder concepts. Items can be sorted by "date added," which corresponds to the date of deletion, elegantly reusing a general feature of folders. e sorting into volumes is a more troubled feature, since it applies only to the trash folder.*
+
+### *Synergies Are Rarely Perfect*
+
+Perfect merging of functionality across concepts is rarely possible, and so most synergies have some costs. e trash is not quite a folder like any other; most obviously, it needs to oer the *empty* action, hence the lile buon that appears in that folder alone.
+
+e designers of the Macintosh trash have tried their best to minimize such non-uniformities. ey resisted, for example, including a "date deleted" eld, which would have only applied to the trash folder, but cleverly included a "date added" eld, which works for all folders, and for the trash happens to allow sorting by deletion date.
+
+More troublingly, in the Macintosh desktop, there is only *one* trash folder, even if there are multiple drives. Unlike any other folder therefore, the trash can "hold" items from dierent volumes; to make this clear, recent versions of macOS allow the items in the trash to be grouped by volume, a feature not available for other folders (Figure 6.8).
+
+Representing the trash as a folder can be confusing at times: hence the uncertainty in my saying that the trash can "hold" items. In Chapter 5, I mentioned the scenario in which you insert a removable drive into your laptop, and move some items from it to the trash folder in the hope of making space on the drive. Since there is only one trash folder, and it "belongs" to your laptop, you might imagine that this action would free up space on the drive.
+
+But, as the division of the trash into volumes indicates, the trash folder no more belongs to the machine than to the external drive, and moving a le to the trash never frees up space. If you eject the external drive, you will see its trashed items disappear from the trash folder, and reappear when you reaach it.73
+
+### *Synchronizing Too Much and Too Lile*
+
+When you compose concepts, the synchronizations become an important part of the overall product design. Synchronizing too much takes control away from the user, preventing some scenarios that would have been allowed in a free composition. Synchronizing too lile, conversely, burdens the user with work that might have been automated. It can also admit unexpected and undesirable behaviors, sometimes with catastrophic consequences.
+
+### *Over-Synchronization & e Strange Case of e Canceled Seminars*
+
+In Apple's Calendar app, the *calendar event* concept that supports the storing of events at given times is composed with an *invitation* concept so that one user can send another a tentative event, which the second user can accept or decline.
+
+In the original design, deleting an invitation event presented users with a quandary. e *delete* action was unhelpfully coupled with the *decline* action, so you could not delete the event without notifying the issuer of the invitation that you were declining it. is was bad enough if you simply wanted to clear space in your calendar without oending a friend. It was far worse if the invitation were spam. In that case, the notication would aid the spammer, conrming your email address as valid and increasing the likelihood of future spam!
+
+For many years, a clunky workaround was the only way out: to create a new calendar, move the event to it, and then delete the new calendar in its entirety. Eventually (sometime in 2017), Apple uncoupled the delete and notify actions (Figure 6.9).
+
+e very same design aw, but in Google Calendar, turned out to be the source of a puzzling problem that my lab had with seminar announcements. Oen a seminar cancellation would be sent shortly aer the initial announcement. e organizer would then send a follow-up, reassuring people that the seminar had not in fact been canceled. It turned out that the cancellations were spurious. Individuals in the lab were receiving notications of research seminars, and adding them as events in their personal calendars. en when
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_6_Picture_1.jpeg)
+
+fig. 6.9 *e original Apple Calendar dialog that unhelpfully always synchronized deleting an event with notifying the sender (le), and the most recent version (right) that xes the problem by making the synchronization optional.* 
+
+someone deleted such an event, a cancellation message was sent spontaneously by Google Calendar to the email address associated with the initial invitation—which in this case was a listserv with more than a thousand members!
+
+Some other examples of over-synchronization:
+
+*Tumblr's questionable design*. In the Tumblr blogging platform, if you wanted to allow people to comment on your post you could insert a question mark at the end of the post's title. In this kind of synchronization, whether one action (here, creating a *post*) produces an accompanying action (enabling *comment*s) depends on the exact *content* of the arguments to the rst action. is is not only an unwelcome synchronization—what if your title were a rhetorical question?—but also makes the *title* concept no longer generic (see "Concepts are generic" in Note 48) and thus harder to understand. Later, Tumblr made it possible to check a box instead.
+
+*Replies in Twier*. A similar issue arose in Twier. Until mid-2016, a *tweet* that began with a username was interpreted to be a reply. is led, amongst other things, to a convention in which people wanting to mention someone else at the start of a tweet, but not to make it a reply, would insert a period before the name ("*.@daniel Really?*").
+
+*An unwanted Google synchronization*. If you have a Google account whose *username* is an external *email address*, and you add Gmail functionality to the account, your username will be automatically changed to match the new Gmail
+
+email address, and you will not be able to reinstate the old username and email address!<sup>74</sup>
+
+*Epson's tyrannical printer driver*. In its photo printers, Epson understandably wants to prevent users from making certain combinations of seings that might damage the printer. For example, it seems reasonable that you should not be able to select "thick" for the *paper option* along with a *paper source* seing that feeds paper from the top (which requires it to bend as it enters the printer). But the printer driver goes further, and prevents you, when selecting the top feed, from using most of the ne art paper seings, presumably on the grounds that these seings only apply to thick papers. is is wrong, however; many ne art papers are thin and exible, and this constraint forces you either to feed such papers through the front (which is much less convenient since each sheet must be manually loaded), or to feed them through the top, but to print with incorrect ink seings.
+
+### *Under-synchronization and a Group at Could Never Be Joined*
+
+A year or so ago, I wanted to create an online forum for neighborhood discussions, so I set up a Google Group for the purpose. Since I did not know in advance the user names of my neighbors, I sent them a link to the group, suggesting that they request to join.
+
+Unfortunately, this did not work, and people were unable to even access the page with the ask-to-join buon. I thought I'd set the group up correctly; in particular, under "permissions" (Figure 6.10, top) in response to "Select who can join," I'd chosen "Anyone can ask."
+
+It turned out there was a dierent seing that determined whether the group appeared in a directory of groups (Figure 6.10, boom). Unless the visibility of this feature was set to "Anyone on the web," the group was not only excluded from the directory but was not accessible at all, even for join requests!
+
+e lack of a synchronization between the action that determines who can join (in the *permission* concept) and the action that sets visibility (in the *group directory* concept) got me into this mess. Since then, Google has tweaked the design. Both controls are placed on the same page (Figure 6.11), but they're still not synchronized, so selecting "Anyone can join" for "Who can join?" won't work unless you also change "Who can see group?" from the default seing to select "Anyone on the web."
+
+| ▼ Permissions                      |                 |                                                                                     |
+|------------------------------------|-----------------|-------------------------------------------------------------------------------------|
+| Basic permissions                  | View topics     | Select groups of users ▼ ✓ All members of the group                                 |
+| Posting permissions                |                 | These was an view tonics in this around if was a superious travible about           |
+| Moderation permissions             |                 | These users can view topics in this group. If users experience trouble, check y     |
+| Access permissions                 |                 |                                                                                     |
+| ▶ Roles                            | Post            | Select groups of users   All members of the group                                   |
+| ▼ Information  General information |                 | These users can post messages to this group.                                        |
+| Directory                          | Join the group  |                                                                                     |
+| Content control                    | Join the group  | Select who can join  Anyone can ask                                                 |
+| Web view customization<br>Advanced |                 |                                                                                     |
+| ▼ Information                      | Group directory |                                                                                     |
+| General information                | Group directory | All members of the group ▼                                                          |
+| Directory                          |                 | Listing a group in the directory will make it easier for people to find your group. |
+| Content control                    |                 | Louing a group in the ansolery will make it easier for people to find your group.   |
+| Web view customization             |                 |                                                                                     |
+| Advanced                           |                 |                                                                                     |
+
+fig. 6.10 *Access controls for Google Groups (2019). Top, the options shown if you click on "Basic Permissions" in the "Permissions" tab; boom, the options shown if you click on "Directory" in the "Information" tab. With the default seing of "Directory," the permission seing was ineffectual, since the page displaying the ask-to-join buon was private to members!* 
+
+### Some other examples of under-synchronization:
+
+*Lightroom import*. Adobe's photo cataloging and editing app, Lightroom Classic, oers a rich importing mechanism that not only copies photos from a card or camera to your hard drive, but can perform an array of additional tasks, such as: moving the copied photos to a preferred location; adding copyright information to the metadata; applying development seings to every photo; adding keywords; building previews; and ejecting the external drive or ash card holding the originals. All of these synchronizations were optional, and were controlled by preferences in a fairly complicated user interface dialog.
+
+In 2015, the Adobe team released version 6.2 of Lightroom, which included a simplication of the import dialog, removing some of the synchronizations that expert photographers had come to rely on. e reaction from users was so fast and so negative that Adobe actually reverted the update.75
+
+*Google Forms, Sheets, and data visualization*. In a lovely example of synergy, Google Forms use Google Sheets, Google's spreadsheet app, as the repository for data collected. e Forms app also includes a nice visualizer that generates pie charts, histograms, and so on to summarize the data. Unfortunately, the visualization is synchronized with a *dierent* copy of the data, distinct from the sheet. As a result, edits to the sheet (for example, data cleaning such as removing duplicate form submissions) are *not* reected in the visualization.76
+
+| Who can see group         |   |
+|---------------------------|---|
+| Group members             | ~ |
+| Who can join group        |   |
+| Anyone on the web can ask | • |
+
+fig. 6.11 *A more recent version of Google Group permissions (February 2021), which helpfully consolidates the permissions for viewing into a single seing, and places it on the same page as the permissions for joining. Unfortunately the default is as shown, and asking to join requires being able to see the group.* 
+
+*Zoom's sticky hands*. In the Zoom video-conferencing app, a participant can raise a virtual hand to signal to the host a desire to speak. While not talking, participants typically mute their microphones to reduce background noise. en when called on, a participant unmutes, makes a point, and mutes again. But most participants forget their raised hands, confusing the host who, noticing a raised hand later, is uncertain whether that person just forgot to lower it, or wants to speak again. Synchronizing the *raised hand* and *audio mute* concepts might eliminate this annoyance.77
+
+*erac 25 radiotherapy machine*. A series of catastrophic accidents with a radiotherapy machine in the late 1980s was eventually traced to a synchronization aw. e source of the radiation was an adjustable electron beam that through either (a) a magnetic collimator to focus the electrons, or (b) a aening lter that converted the electrons to X-ray photons (depending on the position of a rotating turntable).
+
+Patients were irradiated in one of two modes: either directly with electrons or with X-rays. e X-ray production required a high electron current—far more than could ever safely be administered directly. e intent, therefore, was to ensure that the aening lter was in place whenever the electron beam current was high. Tragically, a aw in the synchronization mechanism sometimes resulted in the high current being delivered directly to patients, resulting in massive, fatal overdoses. Although the aw has been aributed to a programming error—a bug in the code that failed to ensure the intended synchronization—a beer design might have prevented it.<sup>78</sup>
+
+### *Lessons & Practices*
+
+### Some lessons from this chapter:
+
+- · Concepts are not composed like programs, with larger concepts subsuming smaller ones. Instead, each concept is exposed to the user on equal terms, and a soware app or system is a collection of concepts running in tandem.
+- · Concepts are composed by synchronizing their actions. is never adds new concept executions, but constrains existing ones, eliminating some sequences of actions that would have been possible for a concept in isolation.
+- · In free composition, concepts operate independently of one another, constrained only by some bookkeeping to ensure (for example) that concepts have a consistent view of which things exist.
+- · In collaborative composition, concepts work together to provide new functionality through automation.
+- · In synergistic composition, the concepts are yet more tightly intertwined, with one concept's functionality helping another concept fulll its purpose.
+- · Composition oers an opportunity for creative design even when the concepts themselves are familiar. Synergy is oen the very essence of a design, bringing unexpected power from the combination of simple parts.
+- · Synchronization is an essential part of soware design. Not enough synchronization can lead to inappropriate or confusing behaviors, and miss opportunities for automation; too much can limit the user's options.
+
+### And some practices you can apply now:
+
+- · If a concept you're designing seems complicated, try thinking of it instead as a composition of simpler concepts, which may be easier to describe and justify (by having a clearer purpose and more compelling operational principle). (More on this in Chapter 9.)
+- · When picking concepts, be on the lookout for familiar concepts to reuse (Chapter 10). For example, you might identify a *notification* concept and then see ways to use notications more uniformly throughout your app.
+- · In design, decide rst which concepts to include, and then how they to synchronize them. Start with synchronizations to remove bad behaviors. en consider automations, but make sure to leave enough exibility to the user.
+- · Look for synergies in which you can simplify a concept by composing it with another. But remember that perfect synergy is rarely aainable.
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+# Concept Dependence
+
+When concepts are composed, they play specic roles in their relationships to one another. For example, when we bring together *label* and *todo* so the user can aach labels to todo tasks, the *todo* concept becomes a kind of subject to which the *label* concept is applied.
+
+e composition itself is symmetrical, because synchronization treats synchronized actions as equals. Nevertheless, composition can introduce an asymmetry in the way in which one concept augments the functionality of another. e *label* concept extends the functionality of the *todo* concept: now, in addition to adding tasks, we can label them. e converse would make no sense: nobody would start by building an app for labeling things, and then extend it with tasks that can be labeled.
+
+ese asymmetries reveal important structure in a soware product, which this chapter explores. I'll explain a *dependence* notion amongst concepts that can be depicted in a simple diagram, which oers a helpful summary of the concepts and their roles.
+
+It may seem paradoxical to introduce a notion of dependence when I have insisted that concepts are mutually independent. ere is in fact no paradox here. e very essence of concepts is indeed that they can be understood and implemented in isolation. e dependencies discussed in this chapter arise from the role that concepts play in the context of the product as a whole, and is more a property of the product than of the concepts it contains.
+
+### *Growing a Soware Product Concept by Concept*
+
+Some soware products must emerge from the womb fully grown. An aircra or nuclear power station cannot be deployed with soware that is only a "minimum viable product," with a plan to adjust the soware as needs arise.
+
+But in most cases an incremental development is beer, because it allows the developers to get early feedback on their design work, assess the value of
+
+the work already deployed, and handle mists as they are discovered. So it's useful to think about designing a new soware product as *growing* it, a few concepts at a time.
+
+Not all growth involves the addition of concepts. Sometimes a concept will be removed, perhaps because it is found to be less useful than expected, or because it has some critical aw that is not easily remedied, or because its functionality can be subsumed by extending another concept. Sometimes the existing concepts will be rened and polished, ideally becoming not only more powerful but also more compelling (in their purposes and operational principles). And sometimes—the most exciting case—a synergy is discovered (with or without the addition of a concept) that extends the product's capabilities without a concomitant increase in complexity.
+
+Unbridled growth can be the downfall of excellent products. Ambitious redesigns of small but successful systems are especially subject to what Fred Brooks, an inuential IBM manager, called "the second-system eect" in which overcondence leads to bloated and needlessly complex solutions.<sup>79</sup>
+
+For all these reasons, it's useful to be able to represent succinctly the possible growth of a soware product, and—equally importantly—the ways in which it may be trimmed back. is is what the concept dependence diagram provides.
+
+### *Building the Concept Inventory*
+
+I mentioned in Chapter 3 how concepts can give you a map of an application—a kind of concept inventory that gives you an overview of its functionality and purposes. Let's see how this map comes about, using an imaginary app as an illustration.
+
+roughout, I'll discuss it as if you were designing the app alone; of course, in practice, most design work is done in teams. I'll also talk only about which concepts to include, ignoring all the critical questions about the actual design of the concepts.
+
+Suppose you love bird song, and want to build an app to help people identify birds from their calls. at's the essential need: someone hears a bird call and wants to know what kind of bird it came from. And presumably people who want this also want to hear the song of a particular bird species.
+
+You think about how such an app might work. Maybe a user uploads an audio track, then other people listen to it and make suggestions. Now you start
+
+### 7: concept Dependence
+
+brainstorming some concepts. Before inventing a new one, you try some existing ones for t. How about the *q&a* concept used in forums (such as StackExchange, Quora, Piazza, and so on), in which someone asks a question and other people provide answers?
+
+In fact, you might ask, why not just use one of those existing apps? Oen that will be the best approach to solving a problem. To make sure that it isn't, you'll want to note some limitations of the existing solutions and check that they really maer. Perhaps in this case you discover that none of them let you easily upload and playback audio recordings; maybe it's important to have a nice integration so you can record a song and post it in a few clicks.
+
+So now let's suppose you've convinced yourself you need to design a new app, and you have some *seed concepts*, such as *q&a* and *recording*. What additional concepts are necessary to make a coherent app? Obviously, since you're relying on crowdsourcing, you'll want some concept for achieving consensus, so you might add *upvote* so that users can approve an answer.
+
+As you brainstorm how your app will be used, you realize that you'll need to somehow consolidate the bird identications. Users will likely want to search for particular species, and listen to recordings for which there are conrmed matches. So you tentatively add an *identification* concept, unsure of exactly how it will work. Perhaps when a user answers a question, they can propose an identication by inserting a hashtag, and your app will automatically extract links between species and recordings from the upvoting of answers.80 Finally, you decide to add *user* to authenticate contributions. At this point, you have the rough outline of an app: BirdSong 0.1.
+
+### *An Inventory of Generic Concepts*
+
+e concepts we have so far, along with their purposes, are:
+
+- · *q&a*: support community response to questions
+- · *recording*: allow upload of audio les
+- · *upvote*: rank contributions based on individual (dis)approvals
+- · *identification*: support crowdsourced assignment of objects to categories
+- · *user*: authenticate content and actions
+
+Note that each concept has been given a generic purpose. Of course, in the context of the articular app, each concept will be specialized. For BirdSong 0.1, the questions will be about bird calls; the audio les will contain bird songs;
+
+the contributions that are upvoted will be proposed answers or identications. Even the *identification* concept, which might have seemed to be very bird-specific, has been cast in more general terms, in the hope that this will make it easier to draw inspiration and lessons from related concepts (such as *tag* in Facebook).
+
+Making the concepts generic not only makes the reuse of design knowledge from previous applications possible. It also helps simplify the design. e less bird-specic any concept is, the easier it will be to understand. Maybe you're tempted, for example, to include in the *identification* concept whether the bird is male or female. A priori, however, this is a bad idea: until you have more experience and understanding of the app and how it will be used, there's no reason to believe that including this distinction (rather than just treating the male and female as separate birds) is any more important than any other. If you wanted to associate dierent birds, a more plausible start would be to enrich the *identification* concept with a notion of birds being *related*; this could then accommodate not only distinctions of gender, but other variants within a species.
+
+### *e Concept Dependence Diagram*
+
+Because each concept is generic and freestanding, there are no concept-to-concept dependencies in the traditional soware engineering sense. But there is a dierent kind of dependence between concepts, related not to the concepts themselves but to their role in the application as a whole.81
+
+Take the *upvote* concept. Clearly, there's no point having this concept in the app unless there is something to upvote! Presumably, what's being upvoted is an answer to a question ("at's a #sparrow singing").82
+
+So we'll say that *upvote* "depends" on *q&a*, because if the *q&a* concept were missing, there would be no reason to include the *upvote* concept. Collecting together all such dependencies gives the diagram of Figure 7.1.
+
+Sometimes a concept's presence may be justied by any of several other concepts. In that case, we'll mark one of the dependencies as the primary dependence (with a solid line), and the others as secondary (with doed lines). A secondary dependence represents additional, but less compelling, reasons to include a concept.
+
+us *user* has a primary dependence on *q&a*, because the main reason for including user authentication is to ensure that questions and answers can be
+
+### 7: concept Dependence
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_16_Figure_1.jpeg)
+
+fig. 7.1 *Concept dependencies for a bird song app. A solid arrow denotes a primary dependence and a dashed arrow a secondary dependence. e core concepts are in bold.* 
+
+reliably associated with individuals; and a secondary dependence on *upvote*, because the authentication could be used to prevent double voting too. e second usage is less essential; we could use IP addresses or browser IDs for that purpose instead.
+
+e diagram tells us which concepts are core to the app and which could be omied. Because every concept depends directly or indirectly on *q&a*, an app can't exist without it—if it includes any of these concepts, it must include this one. But it could exist alone, with no other concept to augment the functionality. is would admiedly be a rather feeble app: lacking *user* means no authentication; lacking *upvote* means no crowdsourcing; and lacking *recording* means that questions would have to describe songs in words, or perhaps link to les elsewhere on the web.
+
+Any subset of the concepts can comprise a consistent app, so long as there are no dependence edges pointing out of that subset. So *q&a*, *recording* and *upvote*, for example, make an app. In contrast, *identification* and *q&a* do not make an app, because *identification* depends on *recording*. In the context of our app, the *identification* concept provides reverse lookup: given a particular identication, it leads the user to the relevant bird songs. Without *recording*, this role cannot be fullled.83
+
+e diagram therefore describes not just one app, but a whole family comprising all the apps that could be built from these particular concepts—what soware developers would call a "product line." Each consistent subset represents an app that might be built.
+
+e subsets can also represent stages of development. At any point in the development, you'd like to have a consistent subset implemented in order to be
+
+<span id="page-17-0"></span>![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_17_Figure_1.jpeg)
+
+fig. 7.2 *Concept dependencies for Facebook (le) and Apple Safari (right).* 
+
+able to evaluate it as a coherent unit. If you implemented a set that included *upvote* but not *q&a* you'd have trouble making a compelling demo or test, because there would be nothing to upvote.
+
+Finally, the diagram provides an *explanation order*. You can't explain an app all at once, so you explain the concepts in order, one or two at a time. But what orders make sense? Dependencies tell us how to avoid introducing a concept before it can be motivated. So if we were explaining our bird song app to a novice user, this order would make sense
+
+*q&a*, *upvote*, *user*, *recording*, *identification*
+
+but this would not
+
+*upvote*, *q&a*, *user*, *identification*, *recording*
+
+because it introduces *upvote* before *q&a*, and you can't explain upvoting without something to upvote (just as you can't demo it).
+
+### *e Structure of Some Familiar Apps*
+
+To illustrate the concept dependence diagram further, and how it can provide insight into designs, let's look at the structure of some familiar apps.
+
+*Facebook*. Figure 7.2 (le) shows the key concepts of Facebook and their relationships. e base concept, of course, is *post*. Comments are on posts, so the *comment* concept depends on the *post* concept. e *reply* concept oers threaded conversations about comments. e *user* concept oers authentication for posts primarily, but also for comments, replies, tags and likes.
+
+e *friend* concept is interesting; since its purpose is to allow users to control access to their posts, it depends not only on *user* but also on *post*. e *tag* concept
+
+### 7: concept Dependence
+
+<span id="page-18-0"></span>![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_18_Figure_1.jpeg)
+
+fig. 7.3 *Concept dependencies for Apple Keynote.* 
+
+involves identifying users that appear in posts, so it depends on *user* and *post*. Finally, the *like* concept depends primarily on *post*, but is also used for comments and replies.<sup>84</sup>
+
+*Safari*. [Figure 7.2 \(right\)](#page-17-0) shows the key concepts of Apple's Safari browser. As you'd expect, *url* is the base concept; for easier layout, I've put it in the middle rather than at the boom. e *url* concept embodies the idea that resources (namely web pages) can be obtained by sending requests to servers with persistent names (namely, uniform resource locators). e *html* concept allows these resources to be marked-up pages, but most of the browser concepts are not dependent on this and could still be used in a browser (admiedly, a rather feeble one) that does not include HTML rendering. e *cache* concept depends only on the *url* concept; it helps the browser run faster by storing the resources returned by previous requests to a given URL. e *certificate* concept makes sure that the server the browser talks to really corresponds to the domain name in the URL, and so depends only on the *url* concept. e *private browsing* concept oers a mode in which cookies are not sent to servers, safeguarding the user's identity, so it depends on *cookie*.
+
+At the top of the Safari diagram is the *bookmark* concept and three variants of it: *favorite*, which, like *bookmark*, allows you to save URLs to visit later, but displays these URLs in the toolbar and on every new tab you open; *frequently visited*
+
+which creates bookmarks spontaneously from sites you've visited many times; and *reading list*, which is also just like a bookmark, but tracks whether a page has been read (and also downloads the page for oine reading). e proliferation of these very similar concepts, and the subtle dierences between them, suggests an opportunity for more synergistic design. e ability to access pages of ine and mark pages as read could be added to all bookmarks. And frequently visited sites, like favorites, could be added as a special folder within the regular bookmarks so that they could be deleted if unwanted.<sup>85</sup>
+
+*Keynote*. [Figure 7.3](#page-18-0) shows the key concepts of Apple's slide presentation app, Keynote. As you'd expect, the *slide* concept sits at the base. e *special block* concept generalizes the title, body, and slide number which appear optionally on each slide, and are given default formats in *master* slides. e *theme* concept allows a collection of masters to be shared across presentations (for consistency and ease of use), and naturally augments the *text style* concept (by playing the role of a *stylesheet* concept that brings together a collection of styles for reuse across documents).
+
+In addition to the *special block* concept, there is a separate concept of a *text block*, as well as a *shape* (which can also hold text, but does not expand automatically to t the content). Text is always broken up by *paragraph*. ere are two instances of the standard *style* concept, one for text in paragraphs and one for shapes. e *layer* concept supports stacking of shapes and text blocks (with the "send to back" and "bring to front" actions). e *animation* concept primarily supports progressive reveal of points in special blocks, but can also sequence the appearance of shapes and text blocks.86
+
+### *Lessons & Practices*
+
+Some lessons from this chapter:
+
+- · Concepts are freestanding, and independent of one another: a concept can be understood, designed and implemented by itself. is independence is key to the simplicity and reusability of concepts.
+- · In the context of a soware product, dependencies arise—not that one concept relies on another for its correct operation, but because inclusion of one concept may make sense only if another is present.
+
+### 7: concept Dependence
+
+· e dependence diagram gives a succinct summary of a product's concepts and the motivations for including them. It helps plan the order of design and construction, identify subsets, and structure explanations.
+
+And some practices you can apply now:
+
+- · When you are designing an app, think about growing it one or two concepts at a time. At the start, identify a few seed concepts that will form the basis for all subsequent growth.
+- · Draw a dependence diagram to get a succinct view of the concepts in your app and their relationships. Each time you add a concept to your design, think carefully about which concepts it depends on: more is generally beer, because it means the concept is used more extensively.
+- · When considering what order to prototype or build the concepts in, refer to the dependence diagram, so that at any point you have a coherent subset.
+- · To explore ways in which an app might be simplied, evaluate the consistent subsets and estimate how much value each brings. Perhaps there is a subset that brings most of the value for only a small part of the cost.
+- · When writing a user manual or developing training materials, use the ordering dened by the dependence diagram to present concepts in the most e cient and rational sequence.
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+## Concept Mapping
+
+You can think of the concepts of an app as running in the background, behind the user interface. e interface provides buons to activate the actions of the concepts, and visualizations of the concept states. So when a user clicks on the "like" buon of a social media post, an action of the form *upvote.like(u,p)* is activated, telling the *upvote* concept through its *like* action that user *u* approves of post *p*. e result of this action—a change in the state of the *upvote* concept—is then reected in the updated count of likes displayed to the user.
+
+Creating a user interface involves more than visual design; its essence is the design of a *mapping* from the underlying concepts to their material form in the interface. e interface designer shapes this mapping, usually by creating multiple screens and dialogs, connected by ows and links, and then embedding within them controls and views that connect to the concepts actions and states.
+
+e design of mappings has been extensively studied by human-computer interaction researchers, and the guidelines that have been developed—mostly at the physical and linguistic levels of design—apply equally well to systems that have been designed with concepts.37
+
+But concepts oer a chance to rene (and maybe even rethink) the relationship between the conceptual level of design and the physical and linguistic levels. So this chapter focuses on examples that illustrate how tricky and intricate mapping design can be, and how deeply it must be informed by the underlying concepts.
+
+### *How to Make a Simple Concept Hard*
+
+Even if the underlying concept is simple, it's still possible to design a mapping that makes it hard to use. Last week, a message popped up on my desktop asking me if I wanted to upgrade to the latest version of Oracle Java. I clicked yes. When I ran the installer, it displayed a dialog with two buons, one labeled "Install" and the other "Remove" (Figure 8.1).
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_23_Picture_1.jpeg)
+
+fig. 8.1 *A puzzling dialog in a Java installation process. What does "remove" mean?* 
+
+Now you might imagine there was no room for confusion here, and yet I still managed to confuse myself. Presumably the install buon invokes the action that installs the new version of the soware. But what does the remove button do? Apparently, it removes whatever version I have currently installed, and then does nothing.
+
+ese might seem like reasonable interpretations; aer all, that's prey much what the words "install" and "remove" mean. So why was I confused? Well, for one, I had just just downloaded and run the installer in response to a prompt to upgrade, so it's unlikely that my goal was solely to remove the old version. Furthermore, many installers give you the option of either removing the old version, replacing it with the new one, or just installing the new one so that you have a choice of which version to run. Since the remove buon was highlighted as the default, that seemed to be the most likely interpretation.
+
+Perhaps the designer of this dialog was aware of this confusion, and that's why it includes what Don Norman would call a "user manual": the wordy explanation that includes a sentence telling you what install and remove do.
+
+What might have been done instead? First, we might note that the *install* concept has two distinct operational principles, one in which you install and use an app, and another in which you uninstall it and reclaim the space. If the intent were to support both of these, they might have been oered as separate workows, perhaps in separate tabs (and with the installer shown as the default, especially when following a prompt to upgrade). Second, removing an
+
+### 8: concept Mapping
+
+<span id="page-24-0"></span>![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_24_Figure_1.jpeg)
+
+fig. 8.2 *e petition owner's view of a change.org petition reveals a small deception: signers are shown a lower count (the 683 on the right in the body of the petition) than the actual count visible to the owner (the 698 in the admin bar at the top le).* 
+
+old version to replace it with a new one is very dierent from uninstalling. e former could be presented as an option ("remove old version?") next to the "install" buon; the laer might be labeled "uninstall" rather than "remove."
+
+Anyway, poor reader, I suspect you've heard enough of this unremarkable example. Suce it to say that conceptual issues lurk, even behind a dialog box with only two buons labeled with common English words.
+
+### *Including a User Manual in the Interface*
+
+Sometimes a concept is suciently complicated that even the best designer will not be able to convey the meanings of actions or states without some additional explanation. In Chapter 2, I described how the Backblaze message "You are backed up as of: Today, 1:05 pm" was misleading due to the complexity of its *backup* concept.
+
+It didn't mean that any le saved before 1:05 pm was safely backed up. To counter this interpretation, I might reword the message to "Last backup: Today, 1:05pm," and include a sentence underneath saying something like "is backup included all les saved prior to the scan that began at 12:48pm." Alternatively, and more conservatively, I might instead display the message "You are
+
+<span id="page-25-0"></span>![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_25_Picture_1.jpeg)
+
+fig. 8.3 *An invitation to support a change.org petition. Or is it?* 
+
+backed up as of: Today, 12:48pm," and append below "is backup was completed at 1:05pm."
+
+is is the approach Apple takes in the dialog for its *do not disturb* concept. Below the checkbox for "allow repeated calls," whose interpretation is far from obvious, a comment in a smaller gray font adds: "When enabled, a second call from the same person within three minutes will not be silenced."
+
+### *Dark Paerns: Intentional Obfuscations*
+
+A company can nudge users to behave contrary to their interests, performing one action over another, or not performing an action at all. Oen this is done with a mapping that intentionally (and maliciously) obfuscates the underlying concepts.87
+
+e petition site, change.org, contains several such obfuscations. A few years ago, I created a petition to persuade our mayor not to locate a new city building in the middle of a local park. I noticed that every time I viewed my own petition ([Figure 8.2\)](#page-24-0), the number of signers seemed to be growing second by second, with the count rising as I watched.
+
+en I realized that, since I was the owner of the petition, a count in the top le of the screen, shown only to me, revealed the actual number of supporters. If I waited, aer a few seconds the growing count would always shoulder o at that actual number. Every time the petition is displayed, the count starts below
+
+### 8: concept Mapping
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_26_Figure_1.jpeg)
+
+fig. 8.4 *Two buons, one stacked above the other (and colored yellow and blue on the site itself), for apparently distinct actions of the Amazon Prime concept, but actually both bound to the same action.* 
+
+the actual number, and then immediately starts rising, giving a false impression of real-time activity.
+
+More insidiously, aer you sign a petition, you get a request to make a donation ([Figure 8.3\)](#page-25-0). Most people assume, quite reasonably, that this *donation* concept is synchronized with the *petition* concept in a particular way: that their donation is being passed to the petition organizer to help them fund their cause. In fact, the money pays for advertising on change.org (whose domain extension is misleading too: it is *not* a nonprot). In the case of my own petition, supporters contributed over \$2,000 to change.org. Had I understood the operational principle of "chipping in," I would have warned my signers against it.
+
+Sometimes, a mapping obfuscates which action will occur when a buon is pressed. On Amazon's UK website, I was oered a chance to sign up for a free trial of Amazon Prime, and presented with what seemed like two buons: a yellow buon labeled "Try Prime FREE" and a blue buon below it whose label began with the word "Continue" (Figure 8.4), suggesting it might mean "continue without Prime." In fact, the full buon label reads: "Continue with FREE One-Day Delivery." at is, *both* buons activate the *signup* action! e option to continue *without* signing up is provided by clicking on the much less prominent blue link to the le of the buon.
+
+A mapping may control your behavior simply by withholding important information or making it hard to access. Many airlines, for example, make it hard to nd the expiry date on your frequent yer miles, hoping that they will expire
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_27_Picture_1.jpeg)
+
+fig. 8.5 *Labeling in Gmail: a conversation with two labels, "hacking" and "meetups."* 
+
+before you realize. (is is just one respect in which the *frequent flyer* concept oen seems to be designed counter to the interests of yers.) Likewise, PayPal has been accused of hiding users' account balances, which—combined with the lack of a synchronization that automatically transfers received funds to an external bank account—maximizes the balances that users maintain at their expense (and PayPal's prot).
+
+### *Mapping Complex Compositions: e Mysteries of Gmail Labels*
+
+Google's email service, Gmail, provides the concept of *label* for organizing messages. For example, you might dene a label *hacking* and ax it to messages in which you discuss programming with your geek friends. en if you want to nd an earlier message that you remembered was about programming, you could lter on that label.
+
+is is a nice example of synergistic composition that I mentioned before (in Chapter 6). By using special "system labels" for sent and deleted messages, the *label* concept unies all kinds of lookups. e buon labeled "Sent" that takes you to a view of sent messages, for example, simply invokes a label query on the *sent* label.
+
+Gmail also provides the concept of *conversation*. Its purpose is to group together the messages associated with a particular thread of discussion, so that you can see a message, its reply, the reply to the reply, and so on, together.
+
+Composing and mapping these concepts together is challenging. e designers of Gmail chose to *ax* labels only to messages, but to *show* labels on conversations. is leads to some strange anomalies. In Figure 8.5, a conversation appears to carry two labels, *hacking* and *meetups*. And sure enough, if you lter on either label separately, that conversation appears. But if you lter on *both* labels, the conversation does not show (Figure 8.6).
+
+Although surprising, this is not a bug. e labels shown against a conversation are the accumulated labels of all the messages it contains. In this case, one message in the conversation has the label *hacking* and another has the label
+
+### 8: concept Mapping
+
+| Q label:hacking               |                               |
+|-------------------------------|-------------------------------|
+| □ - C :                       |                               |
+| ☐ ☆ Alyssa, me 3              | Inbox meetups javascript      |
+| Q label:meetups               |                               |
+| □ - C :                       |                               |
+| Alyssa, me 3                  | Inbox hacking javascript      |
+| Q label:hacking label:meetups |                               |
+| □ - G :                       |                               |
+| Q No                          | messages matched your search. |
+
+fig. 8.6 *A label ltering surprise in Gmail: a conversation seems to match both the "hacking" and "meetups" labels, but is not shown if you query for both of them.* 
+
+*meetups*. So the conversation is shown as having both labels. But since no *single* message carries both labels, ltering on the two together yields no results.
+
+You may wonder how dierent messages in a conversation could end up with dierent labels. When you select a conversation and add a label, it gets added to every message in the conversation. But you can dene rules that ax labels to incoming messages based on their contents. And when you add a label to a conversation, it only aects the messages currently belonging to the conversation; messages added later do not automatically inherit the label. Moreover, some labels (such as the *sent* label) are applied automatically to individual messages.
+
+In practice, the most troubling consequence of this design is more mundane: when you lter on a label, you get all the conversations containing messages with that label, but you can't tell which particular messages within a conversation actually carry the label.88
+
+When you click on *sent* in Gmail to see the messages you've sent, for example, you get a list of *conversations* in which the sent messages are embedded, which includes messages that were not sent by you. e designers of Gmail mitigated this problem by showing the sent messages expanded by default and the rest compacted (Figure 8.7). But this distinction is not always easy to see.<sup>88</sup>
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-091-120/_page_29_Picture_1.jpeg)
+
+fig. 8.7 *Filtering on sent messages in Gmail: the sent message is the rst of the two.* 
+
+Worse, this default-expansion strategy appears to be applied only to sent messages. In other cases, all messages in a conversation are compacted except for the most recent message. is discrepancy is evidence that Gmail's designers are aware of this problem but have not yet solved it.89
+
+### *Understandable but Unusable: Backblaze Restore*
+
+In all the examples we've seen so far, the problem has been a lack of clarity in the user interface: an uncertainty about the meaning of its controls and views in terms of the underlying concepts. Sometimes, in contrast, the meaning is clear enough, but the mapping makes it hard for users to perform the actions or get the information they need.
+
+Backblaze (as I mentioned in Chapter 2) is an excellent backup utility that I've used for several years. e backups indeed run blazingly fast (up to about 200 GB per day), the setup is straightforward, and the service seems to be reliable. Moreover, restoring the latest version of a le is easy: you just go to the restore page of their website, select the le, and click to download it.
+
+Restoring older versions, however, is not so easy. e dialog (Figure 8.8) lets you navigate the le system (on the le) to nd the folder you're interested in, and (on the right) lets you select which les in that folder to download.
+
+To restore an earlier version of a le, you can enter a date at the top of the dialog. ere are in fact two dates. By seing the *from* date, you can include only