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-001-030/concepts-001-030.md

@@ -0,0 +1,390 @@
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_0_Picture_0.jpeg)
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+# **The Essence of Software** Why Concepts Matter for Great Design *Daniel Jackson* princeton university press · princeton *&* oxford
+
+### Copyright © 2021 by Princeton University Press
+
+Princeton University Press is commied to the protection of copyright and the intellectual property our authors entrust to us. Copyright promotes the progress and integrity of knowledge. ank you for supporting free speech and the global exchange of ideas by purchasing an authorized edition of this book. If you wish to reproduce or distribute any part of it in any form, please obtain permission.
+
+Requests for permission to reproduce material from this work should be sent to permissions@press.princeton.edu
+
+Published by Princeton University Press
+
+41 William Street, Princeton, New Jersey 08540
+
+6 Oxford Street, Woodstock, Oxfordshire OX20 1TR
+
+[press.princeton.edu](http://press.princeton.edu)
+
+All Rights Reserved
+
+ISBN 978-0-691-22538-8 ISBN (e-book) 978-0-691-23054-2
+
+British Library Cataloging-in-Publication Data is available
+
+Editorial: Hallie Stebbins and Kristen Hop
+
+Production Editorial: Jenny Wolkowicki
+
+Jacket design: Emily Weigel
+
+Production: Danielle Amatucci
+
+Publicity: Sara Henning-Stout and Kate Farquhar-omson
+
+Copyeditor: Bhisham Bherwani
+
+Interior design: Daniel Jackson
+
+Set in Adobe Arno Pro and Stone Magma using Adobe InDesign
+
+Printed on acid-free paper. ∞
+
+Printed in the United States of America
+
+10 9 8 7 6 5 4 3 2 1
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_4_Picture_0.jpeg)
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+# Contents
+
+### How to Read is Book · 1
+
+### Part I: motivations
+
+- 1 Why I Wrote is Book · 9
+- 2 Discovering Concepts · 15
+- 3 How Concepts Help · 29
+
+### Part iI: esSentials
+
+- 4 Concept Structure · 47
+- 5 Concept Purposes · 59
+- 6 Concept Composition · 79
+- 7 Concept Dependence · 99
+- 8 Concept Mapping · 109
+
+### Part IiI: principles
+
+- 9 Concept Specicity · 127
+- 10 Concept Familiarity · 147
+- 11 Concept Integrity · 157
+
+Questions to Remember · 167 Acknowledgments · 179
+
+### resources
+
+Explorations & Digressions · 183 References · 299 Index of Applications · 309 Index of Concepts · 311 Index of Names · 315 Index of Topics · 317
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+# How to Read is Book
+
+*A micromaniac is someone obsessed with reducing things to their smallest possible form. is word, by the way, is not in the dictionary. —Edouard de Pomiane,* French Cooking in Ten Minutes
+
+Concept design is a simple idea that you'll be able to apply in your own work using and designing soware—without having to master any complex technicalities. Many of the concepts I'll use as examples will be recognizable old friends. So I'll take it as a compliment if your conclusion, aer reading this book, is that concepts are a natural and even obvious way to think about so ware, and that you learned nothing more than a systematic framework for an intuitive idea.
+
+But even if the underlying theme of this book resonates and seems familiar, I suspect that for many readers this new way of thinking about soware will be disorienting, at least initially. Although soware designers have talked for decades about conceptual models and their importance, concepts have never been placed at the center of soware design. What would design look like if every soware app or system were described in terms of concepts? What exactly would those concepts be? How would they be structured? And how would they be composed together to form the product as a whole?
+
+To answer these questions as best I can, this book is longer than I would have liked. To mitigate that, I have organized it so that dierent readers can take dierent journeys through it. Some will want to reach a pragmatic destination as quickly and expeditiously as possible; others, wanting a deeper understanding, may prefer to follow me on some detours away from the main path. is lile guide should help you plan your route.
+
+### *Intended Audience*
+
+In short, this book is aimed at anyone interested in soware, in design, or in usability. You might be a programmer, a soware architect, or a user interaction designer; a consultant, an analyst, a program manager, or a marketing strategist; a computer science student, teacher, or researcher; or maybe just one of
+
+those people who (like me) enjoys thinking about why things are designed in certain ways—and why some designs succeed so gloriously and others fail so spectacularly.
+
+No knowledge of computer science or programming is assumed, and although many of the principles in the book can be expressed more precisely in logic, no mathematical background is required. In order to appeal to as broad an audience as possible, I've drawn examples from a wide variety of popular apps, from word processors to social media platforms. So each reader will likely encounter examples that are easy to follow and others that require more eort. A byproduct of reading the book, I hope, will be a more solid grasp (and thus greater mastery) of apps that you use but don't yet fully understand.
+
+### *Goals of is Book*
+
+is book has three related goals. e rst is to present some straightforward techniques that soware creators can apply immediately to improve the quality of their designs. By helping you identify and disentangle the essential concepts, articulate them, and make them clear and robust, the book will enable you to design soware beer—and thus design beer soware—whatever phase of design you work in, from the earliest phases of strategic design (in which products are imagined and shaped) to the latest phases (in which every detail of interaction with the user is seled).
+
+e second goal is to provide a fresh take on soware, so you can view a so ware product not just as a mass of intertwined functions, but as a systematic composition of concepts, some classic and well understood, and others novel and more idiosyncratic. With this new perspective, designers can focus their work more eectively, and users can understand soware with greater clarity, empowering them to exploit their soware to its fullest potential.
+
+My third and nal goal is broader and perhaps easier. It is to convince the community of researchers and practitioners who work on the development of soware applications and services that the design of soware is an exciting and intellectually substantive discipline.
+
+Interest in soware design—especially when focused on user-facing aspects—has waned over the last few decades, even as recognition of its importance has grown. In part this is due to the misconception that there is nothing inherent to the design of soware that makes it more or less usable, and that
+
+### how to read this book
+
+any such judgments are subjective (or beer addressed as psychological or social questions, with the focus more on the user than the soware itself).
+
+e rise of empiricism in soware practice—while motivated by the apt recognition that even the best designs have aws that only user testing will reveal—has also, in my view, dulled our enthusiasm for design, as many have come to doubt the value of design expertise. But mostly, I believe, we have suffered from a lack of respectability and intellectual condence, since our ideas about what makes soware usable have more oen been expressed as tentative rules of thumb rather than principles grounded in a rich theory. I hope to show, in this book, that such principles and theory do indeed exist, and to encourage others to pursue their development and renement.
+
+### *Choosing Your Path*
+
+You can take dierent paths through the book, depending on your goals. To do so, it will help you to know how the book is organized and what each part contains.
+
+Part I contains three motivational chapters. e rst might have served as a preface: it explains why I came to write this book, and why the problems that I was interested in hadn't already been addressed in other elds (such as human-computer interaction, soware engineering and design thinking). In the second chapter, we see our rst examples of concepts, and the impact that they have on usability, and I explain concept design as the top of a hierarchy of user-experience design levels. e third chapter outlines the many roles that concepts have, from being product dierentiators to being the linchpin of digital transformations.
+
+Part II is the heart of the book. Its rst chapter tells you exactly what a concept is, and how it can be structured. e second explains the fundamental idea of a concept's purpose as a motivation and a yardstick. e third shows how an app or system can be understood as a composition of concepts, combined using a simple but powerful synchronization mechanism; it explains how overor under-synchronization can damage usability; and, more subtly, how some features that we traditionally view as complex and indivisible can instead be understood as synergistic fusions of distinct concepts. e fourth shows how mapping concepts to a user interface is not always as straightforward as you might imagine, and that sometimes the problem with a design lies not with the
+
+concepts per se but in their realization as buons and displays. e last chapter in this part introduces a way to think about soware structure at a very high level as a collection of concepts that are mutually dependent on one another—not that any concept relies on another concept for its correct working, but rather that only certain combinations of concepts make sense in the context of an app.
+
+Part III introduces three key principles of concept design each in its own chapter: that concepts should be specic (one-to-one with purposes); that they should be familiar; and that the integrity of a concept should not be violated in composition (resulting in behaviors that, when viewed through the lens of an individual concept, do not satisfy that concept's specication).
+
+e body of the book closes with a list of provocative questions addressed to readers in dierent roles. You might use these as a summary of the lessons of the book; or as a checklist in your subsequent practice; or even read them rst as a quick overview of what the book oers.
+
+If you want to jump in at the deep end, you could start with Part II; the motivations of Part I could be read as a conclusion, summarizing the ways in which the ideas you've learned can be applied. Each chapter ends with a summary of the main lessons and a list of practices that you can apply immediately.
+
+### *Explorations & Digressions*
+
+Almost half the book is a collection of endnotes. I wrote the book like this because I wanted to make the body of the book as brief as possible, while also carefully justifying my approach and explaining its connection to existing design theories. So the main part of the book contains no discussion of related work (not even a single citation), ignores many subtle points, and leaves out many ideas I have about design more generally.
+
+e endnotes make up for these omissions. ere, I not only cite related work but aempt to put it all in context and explain its signicance. I explain in much more detail the distinguishing characteristics of concept design, and I present examples that require more background (or persistence) to comprehend. When I have not managed to resist the temptation to fulminate (against rampant empiricism, or a myopic focus on defect elimination, for example), I have at least relegated my diatribes to these notes.
+
+### how to read this book
+
+e notes are cited at appropriate points in the main text with superscript numerals; the rst appears a few sentences from here. But to spare you the annoyance of ipping back and forth, I have grouped them into free standing sections with their own titles, so they can be read independently, and you can just dive in and read them randomly at your leisure.
+
+### *Multiple Indexes*
+
+Rather than just one index, this book has four separate ones: an index of the applications from which examples are drawn; an index of concepts; an index of names; and a general index of topics. e entries under *concept* in the index of topics might be particularly useful, as they highlight the key qualities of concepts and point to various mini essays in the endnotes.
+
+### *Warning: Micromaniac at Work*
+
+De Pomiane, author of the inimitable *French Cooking in Ten Minutes*, 1 confesses in his introduction to being a micromaniac. I readily admit to the same pathology. I don't want to hear that a design failed or succeeded for a myriad of amorphous reasons. Even if that were sometimes true, what use would it be? I want to get to the essence, to put my nger on the one essential spot, on the crucial design decision that launched the product to dizzying success or sunk the entire enterprise.
+
+I am not naive, and I know that being cognizant of multiple factors in design—especially when analyzing the causes of accidents—is wise and sensible. But it's just not a valuable way to draw lessons from prior experiences. To do that, I believe we all need to be micromaniacs: to focus on the tiniest of details in the search for an elusive but potent explanation whose generalization oers a lasting and widely applicable lesson. So be warned: the devil is in the details and the angels are too.<sup>2</sup>
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+# Why I Wrote is Book
+
+As an undergraduate in physics, I'd been entranced by the idea that the world could be captured by simple equations like *F = ma*. When I became a programmer, and later a computer science researcher, I gravitated towards the eld of formal methods, because it promised to do something similar for soware: to express its very essence in a succinct logic.
+
+### *A Passion for Design*
+
+My main research contribution in the 30 years since my PhD has been Alloy,3 a language for describing soware designs and analyzing them automatically. It's been an exciting and satisfying journey for me, but I came to realize over time that the essence of soware doesn't lie in any logic or analysis. What really fascinated me wasn't the question that consumed most formal methods researchers—namely how to check that a program's behavior conforms exactly to its specication—but rather the question of *design*. 4
+
+I mean "design" here in the same sense that the word is used in other design disciplines: the shaping of some artifact to meet a human need. Design, as the architect Christopher Alexander put it, is about creating a *form* to t a *context*. For soware, that means determining what the behavior of the soware should be: what controls it will oer, and what responses it will provide in return. ese questions have no right or wrong answers, only beer or worse ones.5
+
+I wanted to know why some soware products seem so natural and elegant, react predictably once you master the basics, and let you combine their features in powerful ways. And to pinpoint why other products just seem wrong: cluttered with needless complexity, and behaving in unexpected and inconsistent ways. Surely, I thought, there must be some essential principles, some theory of soware design, that could explain all of this. It would not only explain why some soware products are good and some are bad, but it would help you x the problems and avoid them in the rst place.
+
+### *Design in Computer Science and Other Fields*
+
+I started to look around. Within my own subeld (formal methods, soware engineering and programming languages), such a theory exists for what you might call "internal design"—namely the design of the structure of the code. Programmers have a rich language of design, and well-established criteria for what distinguishes good designs from bad ones. But no such language or criteria exist for soware design in the user-facing sense, namely design that determines how soware is experienced as a form in context.6
+
+Internal code design is very important and inuences primarily what so ware engineers call "maintainability," which means how easy (or hard) the code is to change over time as needs evolve. It also inuences performance and reliability. But the key decisions that determine whether a soware application or system is useful and fullls its users' needs lie elsewhere, in the kind of soware design in which the functionality and the paerns of interaction with the user are shaped.
+
+ese big questions were at one time more central in computer science. In the eld of soware engineering, they came up in workshops on soware design, specication and requirements; in the eld of human-computer interaction, they permeated early work on graphical user interfaces and computational models of user behavior.<sup>7</sup>
+
+But as time passed, they became less fashionable, and they faded away. Research in soware engineering narrowed, and eliminating defects—whether by testing or more sophisticated means such as program verication—became synonymous with soware quality.8 But you can't get there from here: if your soware has the wrong design, there's no amount of defect elimination that will x it, short of going back to the very start and xing the design itself.9
+
+Research in human-computer interaction (HCI) shied to novel interaction technologies, to tools and frameworks, to niche domains, and to other disciplines (such as ethnography and sociology). Both soware engineering and HCI embraced empiricism enthusiastically, largely in the misguided hope that this would bring respectability. Instead, the demand for concrete measures of success seems to have led researchers towards less ambitious projects that admit easier evaluation, and has stymied progress on bigger and more important questions.10
+
+### 1: why i wrote this book
+
+Puzzlingly, even as interest in design seems to have waned, talk of "design" is everywhere. is is not in fact a contradiction. e talk, almost exclusively, is about the *process* of design, whether in the context of "design thinking" (a compelling packaging of iterative design processes), or of "agile" soware development. ese processes are undoubtedly valuable (so long as they are applied judiciously and not as panaceas), but they are for the most part content-free. I mean that not to disparage but to describe. Design thinking, for example, might tell you to develop your solution hand in hand with your understanding of the problem, or to engage in alternating phases of brainstorming ("divergence") and reduction ("convergence"). But no design thinking book that I have read talks in depth about any particular designs and how the process sheds light on them. e very domain-independence of design thinking may be the key to its widespread appeal and applicability—but also the reason it has lile to say about deeper challenges of design in a particular domain such as soware.11
+
+### *Clarity & Simplicity in Design*
+
+When I began the Alloy project, with the goal of creating a design language that was amenable to automatic analysis, I was critical of existing modeling and specication languages whose lack of tool support rendered them "write-only." is snide dismissal was not entirely unwarranted. Aer all, why would you go to the trouble of constructing an elaborate design model if you couldn't then do anything with it? I argued, in particular, that the designer's eort should be rewarded immediately with "push-buon automation" that would instantly give you feedback in the form of surprising scenarios that would challenge you to think more deeply about your design.12
+
+I don't think I was wrong, and Alloy's automation did indeed change the experience of design modeling. But I had underestimated the value of writing down a design. In fact, it was a not very well guarded secret amongst formal methods researchers (who were eager to demonstrate the ecacy of their tools by nding aws in existing designs) that a high proportion of the aws were detected *before* the tools were even run! Just transcribing the design into logic was enough to reveal serious problems. e soware engineering researcher Michael Jackson credits not the logic per se but the very diculty of using it, and once mischievously suggested that the quality of soware systems might be improved if designers were simply required to record their designs in Latin.
+
+Clarity is good not only for nding design aws aer the fact. It is also the key to good design in the rst place. In teaching programming and soware engineering over the last thirty years, I've become increasingly convinced that the determinant of success when you're developing soware isn't whether you use the latest programming languages and tools, or the management process you follow (agile or otherwise), or even how you structure the code. It's simply whether you know what you are trying to do. If your goals are clear, and your design is clear—and it's clear how your design meets the goals—your code will tend to be clear too. And if something isn't working, it will be clear how to x it.13
+
+It is this clarity that distinguishes great soware from the rest. When the Apple Macintosh came out in 1984, people could see immediately how to use folders to organize their les; the complexities of previous operating systems (such as Unix, which made even the command to move les between folders complicated) seemed to have evaporated.
+
+But what exactly is this clarity, and how is it achieved? As early as the 1960s, the central role of "conceptual models" has been recognized. e challenge was not merely to *convey* the soware's conceptual model to the user so that her internal version ("mental model") was aligned with the programmers', but to treat it as a subject of design in its own right. With the right conceptual model, the soware would be easy to understand and thus easy to use. is was a great idea, but nobody seems to have pursued it, and so until now "concepts" have remained a vague, if inspiring, notion.14
+
+## *How is Project Came About*
+
+Convinced that conceptual models were indeed the essence of soware, I started about eight years ago trying to gure out what they might be. I wanted to give them concrete expression, so that I could point to some soware's conceptual model, compare it to others (and to the mental models of users), and have an explicit focus for design discussions.
+
+at didn't seem so hard. Aer all, a plausible rst cut at a conceptual model might be just a description of the soware's behavior, made suitably abstract to remove incidental and "non-conceptual" aspects (such as the details of the physical user interface). What proved much harder was nding appropriate
+
+### 1: why i wrote this book
+
+structure in the model. I had an inkling that a conceptual model should be made up of concepts, but I didn't know what a concept was.
+
+In a social media app such as Facebook, for example, it seemed to me that there should be a concept associated with liking things. is concept surely wasn't a function or action (such as the behavior bound to the buon you click to like a post); there are too many of those, and they only tell part of the story. It also surely wasn't an object or entity (such as the "like" itself that your action produced), since at the very least the concept seemed to be about the *relationship* between things and their likes. It also seemed essential to me that the concept of liking was not associated with any particular kind of thing: you could like posts, comments, pages, and so on. e concept, in programming lingo, is "generic" or "polymorphic."
+
+### *is Book: Opening a Conversation*
+
+is book is the result of my explorations to date. Driven by dozens of design issues in widely used applications, I've evolved a new approach to soware design, rening and testing it along the way. A happy aspect of this project has been that every app failure or frustration had a silver lining: a chance to extend my repertoire of examples. It has also given me greater sympathy and respect for the designers when my analysis revealed the full complexity of the problem they faced.
+
+Of course, the problem of soware design is not solved. But as my friend Kirsten Olson wisely advised me: a book should aim to start a conversation, not to end one. In the course of giving many talks about this project, I've been thrilled to discover that it seems to resonate with audiences more than any of my previous ones. I suspect this is because soware design is something we all want to talk about, but we have not known how to have that conversation.
+
+So to you, my readers—fellow researchers, designers and users—I present this book as my opening gambit in what I hope to be a fruitful and enjoyable conversation.
+
+| Draft: not for distribution or quotation. © 2018 DanielJackson |  |  |
+|----------------------------------------------------------------|--|--|
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+|                                                                |  |  |
+
+# Discovering Concepts
+
+A soware product—from the smallest app that runs on your phone to the largest enterprise system—is made of *concepts*, each a self-contained unit of functionality. Even though concepts work in tandem for a larger purpose, they can be understood independently of one another. If an app is like a chemical mixture, concepts are like molecules: although bound together, their properties and behavior are similar wherever they are found.
+
+You're already familiar with many concepts, and know how to interact with them. You know how to place a phone *call* or make a restaurant *reservation*, how to *upvote* a comment in a social media forum and how to organize les in a *folder*. An app whose concepts are familiar and well designed is likely to be easy to use, so long as its concepts are represented faithfully in the user interface and programmed correctly. In contrast, an app whose concepts are complex or clunky is unlikely to work well, no maer how fancy the presentation or clever the algorithms.
+
+Since concepts have no visible form, they're rather abstract, and this is perhaps why they haven't been a focus of aention until now. I hope to persuade you, in the course of this book, that by thinking in terms of concepts, and by "seeing through" user interfaces to the concepts that lie behind them, you will be able to understand soware more deeply—to use it more eectively, to design it beer, to diagnose aws more precisely, and to envision new products with greater focus and condence.
+
+We don't generally appreciate how something works until it breaks. You may think that your water heater just magically produces a constant stream of hot water. But then at some point someone in your household takes one shower too many, and your shower is cold. at's when you might learn that your water heater has a *storage tank* with limited capacity.
+
+Likewise, to learn about concepts, we need to see what happens when they go wrong. Much of this book, therefore, will involve examples of concepts that
+
+fail in seemingly unlikely scenarios, or that turn out to be much harder to understand than you'd expect them to be. In this chapter, we'll see our rst examples of concepts, and how they can explain some unexpected (and surprisingly complicated) behaviors.
+
+But don't be put o, or draw the conclusion that the *idea* of concepts is itself obscure and complicated. On the contrary, the idea is straightforward, and adopting it will help you to design soware that is simpler and more powerful than much of the soware we use today.
+
+### *A First Example: Baing Backups*
+
+To protect my work from corrupted disks and accidental deletion, I use a terric backup utility called Backblaze, which copies my les to the cloud, and lets me restore old versions if I need to. It runs invisibly and continuously in the background, keeping an eye on every le in my computer, copying it to the cloud if it changes.
+
+Recently, I edited a video and wanted to make sure the new version had been backed up before I deleted the old one to save space. I checked the backup status, and it said "You are backed up as of: Today, 1:05 pm." Since I had created the new video *before* 1:05 pm, I assumed it had been backed up. Just to be sure, I tried to restore it from the cloud. But it wasn't there.
+
+I contacted tech support, and they explained to me that les aren't exactly backed up continuously. ere's a periodic scan that compiles a list of new or modied les; when the next backup runs, only les on that list are uploaded. So any changes made between the scan and the backup fall between the cracks until they're discovered in the next scan.
+
+I could force a rescan, they told me, by clicking the "Backup Now" buon while holding down the option key. I followed this advice, and waited for the scan and subsequent backup to complete. Now, surely, my new video would show up on the restore list! But no such luck. At this point, I was totally confused, and asked for more help. It turned out that my video *had* been uploaded, but only to a special "staging" area, from which les are moved to the restore area every few hours.
+
+My problem was that I misunderstood the key *backup* concept of Backblaze. I had imagined that les were uploaded continuously, and moved directly to the restore area (Figure 2.1, le). In fact, only the les on the list produced by the last
+
+### 2: discovering concepts
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_22_Picture_1.jpeg)
+
+fig. 2.1 *Backblaze's backup concept. On the le, what I assumed: (1) I make a change to a le; (2) when the backup runs, the le is copied to the cloud; (3) I can then restore it. On the right, what actually happens: (1) I make a change to a le; (2) a scan runs and adds the le to a list of les for backup; (3) the backup runs, copying to the cloud only those les that were added in the last scan; (4) periodically, backed-up les are moved to a cloud location (5) om where they can be restored.* 
+
+scan are uploaded, and even then remain unavailable until they have been transferred sometime later from the upload destination to the restore area (Figure 2.1, right).
+
+is is a small example but it illustrates my key point. I'm not taking a stand on whether the design of Backblaze is awed or not; I suspect it could be improved though (see Chapter 8 for a suggestion). Certainly, had I taken the backup message at face value and not known about the scan, I might have lost some crucial les.
+
+What I *am* claiming is that any discussion of this design must revolve around the fundamental concepts, in this case the *backup* concept, and an assessment of whether the behavioral paern that it embodies is t for purpose. e user interface maers too, but only to the extent that it serves the app's concepts by representing them to the user. If we want to make soware more usable, concepts are where we must start.
+
+# *Dropbox Delusions*
+
+A friend of mine was running out of space on her laptop. So she cleverly sorted the les by size, and looked down the list to see if there were any large and
+
+unfamiliar les that she could get rid of. She identied a dozen or so such les, and went ahead and deleted them. A few minutes later she got a panicked call from her boss asking what had happened to some large les containing data for an important work project.
+
+What went wrong? To answer this, we need to understand some key concepts of Dropbox, a popular le-sharing utility. Dropbox allows multiple users to view a shared collection of les and folders, and to update them collaboratively. To maintain this illusion, Dropbox propagates changes made by one user to the versions seen by other users. e question will be: what kinds of changes are propagated? And under what conditions?
+
+Ava is a party planner who uses Dropbox to coordinate with her customers. She's planning a party for Bella, so she creates a folder with the name *Bella Party* and shares it with Bella (Figure 2.2). Whatever Ava puts into the folder, Bella can now see. In fact, the sharing is symmetrical; whatever Bella puts in, Ava can see too, and whatever changes one of them makes, the other sees those very same changes. So it's as if there were just one copy of a folder that Ava and Bella can work on together.
+
+Actually, it's not quite that simple, because not *all* changes that one of them makes will be seen by the other. Perhaps Bella doesn't want the folder to be called *Bella Party*—aer all, it's her party! So she gives the folder the new name *My Party*. e question is: what does Ava now see? Does the name change for her too?
+
+ere are only two possibilities. Either Bella's action will change the name Ava sees too, in which case there is just one shared le name, or it will not, in which case there are two names for the same folder, one that Ava uses and one that Bella uses.
+
+So which happens? It turns out that *both* outcomes are possible, depending on how the folder was shared. In this case, in which Ava has shared the folder *explicitly* with Bella, Bella's renaming will only be seen by Bella, and Ava will *not* see the change. But suppose Ava creates another folder inside *Bella Party* called *Bella Plan* (Figure 2.3 top). is second folder is now shared *implicitly* (by virtue of its containing folder being shared). Now if Bella renames *Bella Plan* to *My Plan*, say, then Ava *will* see the change.
+
+You might imagine that this variability of behaviors is accidental, that it's the result of some arbitrary choices that arose during Dropbox's evolution. Or you
+
+### 2: discovering concepts
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_24_Picture_1.jpeg)
+
+fig. 2.2 *Sharing a folder in Dropbox. Ava (AA) has shared the folder named Bella Party with Bella (BB). If Bella now changes the name of the folder, will Ava see the change?* 
+
+might think it's evidence of a bug. In fact, neither of these is true. is apparent design oddity is a direct consequence of a fundamental aspect of Dropbox's design.
+
+Before I explain exactly what's going on, let's consider one more question. What happens if Bella *deletes* a folder? Will Ava's copy be deleted too? Again, it depends on the context. If Bella deletes *Bella Party*, her copy alone will go away; but if she deletes *Bella Plan*, Ava will lose it too. Dropbox does give dierent messages in the two cases (Figure 2.3), one of which explains more fully what will happen. But, strangely, the additional information is given in the rst case, not in the second case when the deletion results in permanent loss of the le.
+
+Now we have an explanation for my friend's experience. Her boss, wanting to share just one le with her, had shared the entire folder instead. When my friend removed the les she wasn't using, she was deleting them from the shared folder—and thus removing them for everyone, her boss included.
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_25_Figure_1.jpeg)
+
+fig. 2.3 *Dropbox's folder deletion messages. e folder Bella Party has been shared (top). If that folder is deleted, the message (middle) informs you that the deletion will not be propagated to other users. If the folder Bella Plan contained within it is deleted, a dierent message (boom) appears, surprisingly not warning that other users will lose the folder too.* 
+
+### *Explaining Dropbox*
+
+To see what's going on in these sharing scenarios, it helps rst to articulate what our expectations might have been. A simple and familiar design for names would treat them as if they were sticky labels aached to physical objects—like a cat collar, or a license plate—with at most one label per object (Figure 2.4, le). We might call this approach "name as metadata," and it would be an in-
+
+### 2: discovering concepts
+
+<span id="page-26-0"></span>![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_26_Picture_1.jpeg)
+
+fig. 2.4 *Two possible concepts for folders in Dropbox: in the metadata concept (le), names are labels aached to folders; in the unix folder concept (right), names belong to entries within the parent folder.* 
+
+stance of a more general *metadata* concept in which data that describes an object—such as the title or caption of a photo—can be aached to it.
+
+With respect to deletion, the simplest design would be to make a le or folder disappear when it's deleted. We might call this (using a technical term) the "deletion as poof " approach to deletion: you click delete, and "poof!"—it's gone. e underlying concept here—that a pool of items can be stored, with actions to add and remove items from the pool—is so basic and familiar it has no name. In this design, we'd expect a separate *sharing* concept, with an *unshare* action so that you can remove a le or folder that someone else shared with you and free up the space in your own account without deleting their copy.
+
+Both of these understandings—that names are metadata and deletion simply removes items from a pool—are wrong (at least for Dropbox). e concepts behind these understandings are themselves ne; they're just not the concepts that Dropbox uses. If you hold the wrong conceptual model of a soware app, you might get away with it for a while. We've seen that in some scenarios these explanations would work successfully. But in other scenarios, they'll fail, perhaps with disastrous consequence.
+
+e actual concepts that Dropbox uses are very dierent (Figure 2.4, right). When an item sits in a folder, the name of that item belongs *not* to the item itself but rather to the folder containing it. ink of a folder as being a collection
+
+of tags, each containing the name of an item (a le or folder) and a link to it. is concept, which I'll call *unix folder*, was not invented by Dropbox, but, as its name suggests, was borrowed from Unix.15
+
+Look at the diagram i[n Figure 2.4 \(](#page-26-0)right). Each of Ava and Bella has her own, top-level Dropbox folder, and these two folders have *separate* entries for the single, shared folder called *Bella Party*. When Bella renames *Bella Party*, this alters the entry in her own Dropbox folder, and the entry in Ava's folder is unchanged.
+
+In contrast, there is only a single entry holding the name of the second-level shared folder, *Bella Plan*, belonging to the single, shared parent folder called *Bella Party*. Since there is only *one* entry for the folder—the same entry seen by both Ava and Bella—when Bella renames the folder, she is changing that one entry in their shared folder, so Ava sees the change too.
+
+Using this same *unix folder* concept, we can now explain the deletion behaviors. Deletion doesn't remove the folder per se; it removes its entry. So if Bella deletes the folder *Bella Party*, she removes the entry from her own folder, and Ava's view is unchanged. But if Bella deletes *Bella Plan*, she removes the entry from the shared folder, and the deleted folder is now inaccessible to Ava too.
+
+### *What Kind of Flaw is is?*
+
+At this point, you might be saying to yourself: Well, this is all obvious. I knew Dropbox behaved like this and I'm not in the least bit surprised. ere's nothing wrong with Dropbox, and someone who doesn't understand it shouldn't be using it. But if you think this, I'm prey sure you'd be in the minority of readers. We presented this scenario to MIT computer science students and found that many of them, even those who used Dropbox regularly, were confused.16
+
+Even if you understood all these subtleties, I'd argue that there's still a problem. e distinction between the two cases—whether the folder that is the subject of the action is shared at the top level, or belongs to another folder that is itself shared—isn't readily discernible in the user interface, so it's a constant annoyance having to gure out which situation you're in.
+
+Moreover, it doesn't seem reasonable that this rather arbitrary distinction should determine the behavior. Why should I be able to give my own name only to the top-level folder? Why can't I give private names to all the folders shared with me? Or conversely, if renaming folders for both of us is part of our shared work, why can I only do it for some folders and not others?
+
+### 2: discovering concepts
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_28_Picture_1.jpeg)
+
+fig. 2.5 *Levels of interaction design.* 
+
+Assuming then, that these scenarios are indeed evidence of a aw in Dropbox, we can ask: what kind of aw is it? It's certainly not a bug; Dropbox has behaved like this for years. We might wonder if it's a aw in the user interface. at seems implausible too. It would be possible, of course, for Dropbox to give more informative messages when a change you make aects other users. But this might just be perceived as additional complexity, and experience suggests that users ignore warning messages if they come up too oen.17
+
+e real problem runs deeper. It's in the very essence of how les and folders are named, and how those names are related to the containment relationship between folders and their contents. is is what I call a *conceptual* design issue. e aw is that the Dropbox developer has certain concepts in mind that have been faithfully implemented. But those concepts, at the very least, are not consistent with the concepts in most users' minds. And, at worst, these concepts are not a good match for the users' purposes.18
+
+### *Levels of Design*
+
+To put conceptual design in perspective, it helps to break soware design into levels, as shown in Figure 2.5. is classication is my own, but it is similar to schemes previously proposed.19
+
+e rst level of design, the *physical level*, is about the physical qualities of the artifact. Even soware whose interface is no more than a touch-sensitive piece of glass has such qualities, limited though they might be.20 At this level, the designer must take into account physical capabilities of human beings. It's
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_29_Picture_1.jpeg)
+
+![](03.Resource(책임X,%20정보,학습)/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-001-030/_page_29_Picture_2.jpeg)
+
+fig. 2.6 *A design issue at the physical level, and a classic example of applying Fis's Law. Which menu placement allows for more convenient access: the macOS placement (on the le) in which an application's menu bar always appears at the top of the desktop, or the Windows placement (on the right) in which the menu bar is part of the application window?* 
+
+where accessibility concerns arise, as the designer considers how a visually impaired, or color-blind, or deaf user might interact.
+
+Common human characteristics dictate certain design principles. For example, the fact that our limited visual sampling rate results in *perceptual fusion*, making it hard to distinguish events that occur within about 30ms of each other, suggests that 30 frames/second is enough for a movie to look smooth. It also tells us that system reactions that take much longer than 30ms will be perceived as delays by the user, and should be avoided, or given progress bars, and if very much longer, an opportunity to abort. Likewise, Fis's Law predicts the time it takes for a user to move a pointing device to a target, and explains why the menu bar should be positioned at the top of the screen, as in the Macintosh desktop, and not in the application window, as in Windows (Figure 2.6).21
+
+e second level of design is the *linguistic level*. is level concerns the use of language for conveying the behavior oered by the soware, to help the user navigate the soware, understand what actions are available and what impact they will have, what has happened already, and so on. While design at the physical level must respect diversity amongst the physical characteristics of its users, design at this level must respect dierences of culture and language.
+
+Obviously, the buon labels and tooltips on an app will vary depending on whether it's intended for English or Italian speakers. (I remember as a small child on holiday in Italy learning the hard way that the faucet marked *calda* is not the cold one.) e designer must be aware of cultural dierences too. In Europe, a road sign comprising a red circle with a white interior means that no vehicular trac is permied at all; most American drivers would not be able to