softwaredesign/raw/book/EssenceOfSoftware_Eng/concepts-181-210/concepts-181-210.md

# Acknowledgments

A few years ago, I shared a copy of my book dra with a colleague. It's prey good, he said—or at least it will be "aer a couple of rewrites." I smiled politely, thinking: it's been hard enough writing it once; it will kill me to start again. But in his gentle insistence that the book needed work, he was absolutely right, and I ended up rewriting it three times over. It's still far from perfect, but it's reached the point at which I've explained my ideas as best I can, and it's your turn my fellow researchers, practitioners and enthusiasts—to join the conversation.

I would never have had the motivation to work on this book for so many years—I rst wrote a dra in 2013—had it not been for the ongoing, insightful critiques of friends and colleagues (and their encouragement that it was worth persisting). So many of the good ideas in the book's structure and emphasis come from them. I am, in fact, astonished at the generosity and stamina of those who read the entire book, cover to cover, sometimes more than once. Michael Coblenz, Jimmy Koppel and Michael Shiner gave me copious comments on almost every page; Kathryn Jin, Georey Li, Rob Miller, Arvind Satyanarayan, Sarah Vu, Hillel Wayne and Pamela Zave gave me excellent expository suggestions; and Jonathan Aldrich, Tom Ball, Amy Ko and Harold imbleby not only reviewed the book in detail, but read it again a second time around aer I had reshaped the book in response to their wise advice.

e book has been tested for home use too: Akiva Jackson had a slew of brilliant suggestions for improvement that belied his lack of formal education in computer science; Rebecca Jackson, who has become the unocial editor of everything I write, gave me the benet of her magic with words; and Rachel Jackson ([hp://binahdesign.com\)](http://binahdesign.com) shared her exquisite eye for typography and book design.

Readers will likely notice inuences on the book that I have failed to appreciate myself, and to all those whose ideas I have taken without credit, I oer apology and gratitude. In addition to the many colleagues that I cite in the endnotes, I'd like to recognize in particular Santiago Perez De Rosso, who was a sounding board for my rst ideas on concepts; who built Gitless, the rst major

experiment in concept design; and whose Déjà Vu system embodied early notions of concept synchronization that we developed together.

My editor, Hallie Stebbins, has given me masterful guidance and advice as I've navigated the path of publication, and has been a staunch advocate for my book from the start; Bhisham Bherwani was a meticulous copy editor; and my production editor, Jenny Wolkowicki, shepherded my book along the way, attending to every detail, and generously tolerated the complexities of dealing with an author who insisted on designing his own book. Kirsten Olson, my coach, inspired me to think of a book project not as the production of an artifact but as an extended conversation and collaboration with an ever-widening circle of colleagues and friends.

e research that underlies this book—as those familiar with today's culture of computer science may guess—was not easy to fund, so I am especially grateful to the SUTD-MIT International Design Centre and its directors John Brisson, Jon Grith and Chris Magee who stuck with me over ve years of support.

I have dedicated the book to my extraordinary parents. My mother, Judy Jackson, has been an inspiration with her many books and projects and her unagging enthusiasm for all of my activities. My father, Michael Jackson, has taught me so much about soware that I can barely tell where his ideas end and mine begin, and I continue to relish our frequent conversations about our eld and its history (and the design of elevators and coin-operated zoo turnstiles).

ank you to you all of you. And nally, to my wife and biggest supporter Claudia Marbach: it's done. I'm so grateful for your wisdom, patience and encouragement, and any day now I'll be ready for that break I've been promising to take for so long…

> *Daniel Jackson July 30, 2021*

### *How to Read is Book*

1. De Pomiane's Delights. De Pomiane's *French Cooking in Ten Minutes* [126] is rst of all an unexpected source of spiritual inspiration: how many contemporary cookbook writers would insist you cook your meal in ten minutes so that, with only an hour for lunch, you are still le with half an hour to drink your coee? It also contains some great recipes. My favorite is "Tomatoes Polish Style"—appropriate, as de Pomiane was born into the Polish aristocracy (as Eduard Pozerski in 1875). Melt some buer, add some nely chopped onion, and two plum tomatoes sliced in half face down; cook on high heat for ve minutes, turn over, cook ve minutes longer, and spoon over two generous tablespoons of sour cream; bring barely to the boil over, take o the heat and serve.

is is indeed a micromaniac's delight, as it's hard to imagine a tastier dish with fewer ingredients (although I have to admit to adapting it by (a) replacing the onions by shallots, and (b) including some freshly grated nutmeg at the end—and using it as a sauce for pasta in place of de Pomiane's rather too minimal "Noodles Italian Style"). e timing of the recipe also reveals that while de Pomiane might be a micromaniac, he is no pedant.

2. e importance of details. "e details are not the details; they make the product." is enduring aphorism by the furniture designers Charles and Ray Eames was wrien for the script of a 1961 lm short called "ECS," about Eames Contract Storage, a furniture system designed for student dormitories. e same spirit is evident in the work of Jony Ive, the famed Apple designer, who ended a charming video about shaping the edges of the Macbook laptop with the self-eacing quip "at's quite obsessive, isn't it?"

Sorting out the details is rewarding work, but also hard. As Steve Jobs put it [150]: "To design something really well, you have to get it. You have to really grok what it's all about. It takes a passionate commitment to really thoroughly understand something, chew it up, not just quickly swallow it. Most people don't take the time to do that."

## *Chapter 1: Why I Wrote is Book*

3. e Alloy modeling language. Alloy is a language and analysis tool for soware design. e language itself is a simple but powerful logic based on relations that can be used to model complex data structures and behaviors with declarative constraints (that is, describing the *eects* of the behaviors rather than having to enumerate the steps that produce them). e Alloy Analyzer generates sample scenarios without the user having to write test cases, and can check that the design satises properties that the designer formulates—all completely automatically.

Alloy was inspired by the Z specication language [136] and by the SMV symbolic model checker [23]; its goal was to combine the elegance and succinctness of Z with the analytical power of SMV.

Alloy's technical innovation is a new analysis that achieves SMV-like automation by limiting the "scope" to nite bounds. For example, an analysis of a network protocol might consider all congurations involving up to ve nodes. By compiling into input for a SAT solver, Alloy can promise to cover the *entire* scope, that is all scenarios of that size (which for our network example would involve 32 million cases for the network connectivity graph alone!). is is why Alloy typically nds subtle errors that would elude testing.

e latest version of Alloy [20] smoothly incorporates the operators of linear temporal logic and includes support for unbounded model checking.

Alloy has been used in a wide range of applications, including networking, security, and electronic commerce, and has been taught in soware and formal methods courses around the world. Alloy is described in length in my 2006 book [66], and more briey, with applications, in a 2019 magazine article and video [67].

4. Soware design: origins of the idea. e idea of soware design, as advocated in this book—and contrasted, over the following pages, with the idea of design typical in programming, soware engineering and user interfaces—has been shaped by many people over many years. But it has never been articulated more forcefully than by Mitchell Kapor in his *A soware design manifesto*.

Kapor's manifesto and Winograd's book. Kapor, the founder of Lotus and designer of its eponymous product, rst presented his manifesto at Esther Dyson's PC Forum in 1990, challenging his fellow soware executives to recognize the central role of design in soware development. e manifesto was printed in Dr. Dobb's Journal (in January 1991), and then appeared a few years later as the anchoring chapter of a seminal book edited by Terry Winograd entitled *Bringing De-*

*sign to Soware* [149]. Winograd, who would later be one of the founders of Stanford's d.school, had convened a group of experts with the goal of dening the term "soware design." In the end, his book reected a diversity of views, but all sharing the conviction that such a discipline existed, albeit in a nascent form; that it had features in common with design in other disciplines; and that it was distinct from both soware engineering and user interface design.

Kapor's vision of a new eld (and even a new profession) resonated widely, and today everyone pays at least lip service to the idea that soware needs to be designed in Kapor's sense of the word. In my view, though, we have yet to build the intellectual foundations on which this eld and profession can be based. We have learned much from other design disciplines, and from the experience of creating our own products; and the eld of human-computer interaction has ourished. But the particular, distinctive qualities of soware design have yet to be articulated.

5. What is soware design? e term "design" is oen used loosely to refer to any activity that involves the creation of an artifact to satisfy some need while meeting some constraints. But in that sense, almost every human endeavor involves design, so the word loses any useful purchase. Some would contrast design to manufacturing, but for soware such a distinction is hard to sustain.

I prefer to reserve "design" for the shaping of artifacts judged primarily for their utility—thus separating design from art—and intended for direct human use distinguishing it from engineering. As Kapor put it [78]: "What makes something a design problem? It's where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together." Engineering focuses instead on cost, performance, resilience, and so on—all concerns that are of great interest to human users but which are usually invisible except when they fail.

us an architect, who *designs* a building, aims to create experiences of space and light that delight the building's occupants, and must therefore be intimately aware of their work paerns. e structural engineer, on the other hand, is responsible for ensuring that the building does not fall down in a heavy wind, and that its beams do not rust over time. e designer's analysis is qualitative and by necessity tentative, since the behavior of human users can never be fully predicted; the engineer's analysis is quantitative and denitive, and when it requires assumptions about human users they can usually be reduced to simple numeric measures (such as the maximum number of building occupants, or their average weight).

Soware design, the subject of this book, is thus about shaping and structuring the functionality of soware to meet the needs of its users. Soware engineering,

on the other hand, is about structuring the code that delivers this functionality, and subsumes what I refer to in the main text as the "internal design" of soware. Some soware engineering concerns, such as how fast the soware runs or how well it scales, are relevant to the user but mostly invisible, except when limits are encountered. Others, such as maintainability, are relevant only to the developers, and impact the user only to the extent that they impact the cost of development and the feasibility of new features.

e distinction between soware design and soware engineering was pithily expressed by David Liddle, the leader of the division at Xerox PARC that built the Star workstation: "Soware design is the act of determining the user's experience with a piece of soware. It has nothing to do with how the code works inside, or how big or small the code is. e designer's task is to specify completely and unambiguously the user's whole experience. at is the key to the whole soware industry, but, in most companies, soware design does not exist as a visible function—it is done secretly, without a profession, without honor." [149] We'd put less emphasis nowadays on "complete" and "unambiguous" specication, but otherwise his comment might serve as a slogan for this book.

In noting the lack of respect for soware design, Liddle echoed Kapor's lament in his manifesto [78]: "Today, the soware designer leads a guerrilla existence, formally unrecognized and oen unappreciated." Most soware, Kapor argued, was "merely engineered" and not designed at all. His remedy was to create a professional discipline of soware design, whose practitioners would have a solid grounding in technology but would be distinct from programmers. eir purview would be the very conception of the product, not just the user interface.

It is for just such a designer that my book is aimed. irty years since Kapor's manifesto, the title "soware designer" is still rare. But the tasks such a designer would undertake are seen as increasingly important, even if they are discharged by people with other titles—whether program managers, architects, UX designers, or programmers themselves.

6. Programming Knowledge. In contrast to soware design, soware engineering (or programming) has a well-established and rigorous body of knowledge. Programming as we know it originated in the late 1950s with Fortran, the rst high-level programming language. Within just a few decades, almost all the foundational ideas that we have about programming today were invented: dependencies and decoupling; specications, interfaces and invariants; abstract types, immutability, and algebraic datatypes; objects, subtypes, generics, and classes; higher-order

functions, closures, and iterators; grammars, parsing, and stream transformations; and so on.

Each of these ideas comes with prescriptive guidance on how to program well, and criteria for distinguishing good programs from bad ones. ree ideas, in particular, seem most signicant to me:

*Dependences*. A *dependence* between two modules arises when the rst relies on the second to meet its specication [116], and incurs a liability, in that the rst cannot be understood (or used in a new program) without the second. Eliminating dependencies is thus a major goal of program structuring, and is the motivation for many design paerns [44].

*Data abstraction*. e implementation of a datatype within a module is *representation-independent* [102] if the data structure used to represent instances of the datatype can be altered without having to modify code outside the module, by ensuring that such external code relies only on the behavior of operations of the type [95]. To establish this independence, programmers must not only ensure that clients of the type use it only through its operations, but also that no "representation exposure" occurs in which a reference to an internal structure is leaked to the outside [31].

*Invariants*. An *invariant* is a property of a program saying that, when observed at certain points (such as before or aer particular function calls), the state of the program satises some predicate: for example, that a tree is balanced, or that the elements of an array appear in order [40]. (In databases, invariants are called "integrity constraints".) By formulating invariants, the programmer can simplify the task of understanding complex behaviors. Instead of having to consider long histories of events, she can assume that the invariant holds at each prescribed point (so long as the invariant holds at the start and is reestablished aer an operation).

is rich theory means that programmers also have an expressive language for talking about programs. A well-trained programmer who overhears a conversation in which one programmer says to another "I'd make the key immutable, because otherwise you risk breaking the hash table's rep invariant" knows exactly what she is talking about and what the issues are. ere's no such language, yet, for soware design.

7. Design in soware engineering research. Tim Menzies and his students analyzed the prevalence of dierent topics in soware engineering, with a dataset comprising more than 35,000 papers from top conferences and journals [99]. In 1992, the rst year of his study, design was the most popular topic; by 2016, the last year, it ranked near the boom (eighth in conferences, and not even appearing in his jour-

nal classication). Although this study classied papers in a crude way (checking for a short list of keywords in titles and abstracts), the results match my impressions of a changing eld.

Design in human-computer interaction research. Design seems to have had its heyday in the HCI community in the 1980s, with the arrival of the Apple Macintosh in 1984, the emergence of user-centered design, and the publication of Don Norman's *e Design of Everyday ings* [110]. e book, although not ostensibly about soware, has had a huge inuence on user interface design, most notably through Norman's notions of *aordance* and *mapping*.

Stuart Card, Tom Moran and Allen Newell's landmark book, *e Psychology of Human-Computer Interaction* [26], showed how a model of the user as an information processor with certain parameters (for reaction time, memory capacity, etc.) could reliably predict the eciency of an interface design, and suggest improvements to it.

In 1989, Jakob Nielsen published his paper on "discount usability," proposing a potent but inexpensive combination of user testing, prototyping and heuristic evaluation for improving the design of user interactions [106]. A year later, a fuller paper with Rolf Molich [107] on heuristic evaluation appeared, leading to the rst version of his "10 Usability Heuristics," [108] which are essentially principles of user interface design, and have been followed by several such lists, most notably Bruce Tognazzini's "First Principles of Interaction Design" [143].

omas Green developed a list of criteria aimed at the design of programming languages and other notations, which he called "cognitive dimensions of notations" [46, 47]. In fact, his criteria can be applied much more generally to improve usability for any kind of interface. Indeed, several—such as consistency, error-tolerance, mapping and visibility—are common to the other lists mentioned above. Like them, they can be applied synergistically with the principles of concept design. (More on cognitive dimensions in Note 19.)

Design remains a hot topic in human-computer interaction research but it's rare to nd a paper that addresses it directly, and from which any concrete design guidance can be extracted. More oen, papers explore ethnographic or sociological issues, and don't contribute to a practical body of design knowledge.

For example, last year's session on "Design reections and methods" in CHI, a agship HCI conference, included only ve papers (out of 748 papers in total), and their topics were: the use of design to study metaphysical ideas in philosophy; modes of reection for imagining design futures; an agenda for integrating computers with the human body; a feminist/decolonialist analysis of iterative design

based on experiences with Aboriginal Australian communities; and the impact of automation on economies in the Global South—all no doubt topics of interest to specialists in those areas, but none of immediate relevance to the vast number of people working on the design of the soware that most people use.

For guidance on how to design soware, students and practitioners must go to textbooks and professional books instead. I recommend in particular Harold imbleby's *Press On* [141], which combines classic HCI principles with a state machine formalism for recording and analyzing designs, and also covers wider social, psychological and ethical concerns.

8. On verication and its cultural implications. In the early years of soware research, its pioneers—notably Bob Floyd, Edsger Dijkstra and Tony Hoare—introduced the radical idea that the behavior of a program could be precisely specied. With a specication in hand, the dierence between acceptable and unacceptable behaviors was no longer subjective, and "bugs"—defects in code that correspond to mismatches between specied and actual program behavior—became a focus of aention.

Dijkstra contrasted the "correctness problem"—whether a program meets its specication—with the "pleasantness problem"—whether the specication is appropriate in the context of use [33]. He noted that the correctness problem can be formulated mathematically, and he thus regarded it as a suitable topic for "scientific" investigation. In contrast, the pleasantness problem, he argued, is "non-scientific" and its pursuit by computer scientists questionable.

is distinction, and the idea of mathematically precise specication, launched the eld of program verication, bringing some dignity to our own dismal discipline. Specications have also been very benecial in their own right, but perhaps not in the way Dijkstra had expected. It turned out to be impossible to write complete, precise specications of even the simplest soware systems, or at least no easier than writing the code itself. Instead, specications found their use when applied to much smaller components within a single soware system. Such speci cations are valuable because they allow bugs to be localized—that is, to identify which component is to blame for an unexpected behavior.

Over the years, the notion of correctness, and the eld of verication that grew around it, became a cornerstone of computer science and one of its proudest achievements. From a design perspective, however, its impact has been in some respects pernicious. By separating out the "pleasantness problem" (and giving it such a brilliantly uninspiring name), Dijkstra drew aention away from it, despite its importance. A beer name might have been the "design problem" (for creating

the specication), contrasted with the "implementation problem" (for building an implementation that meets it).

e implementation problem is undoubtedly a more aractive target for many researchers because it is more clearly dened and more susceptible to incremental progress. Just as the proverbial drunk looks for his lost key under the lamppost because that's where the light is brightest, so soware researchers look under many implementation lampposts even though the key to soware quality oen lies elsewhere. e result of lavishing all our aention on implementation is that we have a eld with millions of implementers but few designers, and we oen leave the most critical decisions (about what the specication should be) to non-technical people. It's as if the building industry had only civil engineers and managers but no architects [78].

To Dijkstra, bugs were simply defects, and he insisted that it made no sense to talk about the number of bugs in a program: either the program met its specication or it did not. Ironically, the idea of correctness led to an almost exclusive focus on bugs. If the design of the specication is a non-scientic issue, the specication itself cannot maer much, and the primary issues remaining are what bugs are present and how they can be eliminated. is view has come to pervade research in soware engineering, where major conferences are now dominated by papers focused on nding and repairing bugs, with barely any discussion of specications.

Eliminating bugs is not the key to improving soware. Of course, soware that is riddled with bugs is bad. But soware that is supposedly bug-free is not necessarily good. It may still be unusable, unsafe, or insecure.

In short, the argument of this book is that what maers is the fundamental structure of the design, namely the design concepts and their relationship to one another. If you get this structure right, then subsequent development is likely to ow smoothly. If you get it wrong, there's no amount of bug xing and refactoring (short of starting over) that will produce a reliable, maintainable, and usable system.

9. Defect elimination and soware quality. e assumption that defect elimination is the key to beer soware is so widespread that it is rarely questioned (and often not even explicitly articulated). Companies that make soware like the idea of defect elimination because it can be applied incrementally, without major disruptions to their development process or to an oen shaky codebase. Tool vendors promote it because it helps sell their products. Researchers focus on it because it makes their contributions easier to measure, and because they fear being accused of utopianism if they suggest avoiding defects in the rst place.

Defect elimination, however, is not the right focus. Turning a blind eye to egregious defects that can be easily removed is of course unwise. But defects are a symptom and not the cause of low quality. If you don't address the root cause, defects will remain however many you eliminate. And since patches oen increase complexity, a soware system can become more brile and unpredictable the more defects you aempt to remove.

A parable about defect elimination. My family lives in a Victorian house, built in the 1880s. It's a beautiful house and it has served us well. But like any old house, it has needed extensive repairs. e biggest challenge has been to keep water out. When we bought the house, water would seep through cracks in the basement walls when there was a heavy rainfall. And aer a major snowstorm, water would collect in the sots behind the guers, run into the spaces between oors, and eventually drip through the ceilings and walls.

In both cases, the proximate causes were clear, and they have straightforward (although not inexpensive) remedies. To x the basement leaks, you can repair the cracks in the walls, and spray them with a special waterproong sealant. You can also install underground drainage to collect the water behind the walls and pump it out. To x the guer problem, you can install a layer of rubber ice-and-water shield under the shingles at the edge of the roof, so that runo from melting snow and ice is directed away from the roof into the guer.

Aer many years of experimenting with interventions like these, reading advice online, and talking to contractors, we learned the truth. ese kinds of remedies are inadequate (and unnecessary). ey don't actually solve the underlying problem; they just mask it.

A beer strategy is to identify the real cause and to address that. Take the basement water problem. Water enters your house from the outside, so the best way to prevent it from coming in is to keep it away from the house in the rst place. If you grade the land carefully so that it slopes away from the house, and ensure that downspouts from the guers discharge water far enough away from the foundation, there won't be surplus water pressuring the basement walls.

Dealing with snow on the roof is harder. e problem, it turns out—and this will be familiar to those who live in similar snowy climes—is the dreaded "ice dam." If the roof is warm, snow melts where it meets the roof; it then refreezes when the temperature drops, and a layer of ice forms and eventually grows to cover the eaves. When more melting occurs, this ice prevents water from owing away into the guer, and it ows instead under the shingles into the house. e solution, paradoxically, is to keep the roof cold so that the snow melts only when the outside

air becomes warm. To achieve this, you can either vent the roof with a gap below the shingles through which cold air can pass, or (if you're stuck with an old house) install insulation on the inside of the roof to keep heat inside the house and away from the roof.

In summary, both of our problems seemed to be caused by visible defects, such as cracks in the basement walls or small openings in the roof. But these defects were just symptoms, and the real causes were design aws. If a house is designed well (with the land around it well graded, and the roof vented and insulated), water won't come in. Eliminating the visible defects, it turns out, is neither sucient nor necessary. With enough water or ice buildup, even the best roof or basement wall will fail; and if the design is good, small defects will not even be tested.

10. Empiricism in soware research. e move in soware engineering research away from broader and deeper questions to narrower and more technical ones can be traced back, in my view, to eorts to make the eld more empirical. Advocates of empiricism argued (back in the mid-1990s) that the eld would garner more respect and make more eective progress if it adopted more "scientic" standards, with experimentation playing a more central role.

e hoped-for benets did not materialize. Researchers, forced to appease reviewers demanding empirical evidence, turned away from harder questions (especially those whose very formulation is tricky) towards simpler ones that were more amenable to evaluation, and diverted their intellectual eorts to contrived experiments with small sample sizes, oen using students as participants to evaluate tools aimed at more expert programmers.

Raising the bar of evidence may have weeded out weaker papers, but it threw the baby out with the bathwater. No longer are submissions judged on the strength and originality of a paper's intellectual arguments and the compellingness of its examples; "results" are now the sole arbiter of acceptability. It's a sobering thought that the most inuential papers of the eld (such as David Parnas's seminal papers on information hiding and dependencies [115, 116]) could not be published in mainstream conferences today, except in a few more open-minded venues (such as the *Onward!* track of SPLASH).

Similar concerns have been raised in the eld of human computer interaction. Saul Greenberg and Bill Buxton have observed that people not only generate research questions that are easier to evaluate, but also oen rely on scenarios that are cherry-picked to produce good results, thus proving only that an artifact is usable in *some* context (rather than in all contexts, or in the contexts that maer) [48].

e result, they argue, is that more promising and innovative ideas receive less attention.

In an entertaining and revealing book [13], Laurent Bossavit analyzes a number of folklore beliefs about soware—for example, that productivity varies between programmers by a factor of 10, or that prior to agile approaches, soware was developed in a strict and inexible "waterfall" life cycle—and shows them to have no basis. To some, this is evidence in favor of greater emphasis on empirical data. But as Bossavit notes, the real problem lies not in the original papers that are cited in support of such beliefs, but rather in the game of "telephone" that followed, in which a paper's content and message were progressively degraded and misrepresented. e problem therefore is not that the original papers lack compelling data, but that they are not read critically (or indeed at all).

Of course, not *all* empirical studies are suspect. My objections are to an unthinking preference for empirical evaluation over other forms of analysis (inspired my misleading analogies to the hard sciences), and to the assumption that all ideas benet from quantitative assessments. When targeted appropriately and conducted imaginatively, empirical investigations can of course be revealing and valuable.

In the eld of programming languages, for example, it has long been recognized that programming is as much about communicating with other programmers as it is about conveying information to a compiler. But only recently have researchers begun to embrace the idea that programming languages are a human tool, and that questions of usability are fundamental to their design [28].

Jonathan Aldrich, a noted programming languages researcher who is a leader in this new area, has balanced his technical contributions to programming language semantics and theory with careful investigations of the impact of language features on users. A study led by one of his students, for example, analyzed a corpus of open-source programs, conrming that they indeed would have beneted from structural subtyping, a language feature popular in research languages but rarely deployed in practice [98]; another looked at the prevalence of object protocols in code, nding that enough modules used them to make protocol-checking tools worthwhile [9].

11. How concepts aid design thinking. e emergence of design thinking as a popular movement has done much to elevate the role of design in our society and set higher expectations for the design quality of everyday artifacts. It has also inspired many people to think in a more open and creative way about all aspects of their lives, by questioning assumptions, imagining radically new solutions and reevaluating needs.

e "content-free" nature of design thinking—that the processes it advocates are independent of any domain-specic design principles, language, or strategies—makes it a good match for concept design, which can provide the substance for design thinking in the context of soware. In the neednding phase, the idea of concept purposes can be used to rene and structure needs; in divergent, ideation phases, existing concepts can be drawn on, enabling more ambitious and yet more lightweight exploration; and in convergent phases, concepts provide language for recording designs and criteria for evaluation.

Perhaps most importantly, concepts allow a design exploration to be factored into separate explorations, one per concept (or one per purpose that a nascent concept is intended to address), which might proceed sequentially or in parallel. A design thinking project can be sunk by too large a scope that leads, in divergent phases, to an array of design ideas that is too large and unstructured to be amenable to convergence. It would make lile sense, for example, to pursue the design of a healthcare information system as a design thinking problem. By identifying individual concepts and their purposes—for example, the problem of diagnosing conditions, or triaging patients, or scheduling appointments—the design eort can be given some structure, allowing design thinking to be applied in a more granular and focused way.

Some qualms about design thinking. Part of the appeal of design thinking has been its accessibility, and the inclusive message that it sends to all members of an organization encouraging them to engage in design activities. Broadening participation in design is surely a good idea. Time and again, designers have found that engaging with users and community members results in beer designs. For Christopher Alexander, paerns are valuable precisely because, by embodying experience and design wisdom, they make it possible for people without experience to take advantage of it. Accumulated design expertise, in other words, is the basis for democratization.

But this enthusiasm has a downside, and has led to some misapprehensions about design. One gets the impression from the way many design thinking books talk that design is an easy and fun activity in which radically new forms are conjured out of thin air, and that a grounding in a particular design discipline is not only unnecessary but may be an impediment to fresh thinking.

is misrepresents design in several key respects. First, the best designers don't work in a vacuum. ey are steeped in knowledge and experience of prior designs, which they draw on as they imagine new designs. Second, most designs aren't radical new forms, but are subtle modications of existing forms; the genius of design

is more oen in the details, and in how dierent design elements are reconciled, rather than in the novelty of the design as a whole. And third, each design discipline really does call for its own sensibilities. Natasha Jen raised similar concerns about design thinking and its deemphasizing of the role of design criticism in her talk "Design inking Is Bullsh\*t" (and pillories the ubiquity of 3M Post-its as the design tool du jour) [74].

Design in other domains. ere is undeniably a "design mindset" that applies across domains, and my understanding of design has been enriched by many books that are not about soware. My favorites are those describing and diagnosing failures, such as *Why Buildings Fall Down* by Mario Salvadori [93]; *Why Buildings Stand Up* by Mays Levy and Salvadori [133]; Henry Petroski's *To Engineer is Human* [121]; and Charles Perrow's *Normal Accidents* [120].

I have wondered if it would be possible to write such a book about soware failures, but I suspect not, for a simple reason. ese books are appealing because they tell compelling stories of designs gone wrong: a plan that seemed perfect but then failed spectacularly because of an unwarranted assumption, or a aw in execution. When failures of a similar magnitude happen to soware—for example, a security breach that leaks the personal records of millions of people—the diagnosis is invariably that no reasonable safeguards were ever included in the rst place. Without any design rationale for success, there was no reason to imagine that the failure would *not* occur, and there is thus no design story to tell. A story about why companies are not incentivized to design soware more carefully can still be told, but it's about commerce and risk instead.

Sources of inspiration. Seeking inspiration on design from other disciplines, I have been inuenced most by Michael Polanyi's notion of the "operational principle" [125] (introduced to me by Michael Jackson [72]), Nam Suh's independence axiom (from his Axiomatic Design theory in mechanical engineering [137]), and, more amorphously but no less importantly, Christopher Alexander's ideas about form, context and t, and about the role of paerns in design [3, 4, 5].

Books on typography and graphic design oer an enviable collection of design ideas and design theories, and are full of principles, paerns and illustrative design examples, suggesting a model for how to write about design. Traditional texts on typography frequently give prescriptive design guidance; Jan Tschichold's *e Form of the Book* [144], for example, gives a systematic treatment of page layout and advice on how to use dierent ratios in shaping the page and the text block. Most impressive is Robert Bringhurst's *e Elements of Typographic Style* [16], not

only for the quality and quantity of the design advice that it contains, but also for the beautiful demonstration the book itself provides of how successful typographic design can be. Even if the design ideas in these books don't carry over to so ware, they inspire in the recognition that design principles are a good thing, and amplify creativity rather than constraining it.

Soware development has long looked to other domains for inspiration. e best-known example of borrowing from older elds is the idea of reusable components or interchangeable parts, which goes back to Eli Whitney's demonstration to President John Adams in 1801 of a musket assembled from prebuilt components. e demonstration was later proven to have been faked: Whitney had marked the components and they weren't fully interchangeable. Nevertheless, this moment is oen cited as a technological turning point from handcraing to industrial production. e value of components in soware was rst articulated by Doug McIlroy at the 1968 NATO conference that launched the eld of soware engineering [101], and is important in concept design too, with concepts themselves as the reusable components.

12. Formal specication and design. In the 1970s and 1980s, researchers developed a slew of languages for specifying the behavior of soware systems using mathematical logic. Some of these—the so-called "model-based" languages such as Z [136], VDM [75], and B [1]—abstracted away the low-level details of the soware implementation by describing the behavior in terms of actions over abstract states (comprising sets and relations, rather than the objects, classes, and linked lists of code). Others—the so-called "algebraic" languages such as OBJ [45] and Larch [51] went further, and described the behavior without any state at all, using axioms relating observers (actions that reported on the hidden state) to mutators (actions that changed the state).

For the most part, these languages were motivated by the conviction that so ware quality means correctness: that the behavior of a program conforms to its specication. Clearly, without a precise specication, correctness cannot even be judged, let alone e ectively pursued.

And yet, as researchers began to write formal specications, they discovered that the very activity of writing them revealed inconsistencies and confusions in the intended behavior. Far from being a simple maer of recording expectations that were already clear, the act of constructing specications was a powerful design activity in which many of the most critical decisions about a system were made. is is evident, for example, in a book of elegant case studies in the Z language [55], and was articulated as an explicit goal in a beautiful demonstration of the use

of Larch to design the essential properties of a window manager [50]. In the eld of human-computer interaction, Harold imbleby in particular has explored the benets of formal specication, with a chapter in an early book [139] showing how algebraic properties can be applied to user interface actions, and later edited a collection of papers on the role of formal methods in HCI more generally [54].

My own Alloy language (see Note 3) was, from the start, intended for design exploration. It was still a surprise to us to discover as we began to use it that the most useful analyses were oen not assertion checks, in which a design is tested against expected properties, but simulations, in which arbitrary scenarios are generated, prompting the designer to consider unanticipated (and oen pathological) cases.

13. On simplicity and clarity. Pondering Zoom's dominance in the video conferencing market (suddenly enlarged by the new working conditions of the COVID-19 pandemic), tech writer Shira Ovide aributes the company's success to the fact that its soware "just works." As she explains, "Being the rst or even the best at something may not maer." Instead, "Simplicity is the overlooked secret to success." But she recognizes that designing for simplicity is no easy task: "It's the deceptively dicult ticket to riches." [114]

Ovide was unwiingly echoing the views of two of the most famous computer scientists, Tony Hoare and Edsger Dijkstra, both avid proponents of simplicity. Hoare's remarks on simplicity in his Turing Award Lecture [57] have become perhaps the best known quotes in soware engineering. Both criticized excessive complexity in programming language design. e rst, about Algol 68, lamented the rejection of a proposal for a simpler language: "I conclude that there are two ways of constructing a soware design: One way is to make it so simple that there are *obviously* no deciencies and the other way is to make it so complicated that there are no *obvious* deciencies."

e second, about PL/1, noted that simplicity is elusive even when (or perhaps especially when) the resources needed to achieve it are readily available: "At rst I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in soware can be implemented, sold, and even used given enough determination. ere is nothing a mere scientist can say that will stand against the ood of a hundred million dollars. But there is one quality that cannot be purchased in this way—and that is reliability. e price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich nd most hard to pay."

And here's Dijkstra [36]: "e opportunity for simplication is very encouraging, because in all examples that come to mind the simple and elegant systems

tend to be easier and faster to design and get right, more ecient in execution, and much more reliable than the more contrived contraptions that have to be debugged into some degree of acceptability."

Hoare and Dijkstra were concerned more with soware engineering than so ware design (although Dijkstra abhorred the former term and never used it himself), so naturally they see the benet of simplicity primarily for reliability. e benets in the realm of soware design seem even greater, since users have less tolerance for complexity than programmers. My belief is that designing soware with concepts not only results in a beer user experience, but also in more reliable so ware, because clarity in the design leads to clarity in the code.

In Zoom's case, simplicity may not be the only explanation of the company's success: the quality of the video alone partly explains its dominance over competitors such as Skype and Google Hangouts. And, as we will see later, the Zoom app suers from several conceptual design problems.

14. e origins of conceptual models. In a historic paper [25], Stuart Card and Tom Moran summarize their work over the years at Xerox PARC. Although most of the paper describes their pioneering cognitive model (the "human information processor") and its application to designing the primarily physical aspects of user interfaces, they also discuss the role of mental models, and advocate the view that I have adopted that the mental model is not accidental but is to be explicitly *constructed* by the designer through invention of an appropriate conceptual model. As they put it: "It is clear that users aempt to make sense—by building mental models—of the behavior of a system as they use it. If a simple model is not explicitly or implicitly provided, users formulate their own myths about how the system works… [I]f the user is to understand the system, the system has to be designed with an explicit conceptual model that is easy enough for the user to learn. We call this the intended user's model, because it is the model the designer intends the user to learn."

In the preface of the 2002 edition of *Design of Everyday ings* [110], Don Norman lists the most important design principles in his book. First on his list is the *conceptual model*, which he illustrates with the example of a thermostat, and how a user lacking a correct model may set the temperature higher in the vain hope of geing warmer faster. (e other principles on his top-four list are giving feedback to users, imposing constraints to prevent errors, and signaling aordances.) To Norman, however, the conceptual model principle is mainly about communication: that the appearance of a device should convey its conceptual model (for more on this, see the discussion of Norman's refrigerator in Note 54). My view in

this book is closer to Card and Moran's: that the shaping of the conceptual model is itself the primary design challenge, and the problem of conveying it (or, in my terminology, *mapping* the concepts to a concrete user interface) is secondary.

Conceptual models of APIs. Just as a user needs a sound conceptual model to operate soware, so a programmer needs one to incorporate another programmer's code through an API (application programming interface). One study [81] of programmer comprehension of API documentation found that programmers without a basic grasp of the API's concepts struggled even to formulate search queries, or to assess the relevance of the content they found, making eective usage of the API nearly impossible.

Fred Brooks and conceptual integrity. In 1975, Fred Brooks wrote *Mythical Man Month* [17], based on his experience managing the OS/360 project at IBM. e book became a classic, and has been extremely in
uential. One of its key ideas was "conceptual integrity," which Brooks claimed was "the most important consideration in system design." In an aerword to the 1995 anniversary edition, he re
ected on the views he'd expressed in the original edition, notably retracting his opposition to David Parnas's idea of information hiding. In this regard though, his opinion was unchanged: "I am more convinced than ever. Conceptual integrity is central to product quality."

Brooks expressed a similar view in his in
uential *No Silver Bullet* paper [18], in which he divided the challenges of soware development into essence—"the diculties inherent in the nature of soware"—and accident—"those diculties that today aend its production but are not inherent"—and located the essence in the concepts underlying the soware: "e essence of a soware entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. is essence is abstract in that such a conceptual construct is the same under many dierent representations." Furthermore, he argued that developing the conceptual structure is the greater challenge: "I believe the hard part of building soware to be the speci cation, design, and testing of this conceptual construct, not the labor of representing it and testing the delity of the representation."

For Brooks, conceptual integrity requires that the design of the entire system emerge from a single mind. Consistent with this view, in his latest book, *e Design of Design* [19], he de nes "style" as a set of dierent repeated microdecisions, each made the same way whenever it arises. In contrast, in the book that Brooks coauthored on computer architecture [12], the notion of conceptual integrity is given a

brief denition as comprising three essential properties: orthogonality, propriety and generality. Brooks himself seems not to have developed these ideas further, although they have been inspirational to many others (including the author of this book).

e eld of conceptual modeling. ere is in fact an entire subeld of computer science called "conceptual modeling," but its focus is a dierent kind of conceptual model. Here, the model captures entities and relationships in the real world; the term "conceptual" is used to distinguish the representation inside a computer from the external reality. Conceptual models of this sort are used for classical AI reasoning (e.g., in a robot planner), or for dening databases in applications (such as payroll, or indeed almost any kind of information system) that maintain data about the real world. Another, more recent, focus has been to capture the structure of knowledge in the World Wide Web.

At its heart, conceptual modeling is a descriptive endeavor. As John Mylopoulos, one of the leaders of the eld explains: "Conceptual modelling is the activity of formally describing some aspects of the physical and social world around us for purposes of understanding and communication" [105]. In contrast, this book is about design and invention; description, while vital, is not an end in itself.

Conceptual models themselves are thus usually data models (also called semantic ontologies) that express the fundamental elements of a problem domain and their relationships. In database development, such data models are contrasted with database schemas, which specify not only these problem domain aspects but also how they are represented in the database (for example, as a collection of tables). e most popular data model used in conceptual modeling is the entity-relationship (ER) model. e ER model itself was developed by Peter Chen in 1976 [27] as a stepping stone in database design, and was hugely inuential. Other models (for example, the Semantic Data Model [52]) oered richer features, but few of these were taken up, with one notable exception: the ability to specify that one entity is a subset of another. With this feature added, the model is known as the "extended entity-relationship model," and is the basis for the notation used in the Unied Modeling Language.

Surprisingly, the eld does not seem to have reached consensus on what exactly a concept is; the word seems to be used only in its adjectival form. As a recent paper [117] puts it rather stridently: "e conceptual modelling community not only has no clear, general agreement on what its models model, it also has no clear picture of what the available options and their implications are. One common claim is

that models represent concepts, but there is no clear articulation of what the concepts are."

Most researchers would probably point to the entities in a conceptual model as comprising the "concepts." is would align the concepts of conceptual models with the concepts of formal concept analysis, which organizes concepts into a lattice (essentially a taxonomy in which a concept can have more than one parent). In this view, the associations of a conceptual model express relationships between concepts.

But a distinction between concepts and relationships is not tenable, and depends on how the model is constructed. A conceptual model of a restaurant reservation system, for example, might have an entity called *reservation*, associated with other entities such as the table being reserved and the customer making the reservation. On the other hand, reservations might instead be encoded as an association between customers and tables. One reason to prefer treating a reservation as an entity is that aributes, such as the date of the reservation, can be added. But some modeling languages (including the original ER model) allow associations to have aributes too, so that consideration evaporates. Either way, it seems clear that a denition of concept that distinguishes entities from relationships is on shaky ground.

A larger problem with this approach (identifying elements of the data model as concepts) is a lack of structure in the model, without which concepts proliferate. If every entity or relationship in a conceptual model is a concept, then presumably the start and end times of a reservation are concepts too. To nd a practical notion of concept in a conceptual model, I believe we need to break the model into pieces, grouping multiple entities and relationships together. is is what my concepts do: all the elements that support the booking of reservations become part of the *reservation* concept, with its own localized data model.

Fowler's analysis paerns. My concepts are closer to (and were inuenced by) Martin Fowler's "analysis paerns" [42], which are small, reusable conceptual models. An important dierence is that concepts are primarily behavioral; their structure supports the behavior by identifying what needs to be remembered (in the state of the running concept) to produce the behavior. Fowler brings in behavior by moving towards the code, and showing methods associated with classes. As we will see, this isn't necessary, and behavior can be specied in an implementation-independent way.

Domains, data models and domain-driven design. A related idea is "domain modeling," which advocates using a model of the problem domain as the basis for developing a soware system. An early approach to soware development that relied on explicit modeling of the problem domain is Michael Jackson's JSD [68]. In JSD, each entity of the problem domain is modeled as a context-free grammar capturing the possible sequences of events in the life of the entity. System functions are dened in terms of the model, and an implementation is obtained by a systematic transformation of the model and system functions.

Object-oriented approaches also advocated modeling of the problem domain, although objects turned out to be too polluted with implementation decisions to be useful modeling constructs. e Object Modeling Technique [131] found an elegant way to square an object-based implementation with more faithful modeling: an entity-relationship domain model is constructed rst, and then (in a similar spirit to JSD) is transformed into object structures.

A popular book by Eric Evans entitled *Domain Driven Design* [38] has brought domain models to practitioners, breathing new life into an old idea. In addition to domain modeling, the book renews other important but neglected ideas, such as the distinction between "entity" and "value" objects [96], the idea of a layered architecture in which a lower layer provides a language for a higher layer [32], and the importance for teams of using common terminology [151]. One key respect in which the book extends traditional approaches to domain modeling is the idea of *bounded context*: that dierent (and even incompatible) domain models may be needed for dierent areas of functionality and parts of an organization. Concept design takes this a step further, with each concept holding its relevant part of the data model.

A similar decomposition of the problem domain into distinct subdomains plays a role in Michael Jackson's problem frames [70], which structure requirements as archetypal paerns that capture the relationships between phenomena within the system being built and phenomena in the domains with which the system interacts. In his most recent work [71], Jackson describes a system as a collection of "triplets." Each triplet consists of a machine (a program that executes on a computer); a portion of the governed world that the machine interacts with; and a behavior that results from the interaction. His approach is notable because it allows each machine to work with a *dierent* model of the governed world, recognizing that for dierent kinds of behaviors, dierent aspects of the world will be relevant (and dierent approximations will be acceptable). His machines are less granular than concepts, but like concepts they have their own data model and dynamics.

Other researchers have explored domain modeling as the basis for requirements: Dines Bjørner, in particular, placed such emphasis on domain modeling that he referred to it as "domain engineering" [10].

Concepts in computer system design. e eld of computer science known as "systems," which is focused primarily on the design of infrastructural components (such as networks, le systems, etc.), tends to be case-based, with more focus on breakthrough ideas than on systematizing the variety of possible designs. Notable exceptions are the textbook by Jerry Saltzer and Frans Kaashoek [132], which identies design themes that are close in some respects to my concepts (and whose chapter on naming, in particular, inuenced my ideas), and the course notes on system design by Butler Lampson [86], which shows how the behavior of complex components (such as distributed memory) can be characterized by precise (and oen surprisingly weak) specications.

## *Chapter 2: Discovering Concepts*

15. e Unix origins of Dropbox's folder concept. Dropbox adopted the concept of *folder* from the Unix operating system, in which a folder is called a *directory*. is design has many elegant aspects. In particular, since the names of les and directories are *not* treated as metadata but are simply contained within directory entries, there is no need for any additional structure in the le system for maintaining this information; directories can be represented with data blocks just like les, albeit with a special interpretation.

Allowing a le or directory to have more than one parent, a feature of Dropbox adopted from Unix (and essential for expressing sharing), is powerful but even in the single-user Unix seing brings some nasty complications. Deletion of a le does not simply eliminate it, but rather deletes a directory entry—and the le might still be linked through another directory. Consequently, reclaiming storage requires a form of garbage collection to identify inaccessible les.

From the user's perspective, the possibility of multiple parents produces at least three other surprises. First, novice Unix users, expecting a folder to "contain" other les and folders (rather than just containing named links), look in vain to nd an option for the directory-listing command that tells you how big a directory is that is, how much disk space it occupies. Such an option does not exist, arguably for good reason (since a le can have two parent folders, so it's not clear how the le's space consumption should be assigned). Instead you need to use a dierent command (called *du*, for "disk usage") which, in classic Unix style, will generate by default a report of sizes of all reachable directories without specifying the unit of

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

fig. E.1 *Results of a survey testing understanding of Dropbox amongst computer science undergraduates at MIT: the bars show the proportion of correct answers to two questions.* 

measurement! Needless to say, only computer scientists would tolerate such unusable soware, so when the Unix le system was adopted by Apple for the Macintosh, this was all hidden away, and the Finder displays folder sizes as expected.

A second surprise, which is harder to work around, and becomes a serious problem, is that changing the name of a le is indistinguishable from deleting it from a directory and then adding it back again under the new name. Tools built on top of Unix for synchronizing les across machines therefore can't tell when a le is renamed that it's the same le, and not a new one that happens to have the same contents. is makes it impossible to reliably track the history of changes to a le. If a new le has the same contents as an old le with a dierent name, was the le just renamed or was the old le deleted and a new one created that happens to have the same contents? e Git version control system, for example, guesses that the le was renamed if the le is large, on the grounds that it's less likely in that case that you'd create a new le with identical contents! Dropbox doesn't suer from this problem because, unlike Git, it can see the action in which the user renames the le, and even if the le system is Unix-based, it can interpret that renaming in its own, non-Unixy, way.

A third surprise is that someone who has no permission to read or write a le may still be able to move it and change its name, since those actions are applied to a directory containing it, and not to the le itself.

is *folder* concept is perhaps one of the oldest concepts in computer science. It was actually invented in the late 1960s—in the predecessor to the lab I now work

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

fig. E.2 *Warning message displayed by Dropbox app aer a shared folder has been deleted.* 

in at MIT—as part of an operating system called Multics. e exibility of having more than one parent was only partly present in Multics, which had two distinct ways in which one directory could refer to another. e main references were called "branches," and they always formed a tree. e others were called "links" and were unconstrained. Unix eliminated the distinction, using links (properly called "hard links") in both cases, so that when a le (or directory) is accessible from two or more directories, the situation is completely symmetrical.

- 16. An empirical study of Dropbox users. It's not just the technologically unsophisticated who get confused by these concepts. My student Kelly Zhang surveyed about 50 computer science undergraduates at MIT, asking them rst to rate their understanding of Dropbox, and then to predict the eect of deleting a folder in two cases. e results are shown in Figure E.1. e eect of deleting a top-level shared folder (such as *Bella Party*) was understood by less than 60% of those who said they had "good knowledge" of Dropbox, by less than 40% of those with "average knowledge," and by none of those with "poor knowledge." e eect of deleting a folder contained in a shared folder (such as *Bella Plan*) was predicted correctly by about 70% of those with good knowledge, almost 80% of those with average knowledge, and only just over 40% of those with poor knowledge. In short, if you delegated control of your Dropbox to an MIT computer science undergraduate, you wouldn't do much beer than if you just tossed a coin to decide what to do.
- 17. Dropbox mitigations. To Dropbox's credit, even if you delete a le by removing the mirrored copy on your desktop (rather than deleting the cloud le more directly through your browser), a warning akin to the browser warning (Figure 2.3) is displayed, as shown in Figure E.2. But this warning is shown *aer*, not before, the le or folder has been deleted, so it's easy to miss.

Dropbox's design also includes a variant of the *trash* concept, explained in Chapter 4, so that les and folders that are deleted are actually moved to a special temporary location and can be retrieved until 30 days have passed, aer which they are lost forever.

- 18. Time to sue Dropbox? Given this chapter's rather critical analysis of Dropbox's design, you may wonder if I'm advocating a class action suit against the company. Far from it. When the Apple Macintosh appeared, one reviewer noted that it was the rst user interface design that was *good* enough to be criticized. Previously, the user interfaces of most computer systems were so inconsistent and arbitrary that no coherent critique was possible. roughout this book, I've picked examples from products made by leading companies, both because they are likely to be familiar to readers, and because they represent the best and not the worst examples of soware design. It would be easy to critique a straw man—an incoherent design by an unknown company. But by focusing on major products, I hope to convince you that concept design has value even for companies that seem to have nearly unlimited resources and that employ the most talented designers and engineers. If concept design can reveal serious aws even in their products, imagine how much more useful it can be for the long tail of smaller and less well resourced companies.
- 19. Levels of UX design for soware. In the late 1970s, James Foley and Andries van Dam identied four levels: lexical, syntactic, semantic and conceptual [41]. ese levels reected the structure of the implementation; indeed, the rst three correspond exactly to the classic compiler structure that had emerged in the prior decade. In contrast, my levels reect design concerns. A red buon, for example, would sit at their lexical level, but in my analysis might invoke design questions at both the physical level (will color-blind users see it clearly?) and the linguistic level (does red mean stop?). e behavior of the buon would be placed at their semantic level, but where it goes in my scheme would depend on whether the pressing of the buon is conceptually signicant (a moderator rejecting a post, for example) or not (aborting a slow query, say). And despite similar terminology, their conceptual level is dierent from mine. eirs is concerned with the user's mental model, and focuses on goals rather than details of behavior; mine embodies the essential behavior that comprises the shared understanding of user and designer alike.

Tom Moran proposed a three-level scheme that is much closer to mine, but like Foley and van Dam's, also more inuenced by implementation structure [103]. At the boom, he places the *physical component*, which handles devices and user interface layouts; in the middle, the *communication component*, which involves interactions (such as key presses) and the syntax of the command language; and at the top, the *conceptual component*, which comprises tasks and their meanings. What is physical to Moran depends on the computer; in my scheme it depends on the perceptions of the human user. Many design aspects are like the redness of the buon and have both physical and linguistic aspects: just consider how links are signaled

on web pages by underlining text or coloring it blue. On the other hand, Moran's conceptual level—unlike Foley and van Dam's—is similar to mine. He divides it into two sublevels, the task level (which expresses the goals of users in terms of the tasks they want to perform) and the semantic level, which comprises a collection of entities with associated operations. e innovation of this book is thus not in identifying the conceptual level but in giving shape to it. As we'll see, we can nd useful structure in the conceptual level by going beyond entities and operations.

Bill Buxton also criticized Foley and van Dam, preferring Moran's levels [24]. He argued for more explicit consideration of "pragmatics," by which he meant the aspects of design that correspond to basic human interactions. He noted that our ability to perform mental chunking, for example, may determine how complex a command grammar can be tolerated. In the schemes of both Moran and Foley/van Dam, syntax occupies the middle level. In my scheme, in line with Buxton's view, this particular question would be placed at the physical level, because—like perceptual fusion—it belongs more to the user's cognitive rather than the linguistic characteristics.

Ignoring UX levels. Some authors treat the user's experience of a system's interface as a single, integrated entity, and do not distinguish levels. omas Green, for example, in his rst paper on "cognitive dimensions of notations" [46] presents the slogan "system = notation + environment" precisely to suggest that the underlying semantics of the notation and the tool in which it is embedded are inseparable.

To the extent that a designer can mitigate aws in the notation proper by more elaborate tool support (for example, functions to display otherwise hidden dependencies), this observation is helpful. But it runs counter to the fundamental premise of this book: namely that separation of levels allows for greater clarity and eectiveness in design, and that deep aws at the conceptual level cannot be remedied by linguistic and physical band-aids. For designing a notation, this would mean at the very least distinguishing between semantics, abstract syntax and concrete syntax, which (surprisingly) Green does not do.

Finding semantics in usability. If you detected in my three-level classication a desire to emphasize semantics over syntax, you'd be correct. As one colleague quipped, parodying our eld's tendency to favor one over the other: in computer science, the term "semantic" usually just means "beer." is is a lile unfair, and I certainly recognize the critical importance of physical and linguistic design, and especially the way in which subtle choices of type, color, layout and language can

impact the emotional experience of the user. But it would not be too reductionist to say that this book is, to a large degree, an aempt to nd semantics in usability.

20. e dystopia of Terminal World. David Rose [130] describes a dystopia that he calls Terminal World in which every interaction we have with a physical object is through a glass slab and glowing pixels. Bret Victor has also railed against the limitations of devices that use the human hand for input but allow only pointing and sliding [146].

e concerns of the physical level would apply even in Terminal World, but they become more interesting when physical interactions are enriched. Although phones and computers seem (largely due to Apple) to be carrying us inexorably towards Rose's dystopia, in other areas of design, resistance to the universal interface seems to be growing. Users are tired of menus and clicking, and prefer more tactile experiences. Some camera manufacturers (notably Fujilm and Leica) have preserved classic mechanical designs in their digital cameras, with enough knobs and dials that adjustments can be made without looking at a screen. For many photographers, this feature alone makes such cameras preferable to others with more elaborate features.

21. Fis's Law and "physical" capabilities more generally. Another example of a UX design principle grounded in the physical capabilities of the human users is Fis's Law, which predicts the amount of time it takes to move a pointing device to a target. Simplifying, the time varies inversely with the width of the target, because if the target is small, the user has to slow down and might have to move back and forth to nd exactly the right position.

A classic application of Fis's Law demonstrates the superiority of the menu design in macOS to that of Windows. In the macOS design, the menu items at the top of the desktop present an eectively innite width: the mouse sticks as you attempt to move it past the desktop boundary. Consequently, opening a menu is faster and easier than in Windows.

Note that the physical level of design accounts for "physical" capabilities of users in the broadest sense; it includes cognitive aspects such as the user's memory capacity. e classic work on the physical level of user interface design is *e Psychology of Human-Computer Interaction* [26], which bases a theory of interface design on an explicit model of the human user as an information processor, with parameters for reaction time, memory capacity, etc. e book actually derives Fis's Law from this model.

- 22. Risks of linguistic misinterpretation. e icon I've used in Figure 2.5 to represent the linguistic level is a British trac sign warning drivers of road works ahead, affectionately known as "man having trouble opening umbrella," illustrating the risks of unexpected interpretations at this level.
- 23. Redundant functionality, bloat and discoverability. It's rare for apps to lack features that their users desperately need. When this happens, the users complain (or go elsewhere), and developers respond accordingly. Having too many features, or features that are too complex, is a more real concern. A mantra of agile programming is to build "e Simplest ing at Works." Another reminds you when considering complex functionality that "You Aren't Going to Need It" (abbreviated YAGNI). e wisdom in these slogans reects the painful experience of many soware teams that the most ambitious, and seemingly essential, features oen consume the lion's share of eort and end up not being used at all. On the other hand, the complaint that some very successful apps are "bloated" fails to recognize that while it may be true that only 20% of an app's functionality is essential, that 20% may be dierent for dierent users.

e ip side of YAGNI is the recognition that for any particular purpose, you *are* likely to need the complexity that others have found necessary in fullling it. So don't try to build authentication and imagine that you don't need to let users reset their forgoen passwords; or build a shopping cart in which you can't change the count of each item at the last minute; or design almost any professional app without oering presets to store and recall complex seings.

e only way to know what users are likely to need is through experience. Concepts help because their design embodies experience accumulated across many applications in many dierent contexts. So when you're designing your authentication mechanism, for example, you should select from established concepts and not be tempted to roll your own. at way, you won't stray too far in either direction (of excessive complexity or inadequate functionality), and you won't introduce a critical security vulnerability.

Discoverability is a real issue. My favorite example of a concept that took me years to discover: Apple Keynote's *object list view* (introduced in Keynote 7.1, March 2017), which shows the objects on a slide in a tree and allows you to make cross-cuing selections, so you can alter formaing, animations, and so on arbitrarily, without the constraints imposed by layers and groups. PowerPoint has a similar concept called *selection pane* which was introduced earlier (in the 2007 version) but apparently also went unnoticed for years by many users (as indicated by a rhapsodic review in a blog post dated 2013).

I suspect that an increasingly common reason that some features go unnoticed is that they are not accessible through keyboard or menu commands. Menus, despite being old-fashioned and a source of visual cluer, at least have the benet that they can be easily scanned for available actions. As interfaces have become increasingly visual and less textual, they have become harder to explore. I wonder, for example, how many users of Apple Preview (a PDF viewing and editing app) know that PDF documents can be merged by dragging thumbnails from one window to another, or that an Apple Keynote presentation can be made from a set of photos by dragging the selected le icons to the slide navigator window.

24. Conceptual models of varying degrees of sophistication. Sometimes, the same app or system can be viewed at varying degrees of sophistication. is happens less oen than you might imagine, because in well designed apps the designer's concept is only as complex as it needs to be to support the intended purpose, and a user who fails to grasp the concept won't be able to use it eectively. A concept may have behavioral details that a user is not familiar with, but these are rarely an impediment to usability, and can oen be learned on the y.

Such varying degrees of conceptual understanding tend to appear when a concept represents a mechanism that is hidden from most users, but may become visible either if a user's activities extend into a new realm, or if failures occur. Someone browsing the web, for example, may imagine that *amazon.com* is the name of a machine that is owned by Amazon, and that typing this name into the bar at the top of the browser, and subsequently interacting with the pages returned, causes the browser to contact this machine, sending it queries and receiving responses back. While oversimplied, this view is sucient to use a browser eectively most of the time, and might be formalized as a *web service* concept. In particular, it allows a user to understand who might have access to data that is entered into the browser.

In contrast, a user who doesn't even have a model that distinguishes the servers owned by dierent companies won't be able to understand why entering private data is safer on some sites than others, and arguably has a conceptual model that is simply incorrect. In a survey of users' models of the Internet, one user responded to a question about where data goes as follows: "I think it goes everywhere. Information just goes, we'll say like the Earth. I think everybody has access."[77]

A richer conceptual model would recognize that Internet servers do not have intrinsic, symbolic names, and that a name appearing in a web query is rst resolved by a domain name server (DNS) that translates the domain name to an IP address. e *domain name* concept is needed to explain why, when a new name is assigned to a server, the name might not be immediately available (since the DNS