softwaredesign/raw/book/EssenceOfSoftware_Eng/concepts-271-300/concepts-271-300.md

agnose problems between the client and server. (See: hps://thoughtsofanidlemind.com/2012/08/29/outlook-sync-issue)

Poor synergies are oen examples of a violation of the specicity principle (Chapter 9) in which a concept is overloaded with multiple purposes. In the Outlook example, the message folder is given a new purpose (storing synchronization logs) that is distinct from, and incompatible with, that of classifying messages.

74. A Google mystery due to over-synchronization. I myself was a hapless victim of this strange synchronization aw. While I was working on this book, I wanted to experiment with Gmail to explore some design issues. So I created a couple of Gmail accounts for ctitious characters named Alice, Bob, and Carol. Sometime later, I noticed that my display name in all my Google apps (in Google Drive, Google Groups, etc.) had switched from Daniel to Alice.

Eventually I gured out what had happened. I had inadvertently created one of the ctitious Gmail accounts in the context of my primary Google account. is had reset my username to "Alice Abalone"—a name that I once thought funny, but since becoming my ocial name in every professional context in which I used my Google account, was distinctly unamusing.

Amazingly, the change was irreversible. Unable to undo it, I was forced to create a new Google account and switch all my memberships to it. is experience occurred in 2018; hopefully it's been xed since.

75. Adobe reverts an update. is story highlights some of the dicult design tradeos the Lightroom team faced. While expert users were upset to lose some synchronizations, the developers had reasonably been concerned for less sophisticated users about the extra complexity of the preference seings that controlled the synchronizations.

In a rather remarkable and humble blog post, Tom Hogarty, the head of the Lightroom development team wrote: "We plan to restore the old import experience in our next update… I'd like to personally apologize for the quality of the Lightroom 6.2 release we shipped on Monday. e simplication of the import experience was also handled poorly. Our customers, educators and research team have been clear on this topic: e import experience in Lightroom is daunting. It's a step that every customer must successfully take in order to use the product and overwhelming customers with every option in a single screen was not a tenable path forward. We made decisions on sensible defaults and placed many of the controls behind a seings panel. At the same time we removed some of our very low usage features to further reduce complexity and improve quality."

Somewhat surprisingly, one of the most frequent and anguished complaints was that Adobe had eliminated the synchronization that allowed the ash card or external drive holding the source images to be ejected automatically when the import was complete.

You might have imagined that this was not a major design issue. Aer all, a user could always eject the card manually in a couple of clicks. It turned out, however, that for many professional users this additional step made the task of uploading photos from a large number of cards feel more burdensome. Complainers also noted that automatically ejecting the card prevents accidental deletions from the card. is entire episode fascinated me: it was a very rare case of a company reverting a change, and an interesting illustration of how sensitive users can be to seemingly small design decisions. Lightroom also happens to be, in my view, one of the very best apps ever.

It should be noted that the update also introduced a bug that was not resolved prior to release; the presence of this bug was also undoubtedly part of the reason for reverting the change. (See: hps://blogs.adobe.com/lightroomjournal/2015/10/lightroom-6-2-release-update-and-apology.html)

• 76. Under-synchronization in Google Forms. e lack of synchronization between the visualization and the spreadsheet associated with a Google Form has caught me out a few times. I've oen created an anonymous survey, and included at the end an opportunity for responders to add a comment and an email address if they'd like a reply. e submied email addresses then appear in the summary visualization, compromising their anonymity, but removing them manually from the spreadsheet has no eect. I am thus prevented from sharing the summary with a community that submied data that was anonymous in every other respect.
• 77. Another synchronization issue in Zoom. e zoom session concept allows a single identier to be used for multiple conversations that occur at dierent times. e Zoom web portal synchronizes this concept with a conventional calendar event, so when you create a session, you are prompted to specify a date and time for it, or a recurring series of dates and times. is synchronization is more complicated than it seems, however. A zoom session may have a limit on the number of times it may recur, and will expire if the time between recurrences exceeds some bound. Confusingly, a session scheduled as a single event can recur just like a session scheduled as a recurring event, albeit with a shorter expiry (30 days rather than 365 days). Sessions scheduled as a one-time or recurring event can recur at most 50 times, unless they are scheduled as "recurring events with no xed time," in which case there is

no limit. My guess is that this synchronization is designed to balance the resource cost of storing session identiers with the desire to give exibility to users, but I wonder if it might be accomplished in a simpler way (for example, by listing all unexpired sessions owned by a user in their prole, and encouraging them to delete the ones they do not intend to use again).

78. Lessons from the erac-25. Nancy Leveson and Clark Turner provided a thorough account and analysis of the erac-25 accidents [92]. Shockingly, the synchronization aw that I described (and which is explained more fully in the paper) was not discovered aer the rst accident, which was aributed instead to a hardware glitch; the failure to investigate the accident properly led to multiple additional accidents before it was nally diagnosed correctly.

Leveson and Turner rightly note that accidents like this happen due to a complex web of missteps, and that it is naive to imagine that soware will ever be free of bugs. Nevertheless, the synchronization aw was indeed the proximate cause of the accidents. e only path to safety (or security) for soware-intensive systems runs through simplicity of design, which means using robust concepts whose mis ts are well understood (see "Concepts Ensure Safety and Security" in Chapter 3; "Mists: When Purposes Aren't Fullled" in Chapter 5; and Notes 60 and 61).

Chapter 7: Concept Dependence

79. New concepts must address real problems. To counter the tendency to complicate a design with unnecessary concepts, each time you are tempted to add a new concept, a good question to ask is: what problem with the existing design does this new concept solve?

Here are two examples. Netix added the profile concept to its movie-viewing app in 2013, six years aer it began online streaming. e problem was straightforward. Dierent family members watched dierent movies on the same account, which messed up both recommendations (since my recommendations were based on your prior selections) and placemarks (since my watching a movie cleared the memory that you'd watched only half of it). e profile concept nicely solves all these problems by giving each family member essentially their own account contained in one larger account for billing purposes.

e Netix prole concept is really just a second instantiation of the user concept in the same app, and thus an example of synergy. Proles even include a rudimentary form of authentication: the account owner can add a PIN to control access to a prole. is allows the proles to be used also for parental control of a child's viewing, by limiting a prole to movies with certain ratings. Apparently, customers

also use proles as roles: dening, for example, a "documentary" prole and a "date night" prole to keep movie lists and recommendations separate.

Apple's slide presentation app, Keynote, added the style concept about ten years aer the rst release. Keynote already had a master concept that allows you to create master slides that dene the styling of a slide's heading, text levels, etc., so a style concept might seem unnecessary. Presumably this is why Microso PowerPoint still has no style concept. In fact, though, the master concept is insucient. It won't let you dene a style for things like quotations (which don't occupy a xed level in a master slide) or indeed any text that appears outside the text body of a master slide; nor does it allow you to maintain consistency across masters (e.g., with a single heading style).

• 80. An example of concept as dierentiator. e identification concept is what I called a dierentiator in Chapter 3: a novel concept that the designer hopes will not only be the linchpin of the product but will also dierentiate it from competitors. As I noted there, the dierentiator may be a technological tour de force: examples are Adobe Photoshop's layer concept (which allows non-destructive editing of images), Google Slides's auto caption (which generates remarkably accurate captioning on the y), and WhatsApp's call (which gives users free phone calls that require little enough bandwidth that they can run over cellular networks). But dierentiators can also be, like our identification concept, neither especially subtle nor technologically complex—consider the Tiktok app, for example, whose very successful dierentiator is the simple shared song concept, which allows users to create videos based on the soundtracks of other users' videos.
• 81. Parnas's dependence diagram. My dependence diagram is inspired by the work of David Parnas, but diers from it in some key respects. e original idea of dependencies was introduced by Parnas in his seminal paper "Designing soware for ease of extension and contraction" [116], where he calls it the "uses relation."

e dependencies are dened by the code itself, so whether A depends on B is determined by how A is wrien (and whether, for example, it includes a call to B). Roughly, A depends on B if the correct execution of A relies on the correct execution of B. e consistent subsets that dene the product line then follow from this denition, because if A relies on B, a subset that includes A but not B will simply not execute properly.

Parnas's proposed strategy is to design the code to have the desired impact in the product line. His methodological principle is this: you should design A to use

B only if you can't imagine a subset that includes A but not B, and furthermore, the use of B should make A easier to build.

Rening Parnas's dependencies. In an early paper of mine, I explained why conventional notions of dependence are not sucient and may not even make sense [63]. Parnas, to his credit, had foreseen many of these issues, and notes in his original paper, for example, that A calling B is neither necessary nor sucient for A depending on B. But despite widespread use of the idea of dependencies, these issues have never been fully resolved. More recently, Jimmy Koppel and I proposed a new model of dependence [84] that overcomes some of the problems I raised there (and more), basing the notion of dependence on counterfactual causality.

Concept dependencies vs. code dependencies. Concept dependencies are similar to Parnas dependencies in dening possible subsets, so that the concept dependence diagram (like Parnas's uses relation) characterizes not one application but an entire family.

But concept dependencies dier in a key respect. Concepts are always freestanding and never rely on other concepts for their correct operation. Whereas a code module's dependence is induced by its inherent nature—namely the code inside it, and the calls it makes to other modules—a concept's dependence is a result only of the context of usage.

Concept dependencies are thus more subjective, and embody the designer's assumptions about what makes a consistent app. For the bird song app, maybe you thought it was preposterous to even consider an app with questions and answers but without user authentication. In that case, your dependence diagram would include not only a dependence of user on q&a, but also a dependence of q&a on user, ensuring that any app regarded as consistent include both concepts.

is freedom to use dependencies as a way to express design options comes from the fact that the connections between concepts are expressed in a synchronization when the concepts are composed, and not in the concepts themselves. It also means that removing a concept that is not needed for consistency may involve an adjustment to the synchronizations; for Parnas, in contrast, a module on which a subset does not depend can (theoretically) be simply deleted, and the subset recompiled without it.

In summary: for Parnas, the subsets follow from a more basic notion of dependence; for concepts, the subsets dene dependence.

Does object-orientation violate the dependence principle? Parnas's methodological principle (see above) is oen violated. Worse, these violations may be in-

herent to the way we program, especially in object-oriented code: our most common and familiar idioms seem even to militate against Parnas's principle.

Imagine that you're implementing a forum that includes a post concept and a comment concept, in a language like Java. What would be the standard object-oriented way to implement these concepts? You'd have Post and Comment classes, with the Post class oering methods such as addComment and getComments. is would induce a dependence (in Parnas's terms) of Post on Comment.

Now consider the subsets that you'd like your codebase to support. Obviously, it makes sense to have posts without comments, but not to have comments without posts. So the dependence diagram should show a dependence of Comment on Post—just as the concept dependence diagram would show a dependence of the comment concept on the post concept. So the dependence is the wrong way round, and object-oriented programming seems to have led us to a structure that's upside-down.

How did this happen? e root of this problem is that object-oriented programs are usually structured around control ow. Because the user interface will need to nd the comments associated with a post when the post is displayed—and oer a buon next to a post to add a comment—it is natural to want to include commenting functionality inside the Post class.

In fact, the principles of object-oriented programming make it hard to do anything else. We could give the Comment class an internal table that maps posts to comments to support a method like getComments, but this time inside Comment rather than Post, so it would take a post as an argument. Such a table would violate the o-quoted rule that static state is inimical to object orientation, and classes should not have static components. Another option might be to create a separate class, Forum say, that contains tables mapping posts to comments and vice versa. Using such a class would violate other object-oriented principles, however. For example, the fact that a method would need to call a method of Forum to obtain a list of comments on a post, and then call their methods to display them, would violate the Law of Demeter [94].

is suggests to me that new programming idioms are needed in which concepts are supported in a more direct and modular fashion in the code. It's not just about dependencies, but also about how the code is organized. Note that in the rst object-oriented idiom that I suggested—the naive one that every novice would use, in which Post has an addComment method—the implementation of the comment concept is unfortunately split across classes, since the Post class includes the mapping between posts and comments, a structure that belongs to the comment

concept and not to the post concept. A code structure more faithful to the concept design would instead isolate each concept within its own module.

• 82. Dependencies emerge from detailed design. Dependencies rely on quite deep knowledge of the design. In BirdSong 0.1, it's possible that the individual identi cations could be upvoted: maybe if an answer said "at's an #american-goldnch or a #lesser-goldnch" users could upvote the two identication tags separately. Or maybe users could also upvote recordings just to say they like them. If so, these would produce additional dependencies (of upvote on recording and identification too).
• 83. A note about primary and secondary dependencies. A subset might still form a consistent app if a secondary dependence (a doed edge) points out of the subset, or if a primary dependence (a solid edge) points out but a secondary dependence is included.

is reects the following interpretation of dependencies: each concept depends on all of the primary dependees, or on any one of the secondary dependees. A richer notation would let you express fully general dependencies: that a concept depends on a set C of sets of concepts Ci , with the dependence satised if whenever the concept is included there is at least a set of concepts that covers one of the Ci . (is corresponds to a disjunctive normal form, and could express any logical combination of dependencies.)

Feature diagrams. A feature diagram [76] is usually an and/or tree showing the features of a product family, and the combinations that are legal. In terms of specifying combinations, it's comparable to this richer notation (and thus more expressive than my basic diagram). But it doesn't express dependencies directly, so it's less useful from a design point of view.

84. Facebook's concepts. e dependence diagram simplies the concepts of Facebook and their relationships. e friend concept has a second purpose, namely to lter which posts a user sees; this is technically an overloading (as explained in Chapter 9).

In Facebook, you can tag a photo to say who's in it (a feature introduced in December 2005), but you can also tag a post or a comment (September 2009). To simplify, I've le the photo concept out of the diagram.

Facebook introduced the reply concept in March 2013. Previously, a user could not respond to a comment without adding another comment at the end of the comment list, losing context. Replies introduced threading, so that users could respond directly to a comment. Arguably, reply was not a distinct concept from comment, but rather an enrichment of the comment concept to allow comments not only

on posts but also on comments. To represent this in the diagram, we could just give reply the new name threaded comment, and remove its dependence on comment, making it clear that a subset could choose one of the two options: at comments or threaded comments.

e like concept was introduced in February 2009, ve years aer Facebook's debut. It's now hard to imagine any social media app without an upvote or like or reaction concept, since these concepts are so central to two insidious aspects of the platforms: the psychological stimulus of small rewards that has addictive eect on users, and the value that the platform owner derives from extracting personal information from user preferences.

85. A paradox in Safari's concepts. e private browsing concept is a bit of a paradox at rst sight, but not that puzzling once you understand concept dependencies. It depends on the cookie, because if there were no cookies, there would be no need for a concept of private browsing! at is, a subset with private browsing but not cookie would make no sense. But its very essence is that when private browsing is enabled (in Safari, by opening a private window), cookies aren't used!

Why Safari needs more synergy. My proposed synergy would produce a structure in which favorite, frequently visited and reading list all depend on bookmark and are seen as extensions of its functionality, and not independent variants. e favorite concept is already largely synergistic: favorites are just a predened folder within the bookmark collection. e others, however, are largely disjoint. So you can't organize your reading list into folders, for example—that's a bookmark feature, not a reading list feature—and you can't save regular bookmarks for oine reading. As evidence of the confusion that all these related but incomparable concepts produces, I would point to the many articles online that explain the subtle dierences between them.

86. Keynote's concepts. Keynote actually oers a character style concept as well as a paragraph style concept. e shape style of a shape seems to also store the paragraph style of its rst paragraph.

e choice of which dependence is primary is sometimes a bit arbitrary. For example, animation is given a primary dependence on special block because animations are most oen used to play the bulleted points in a special block. A richer diagrammatic notation that allows multiple dependence sets (without prioritization) could be easily devised but the complexity seems unwarranted (see Note 83).

Two aspects of Keynote's design seem to indicate unresolved design challenges. One is that the transition concept, which governs transitions between slides, is dis-

tinct from the animation concept, leading to some confusion especially when transitions also animate objects (as in the "magic move" transition), and when the presentation is played automatically. e other troublesome aspect revolves around the special block concept, which allows paragraphs to be organized in a hierarchy of levels, but is restricted in various ad hoc ways: there can be only one special "body" block on a slide (and regular text blocks cannot have levels), and special blocks can't be grouped. e rationale for these constraints, I believe, is to allow the text in special blocks to be entered in outline mode. In other words, the special block concept only makes sense because of the outline concept (and thus depends on it).

Chapter 8: Concept Mapping

87. Dark paerns. Harry Brignull, a British user experience designer, coined the term "dark paerns" in 2010 for the recurring motifs that websites employ to deceive their users [15]. Most dark paerns involve mapping of concepts to user interfaces. e "Roach Motel" paern, for example, makes it easy to sign up for something (such as a subscription with a free-trial period) but hard to cancel it.

Usually, the underlying concepts themselves are not implicated. I'm curious to explore, however, whether there are concepts that are themselves designed with ill intent. I have yet to nd a convincing example of such a "dark concept" that is used by legitimate companies. But in the security domain, many aacks (such as phishing, cross-site request forgery, injection, and cross-site scripting) might be regarded as dark concepts.

88. Label mapping in Gmail. One workaround to the label mapping problem in Gmail is simply to switch o the conversation view (via a toggle in the preferences). is is not very satisfying, because then you lose the advantage of the conversation structuring.

In its current design, Gmail shows some messages as collapsed and some as expanded. Initially I hoped this might correspond to which messages have the queried label. But this feature seems to be used in multiple, inconsistent ways including showing the most recent message, showing messages that have been recently modied (e.g., by being starred), and, in the case of the sent message lter, showing messages with that particular label.

Apple Mail has similar issues in the interaction between its conversation concept and its folder concept. But its conversation seing can be turned on and o on a folder-by-folder basis. By default, conversations are turned on for the inbox and o for the sent messages folder, so when you ask to see sent messages, that's all you see. is solution would not work in Gmail because it would not generalize to l-

fig. E.6 Trepanning: a metaphor for small design aws? (om Hieronymus Bosch, e Extraction of the Stone of Madness*).*

tering on label combinations. (e designers of Gmail have tried to combine the advantages of labels and folders by using label actions to emulate folder actions [129], but this example illustrates one of the limitations of that approach.)

89. Small design aws as symptoms of greater pain. A skeptic might complain that many of the design aws that I discuss in this book are relatively minor. In response, I would note rst that limiting my corpus of examples to major products from leading companies introduces a selection bias, and a larger sample that included products earlier in their development, and products from less capable companies, would reveal larger problems.

I also suspect that many of the design aws I have discussed, while seemingly small to the onlooker, might have caused considerable pain to the developers who had to deal with the complications they produced in the code. Some of these aws are thus like trepanning holes, which appear as small defects in exhumed skulls, but are reminders of the pain suered during their formation (Figure E.6).

90. Beer Backblaze strategies. ere are more ecient ways to search for old les. Instead of looking back one day at a time, you could do a binary search. Say you want to nd the latest version of a le before a corruption occurred, and you know the corruption happened sometime between January 1 and March 1. You'd pick February 1 rst; then if that version is corrupted, you'd try January 15; if that version is uncorrupted, you'd try February 15 in the hope of nding a later version.

is would reduce your search from 60 to six steps. You might also exploit the le modication date. If the backup of February 1 shows a modication date of January 5, say, there's no point checking January 15; you might as well check January 5 next.

• 91. Flags versus labels. e flag and label concepts are similar. Flags are usually predened, and mutually exclusive (a maximum of one ag per item). e same ltering conundrum that I describe for ags applies to labels, and indeed, to any concept that involves ltering items by mutable properties.
• 92. e live ltering conundrum in Lightroom. e seemingly obvious mapping for a ltered list of items—in which exactly the items satisfying the lter are displayed—is used in Adobe Lightroom Classic. e usability problems that follow provide a nice case study in the challenges of mapping design.

In Lightroom, a very powerful ltering bar lets you select photos that have been labeled or agged in various ways, or whose metadata has certain properties, such as including particular keywords, or having been converted to black-andwhite. Some of these properties are xed—for example, the metadata properties that identify the camera or the shooting parameters such as aperture and shuer speed—but most of them can be modied by the user. Adopting the simpler form of mapping, namely maintaining the lter results so they always correspond to the lter seing, even as the items are modied, has some unfortunate consequences.

Here are two examples. Suppose you lter a set of photos to show only those that have been converted to black-and-white. You select one of them from the grid of thumbnails, and, intending to explore dierent renderings of the image, you open it in "develop mode." If you exit develop mode, you'll return to the thumbnail view, with the photo still selected. e photo being edited is thus always the currently selected image in the collection.

Now, with the photo open in develop mode, you can adjust the tonality, crop the image, and so on. But suppose you select the option to switch the image to color rather than black-and-white. Lightroom permits this adjustment, but now the photo no longer satises the criterion for membership in the collection. Not only is the photo instantly removed from the collection (invisibly, since you're still in develop mode), but to maintain the invariant that the photo being edited is always the selected photo in the collection, the develop window suddenly goes blank and displays the message "no photo selected." is is disconcerting and extremely inconvenient: you can't change it back to black-and-white because you're no longer even editing the image! Lightroom's wonderful undo facility can rescue you from this state, although interestingly only by returning you to the thumbnail mode.

at example illustrates a problematic interaction when the user makes a mistake (albeit one that is very easy to make). My second example arises in the context of a task that I oen want to perform, and for which, due to this design, I needed to invent a workaround. In Lightroom, you can aach keywords to your images. I do this to identify people in pictures. A common task I want to perform is to check a particular keyword, or perhaps replace it by another one. So let's suppose I keyworded images of my daughter with the keyword "Rebecca" but I want to replace it by the keyword "Becca." So I lter for images carrying the rst (old) keyword; to these, I then add the second (new) keyword in bulk. So far so good. en I remove the old keyword, and all the images disappear, because they no longer carry the keyword of the lter. is is a serious problem, because I want to complete the task by saving the keyword edits in all these photos to their les on disk. Now, without the photos selected, I cannot execute the save command.

(e workaround, incidentally, is to rst lter the photos on the required keyword; then to select all; then to turn o the lter, revealing a larger collection in which the relevant photos are still selected. Now they can be edited in bulk without any disappearing as their keywords are changed.)

Following Apple's design of marking the items in the original ltering with their properties would not work here, since the ltering is more sophisticated (allowing multiple properties to be combined). A solution might be to gray out photos that no longer match the lter aer they have been edited. e user could then easily see which photos satisfy the lter, but can still select those that do not.

93. e selection concept and singleton actions. A similar problem arises with the selection concept, which allows a user to select multiple items and then apply an action to them all in aggregate. is is used, for example, in desktop le managers like the macOS Finder, in which you can select multiple les and then delete them all with one click. If there is an action that can only be applied to a single item, invoking that action when more than one item has been selected is problematic.

One solution is simply to block such actions; the Finder does this if you select two les and then try to apply the rename action. Another solution is for the selection to mark, in addition to the set of items selected, a single item (within the selected set) that will be the target of such actions. In Lightroom, for example, when you select multiple thumbnails, one of them is highlighted with a slightly brighter frame, and there are user interface actions to cycle through the selection, changing which thumbnail plays this role. is approach could be used to resolve the Lightroom collection-deletion ambiguity problem: when you select multiple col-

fig. E.7 What's the dierence between labels and categories? Gmail help isn't too helpful.

lections, one of them would be distinguished. But this solution seems to me to be overkill in this case, and likely to be confusing to users.

Chapter 9: Concept Specicity

• 94. Google's inadvertent humor. Seeking to understand the dierence between labels and categories in Gmail, I looked up "labels" in Google's help documentation. e article began "Labels help you organize your messages into categories…" (Figure E.7).
• 95. Why Zoom has a redundant concept. Why would Zoom's developers have gone to the trouble of creating an extra concept (broadcast) rather than extending an existing one (chat)? My hypothesis is that, rather than aempting to integrate the breakout concept fully into the app, its engineers opted for a quick-and-dirty solution in which each breakout room is treated as a separate Zoom call. is would explain why "everyone" in the chat of a breakout room refers to only the participants in that room, and why the chat messages of a breakout room are lost when the breakout room is closed.
• 96. Apparent redundancy due to distinct purposes. An apparent redundancy between two concepts may disappear on closer examination, turning out to be a re ection of a genuine dierence in purposes. In Adobe Lightroom Classic, the flag and star concepts appear at rst to serve the same purpose: they both let you assign some measure of approval to a photo, and then to lter accordingly.

In fact, however, the two concepts serve dierent purposes. ere are two ag types, "pick" and "rejected," and a dedicated action for deleting all rejected photos. Flags are not saved to the metadata in the photo le itself, so they are intended only

fig. E.8 Nail clippers: with function sharing (le) and without (right) (om [145]).

for temporary use. Stars, on the other hand, range from zero to ve, oer actions to increase and decrease, and can be saved to les.

ese dierences are consistent with the dierent purposes of the two concepts. e flag concept is for selecting and rejecting images as a precursor to deletion; the star concept is for rating images that remain, along with their stars, stored over a longer period.

In an earlier version of Lightroom, ags were collection-specic, so you could have separate collections for printing and web display (for example), with dierent photos agged in each. I suspect that Lightroom's developers dropped this useful feature because it was confusing to some users.

• 97. Concepts in the New Testament. e Gospel of Mahew seems to have preempted the principle that a concept cannot fulll two purposes: "No one can serve two masters. Either you will hate the one and love the other, or you will be devoted to the one and despise the other." [Mahew 6:24]
• 98. Overloading in mechanical design. In the design of mechanical systems, it is common to design a single component to have multiple purposes. e sheet metal body of a car not only provides structural support, but also keeps the weather out, and provides an aerodynamic prole. It also acts as the electrical ground for the car.

Karl Uhrich imagined what a nail clipper would look like if no single component was allowed to provide multiple functions, in contrast to the conventional design in which a single metal strip acts both as a spring (through bending) and a cutter (through its sharpened edge) (Figure E.8).

Mechanical designs, in other words, seem to revel in overloading. But soware is dierent. Overloading can be benecial for mechanical designs because it simplies the design, saves manufacturing costs, and by reducing size and weight, may lead to beer performance. For soware, no such considerations apply; two orthogonal concepts are easier to understand than a single concept that serves in-

compatible purposes, and there is no cost in performance or complexity to a few extra lines of code.

Even in mechanical engineering, overloading can be problematic, and it is advantageous to ensure that dierent purposes are separated into separately controllable design parameters. Axiomatic design [137] is a theory of mechanical design that aims to produce more malleable designs, by ensuring that a change in one functional requirement never requires a change to a design parameter that also in uences another functional requirement.

99. Overloading in social concepts. Some of the principles of concept design seem to apply not only to soware but also to concepts that are executed by people that is to social structures and policies. I've noticed that overloading by false convergence seems to cause problems particularly in policies related to evaluation and feedback.

Many academic departments (including my own) assign mentors to junior faculty. e mentor is supposed to give encouragement, advice and moral support. When it comes time to consider promotion, the mentor is oen one of the rst people asked to comment on the case—on the grounds that they have greater knowledge of the candidate's achievements.

By playing these two roles, however, the mentor is put in an untenable position. What if the candidate has revealed inadequacies and concerns that negatively color the mentor's assessment of whether the promotion should go ahead? ere is a basic conict of interest here, which could be eliminated by excluding the mentor from any promotion decisions, or at least instructing the mentor to act, during promotion discussions, only with the interests of the candidate in mind.

In other words, there are two distinct purposes here—providing support and advice on the one hand and helping to assess the candidate on the other—and they are mutually incompatible. Two dierent roles are needed to serve the two purposes.

e same conict between assessment and guidance arises in the concept of review that conferences use to respond to paper submissions. One purpose of a review is to provide helpful feedback to the author of a paper. A quite dierent purpose is to decide which papers should appear at the conference. A reviewer cannot satisfy both at once. Even if you rate a paper highly, and would like it to be accepted, if you make constructive suggestions pointing out ways in which the paper might be improved, you run the risk of other commiee members using these suggestions as reasons to reject the paper.

To expose such false convergences, you need a clear articulation of the purpose. If the purpose of a submission review is to "review the paper" (merely repeating the name of the concept) or to "solicit expert advice" (which has no value in itself), the issue won't arise. You need to articulate honest and straightforward purposes such as "choose which papers to accept" and "give helpful feedback to authors" to make these conicts apparent.

Another example of overloading in social seings is provided by Kieran Egan whose pedagogical theory [37] starts from the observation that the three conventional purposes of education—socializing students to prevailing norms, teaching them to seek higher truths and transcend prejudices, and helping them fulll their own personal potential—are fundamentally incompatible. Egan insinuates, more generally, that the success of any social institution may rest on the degree to which its purposes are aligned. Prisons, for example, are problematic because their purposes—punishment and rehabilitation—are in direct opposition, and achieving one can only come at the expense of the other.

100. More on Epson's overloading. You might think that the overloading in Epson's printer driver that binds the paper feed seing to the paper size is mitigated by the ability to choose the paper feed in the printer dialog itself.

is is in fact possible, but the Epson driver won't let you pick a value that is incompatible with the value in the paper size seing. Needless to say, this confuses many users, who don't realize that their paper size selection determined the feed choice and are then puzzled that their preferred feed option is grayed out in the dialog. e overloading aw is thus exacerbated by Epson's excessive conservatism in saving the user from errors (explained in the Over Synchronization section of Chapter 6).

101. Overloading in Photoshop's cropping function. For photography acionados, here's a richer example of overloading that was eventually xed by Adobe.

Adobe Photoshop has a cropping concept. Its purpose is to allow you to trim the edges o an image so you can remove unwanted parts of a photograph. e operational principle is: you create a cropping frame within the image whose dimensions and position you can adjust; then if you issue the crop command, the pixels outside the frame are removed.

Or at least that is the operational principle in the current version of the app. Until a few years ago, cropping in Photoshop was much more complicated than this. Let's look in particular at one part of the user interface (Figure E.9).

fig. E.9 Cropping in Photoshop CS5.

Notice that there are elds in which you can enter a width and height for the cropping frame. is supports an important feature: the ability to maintain a xed aspect ratio. If you want to print on paper of a certain shape, or you want to maintain consistency between the images in a portfolio, you might want your image to conform to a particular aspect ratio—such as 2×3.

By using the width and height elds, you can set a xed aspect ratio. As you now adjust the cropping frame, the aspect ratio will be maintained. If you look carefully at these elds, however, you'll notice that the values that are entered include not only the numbers but also the units. In this example, the units are set to inches, so what I've actually specied is not 6×4 but 6 in×4in.

Cropping now has two, independent consequences. One is that you remove the pixels outside the cropping frame. e other is that the new image will be resized to have the given dimensions. If the photo was not 6 in×4 in before, it will be aerwards. at will aect the default printing size in many applications.

But wait, there's yet more complexity! If a resolution is specied in the dialog, the cropping action will preserve the resolution of the le. Since the dimensions in inches are being changed, and the resolution is xed, that means that there will have to be a change in the number of pixels, by either upsampling or downsampling the image.

Suppose the image were 6 in×4 in to start with, and 200 pixels per inch. en the image had 800×1200 = 960,000 pixels. If I crop away half of the image, half the original pixels will be removed. But if both the dimensions and the resolution are to be maintained, the overall pixel count cannot change, so the image will need to be resampled.

One rather surprising consequence of this is that if you dene the cropping frame to include the entire image—that is, with no pixels outside the frame—the cropping action may still modify the le!

e problem here is that there is a separate concept of resampling which has been piggybacked onto the cropping concept. e result is not only a confusingly complicated interface for non-experts, but also the strange inability to set a xed aspect ratio without modifying the image dimensions.

is design aw was xed in Adobe Photoshop CS6 (2012) by teasing apart the two concepts. e features of the resampling concept no longer appear in the dialog for cropping, and there is a new aspect ratio option that allows you to set the aspect ratio in dimensionless units.

102. Recommendation, upvote, and karma concepts. In my analysis of the Facebook like concept, I identied the recommendation concept and not the upvote concept as serving the purpose of curating your newsfeed. e upvote concept aggregates approvals and disapprovals of an item to rank that particular item; this is how newspapers sort reader comments, and forums such as Reddit and Hacker News highlight the most popular posts. e recommendation concept, in contrast, uses approvals of items in the past to predict the relevance of items in the future. It is related to the concept of karma, in which posts in a public forum are ranked according to the reputation of the contributor, measured by aggregating ratings of their prior contributions.

Would my Facebook solution really work? I suggested that the Facebook like concept be split up so that the user has separate control over sending reactions and curating their feed. In Facebook's case, I actually doubt this would help, because the curation algorithm is so opaque that Facebook users don't have any understanding of how posts are selected and ordered in their newsfeed, so they would be unlikely to take the extra trouble of providing separate information for that purpose. Perhaps in a new platform that is more commied to the interests of the user, and less driven by advertising (if such a thing were possible), this division would be useful. I will note also in its defense that it could be mapped to two clicks—one to select

the emotional reaction and one for thumbs up or down—which is no more than the Facebook design currently takes.

A design problem with the upvote concept. e upvote concept suers from an overloading problem in many cases, since it is oen used to signal support or antagonism. is purpose is in conict with the purpose of obtaining accurate measures of approval, but I don't know of any concept split to resolve it, assuming that the vote tally must be public. e problem, by the way, is related to a problem that arises in student evaluations of teachers, in which a small number of angry students submit an articially low rating in order to bring down a teacher's overall average. In my own experience, such cases can be spoed in the response data because such students give the lowest possible rating to every aspect of the teacher and the course, and in their informal comments frequently reveal that they felt unfairly graded.

Chapter 10: Concept Familiarity

103. Normal and radical design. In What Engineers Know and How ey Know It [147], Walter Vincenti distinguishes between "normal" and "radical" design. Normal design involves the renement and extension of an accepted, standard design. A car designer, for example, takes the essential structure for granted: that the car will have four wheels, a conventional gasoline or hybrid engine, a gearbox, etc. Because normal design uses familiar components in familiar ways, and relies on a large body of experience, the designer can be condent that the design will perform as expected.

Radical design is much rarer. It's what NASA's engineers did when they designed the lunar module of Apollo 11. Nobody had ever designed such a thing before, and they could not be sure that it would work at all. In fact, as the lunar module descended, it generated alarms indicating that the computer was overloaded and had to shed some tasks (fortunately not including the ones that were needed to ensure a safe landing).

In soware, the obviously normal designs are the countless "CRUD" applications being built using content-management platforms such as Drupal and WordPress. (Of course, like all normal designs, these were at one time radical.) Radical designs include the rst graphical user interfaces (invented at Xerox PARC and then realized commercially by Apple), the rst spreadsheet (Dan Bricklin's VisiCalc), and the rst relational databases (based on Edgar Codd's design).

In practice, the distinction is not binary, and most designs—including soware applications—lie between the two extremes. Sometimes a design is radical in its

scope and overall purpose, despite the reuse of normal concepts—Tim Berners Lee's invention of the World Wide Web, for example, which exploited decades-old concepts (notably hypertext and markup) to dramatic new eect. Sometimes a design is not radical in its purpose but introduces concepts that change the game entirely; Adobe Photoshop did this with the introduction of its layer and mask concepts.

Not all novelty in a product is the result of radical design. In soware, new concepts emerge over time, in response to new uses and new opportunities. Twier's hashtag concept solidied and extended an idea that users had invented. is follows a paern that Eric von Hippel [56] has argued is typical in many industries: that innovation oen comes not from the suppliers or products, but from their users, who rst feel the need for new functionality, and oen even create it in prototype for themselves.

e key point is that radical design is atypical. Normal design is what almost all designers do day to day. is doesn't mean designers just reinvent the wheel. Even in a normal design, there are many opportunities for small innovations, resulting over time in dramatic technological advances. It also doesn't mean that design does not maer. On the contrary, the quality of a normal design can spell the dierence between success and failure, for any product, including soware.

To be radical, a design does not need to change everywhere. Changing one critical component can make a design radical, while keeping others xed to reduce risk. e designers of the rst hybrid car switched the engine but they didn't replace the steering wheel with a joystick, or use acrylic in place of glass for the windows, or alter the shape of the cabin.

In soware, similarly, one new concept can make a design radical. e radical move in the design of the World Wide Web—in my view the key insight of its inventor—was, as I argued in Chapter 3, the concept of the url, whose purpose is to provide a distinct and persistent name for each resource that is independent of where and how the resource is stored. is was what made the Web dierent from all its predecessors (such as HyperCard), making possible a massive shared information infrastructure.

On a smaller scale, Adobe Lightroom's designers based image editing not on Photoshop's layer and mask concepts, but on the concept of an action—an image adjustment that is stored in the image's metadata as part of a history, making possible exible and non-destructive image editing. e implications of this change are enormous. Interaction becomes simpler; non-destructive edits become easy; modications can be stored as metadata in the image les themselves; and the le sizes are dramatically reduced.

104. Alexander's design paerns. e idea of capturing design expertise in generic "design paerns" that can be instantiated in dierent contexts originated in the work of the architect Christopher Alexander [4, 5]. Alexander is known to computer scientists through the "Gang of Four," whose inuential collection of design paerns in object-oriented programming [44] cited him as an inspiration.

Concepts are in fact closer to Alexander's design paerns than the Gang of Four paerns are, because, like Alexander's paerns, concepts are driven by the needs of users, and shape users' experiences of the product; the Gang of Four paerns, on the other hand, are motivated mostly by the needs of programmers (in particular making code easier to evolve over time). At heart, however, design paerns and concepts have a lot in common, and the Gang of Four deserve credit for changing the way we think about programming.

For Alexander, paerns address the fundamental challenge of design, namely the unknowability of context that results in unanticipated mists (see Note 60). Because paerns represent normalized design (see Note 103), they embody long experience in coping with the mists that typically arise, and save you from the design mistakes you would make if you were designing from scratch.

Computer scientists who have encountered Alexander only secondhand through the literature on design paerns in soware may be surprised to discover, on reading Alexander's work, that he writes not so much as a designer, let alone as an engineer, but more as a poet, reveling in the spirituality of good design (especially in his latest books [6]). e spiritual and aesthetic components of concept design have yet to be explored, but may be essential if we want to go beyond so ware that works to soware that delights and inspires.

105. Why does PowerPoint have a cursor? In my discussion of PowerPoint's section concept, I referred to "the selected slide." Even behind this simple phrase lurks a conceptual design question. Many apps involve manipulating a sequence of items by insertion, deletion, and moving. All of them have some concept of selection; what distinguishes them is whether you can select more than one item, and if so, whether those items must be contiguous.

Many also have a concept of cursor, which marks the point at which an insertion will occur. In text editors, the relationship between the cursor position and the current selection is quite complicated; in the editor I'm typing this text in (BBEdit), for example, if I select a word, the cursor disappears; advancing the cursor (with the right arrow key) then places it aer the word, and moving it back (with the le arrow key) places it before the word.

One reason that text editors have a cursor in addition to selections is to support replacements: if you make a selection, and then start typing, the new characters replace the characters that were selected. Placing the cursor without a selection allows you to insert without making any replacements.

is complication—of having both a cursor and allowing selections—works well in text editors but doesn't seem necessary in a slide presentation app. So Keynote has no cursor; if you select a slide and add a new slide, the new one just appears aer the selected slide (without replacing it, of course). But both PowerPoint and Google slides include both cursor and selections. Unlike in a text editor, where a simple click always sets the cursor, in these apps you have to click quite carefully between slides to place the cursor without selecting a slide.

I'm not sure why this complication is useful. You might think that it makes adding slides a lile more intuitive, because you don't need to remember whether the new slide comes before or aer the selected one. So to add a new slide at the beginning of a section in PowerPoint, you might place the cursor just before that slide. Sadly, you can't do that though: the cursor can only be placed between slides within a section or aer the last slide.

Perhaps this whole discussion seems nitpicky. But while any one small complexity like this might not maer, the accumulation of many such needless complexities exacts a heavy price, from programmer and user alike.

106. Inevitability as a design principle. e PowerPoint example illustrates a general design principle. Consider how the add section command might have behaved. ere are so many dierent possibilities: to include or exclude the subsequent slides from the newly created section; if a slide is currently selected, to include or exclude that particular slide; to allow the action to be executed when non-contiguous slides are selected or not; and so on.

Whenever a design decision is made from such a set of possibilities, and when those possibilities seem equally plausible—or at least none stands out as obviously beer than the others—the designer runs the risk of making a non-optimal choice. So the very presence of all those options leads to a fragile design process, in which at every step the designer is likely to make a mistake, following a path along which arbitrary decisions take the designer towards a more idiosyncratic and incoherent design. Each of these choice points is faced by the poor user too, who has to guess how the design will behave from amongst the equally plausible options.

ese decision points are thus a symptom of a bad design. In a good design, the design decisions seem to be inevitable. Only one of the options is plausible, and if more than one is plausible, the choice is resolved by following a general rule or sen-

sibility that applies uniformly to all decisions within the product. e user will be able to predict which behavior is most likely at any point, either because only one makes sense, or because the user will be aware (perhaps only subconsciously) of, and guided by, the general rules and sensibilities that have been conveyed by the design and the detailed behaviors the user has encountered so far.

For the designer, this raises a question. When you reach a decision point at which there seem to be many possibilities, what do you do? You should start, of course, by evaluating the options. If one is clearly and demonstrably superior to the others—which means that in a team you will have consensus—you should probably choose that option. If not, you can try to formulate a general principle that would favor one over the others. If you're able to do that, and can apply that principle throughout your design, choosing that one option may be justied. If you can't do that, you have no choice in my view but to back o: to undo the previous decision that brought you to this point of confusion.

e inevitability of your design move at each point, in other words, is not only a mark of design quality, but evidence that the decisions you have made so far have been sound.

107. More on Lightroom's unconventional export presets. e unusual semantics of the augmented preset concept is reected also in its mapping to the user interface. In the standard checkbox widget, the label that sits next to the box is not usually selectable as a separate control. is is what Don Norman would call an aordance problem: the preset names don't signify that they have a clicking aordance distinct from toggling the checkbox.

Complex concepts confuse technical writers. e complexity of the preset concept is evident in the documentation too. e help page includes an FAQ with the question "Why are some sections hidden when presets are checked?" e answer given is as follows: "When you select one or more export presets in the Export dialog, Post-Processing section and other sections created by third-party plug-in are hidden in the Export Seings. However, the export seings dened for Post Processing and other sections from third-party plug-ins in the export preset are respected and images are exported accordingly." Hmm.

Complex concepts confuse programmers. While experimenting with the preset dialog in order to understand it beer, I found that the entire application sometimes became unresponsive and I had to force quit it and restart. It seems likely to me that the conceptual complexity of the design has resulted in some untamed

complexity in the code, and Adobe may be experiencing some trepanning here (Note 89).

108. Using nicknames in contacts. As evidence that many people use nicknames and not real names for their contacts, consider the fact that NokNok, an Israeli startup, actually marketed an app to exploit this. Users who downloaded the app were connected and shown the nicknames others used for them in their contacts. Perhaps not surprisingly, the company eventually switched business areas and is now focused on providing free VOIP calls.

Apple's Contacts app in fact supports the nickname concept. You can select "nickname" from a set of elds that can be added to a contact. What you enter there appears to be private: if you start typing a nickname in an email message, the address is completed but the nickname does not appear in the message that is sent. With this feature, our Prince can safely call the Queen "Mummy" aer all.

Chapter 11: Concept Integrity

109. Robustness of mental models. In early and inuential work on mental models, Johan de Kleer and John Seely Brown argued that only certain kinds of models served users well, allowing them to reliably predict behavior (especially in novel situations). ese models, which they termed "robust," had to satisfy certain "aesthetic principles" [80].

eir rst and most important principle, which they called "no-function-instructure," required that the behavior of the components of a system be context free. is would mean, for example, that the explanation of how a switch works could not refer to the function of other parts of the circuit (even though of course whether a component is activated may depend on whether the switch is on or o).

It is reassuring that this principle, emerging from a psychological perspective, aligns so closely with the idea of concepts as independently explainable units of functionality, and with the integrity principle (see "Concepts are freestanding" in Note 48).

110. Feature interactions and integrity. Concept integrity is strongly related to the idea of feature interaction in telephony (see "How concepts dier from features" in Note 48).

One particular formulation—which appears as the denition of feature interaction in [122], and as the last of a series of possible denitions in [22]—associates a system-level specication with each feature, and then says that an interaction exists if the presence of one feature causes the specication of another to no longer hold.

is is exactly the denition of concept integrity. Ruling out such interactions is, by the standards of the feature interaction literature, quite extreme. But it seems essential to preserving the nature of concepts; without it, concepts would not be understandable in their own right, because their behavior would depend on the context in which they are deployed.

In practice, concept integrity does not seem to impose unreasonable demands, for several reasons. First, not all features need be implemented as concepts. Classic telephony features such as "call forward on busy" and "voice mail on busy" would probably be beer represented as synchronizations of concepts than as concepts in their own right. Second, distinct features in telephony (such as "selective call acceptance" and "selective call rejection") may be contained within a single concept (in this case one that manages accepting and rejecting calls based on preference lists).

ird, a concept specication only governs its own actions, so when concepts are synchronized in collaborative composition, one concept need not impinge on the behavior of another. For example, if call forwarding is described in terms of mapping phone numbers to phone lines, and regular calling involves only making connections between lines (and has nothing to say about numbers), the two can be composed without risk of integrity violation.

Finally, when concepts are composed, the mapping to a user interface can change which actions are exposed to the user. For example, an email concept might have a delete action for permanently deleting messages. When composed with the trash concept, however, the deletion buon in the user interface will no longer be associated with the email.delete action, but rather with trash.delete, the deletion action of the trash concept. In such a case, it might appear to the user that integrity is violated—deletion no longer permanently removes a message. But once the user understands the mapping of user interface controls to concept actions, integrity is recovered.

111. Font magic in Apple Pages and other delights of format-toggle. In Apple Pages, if you bold some text in Helvetica Light, it will be in Helvetica Bold; bolding again takes you back to Helvetica Light. And if you start in Helvetica Regular, and apply bold twice, it will take you back to Helvetica Regular. is sounds nice, because it preserves the toggling, until you realize that the text that was supposedly in Helvetica Bold is treated dierently in the two cases! e app is apparently remembering more about the format seing than is evident in the formaing dialog, and so integrity is violated for other reasons.

fig. E.10 An aempted solution to the formatToggle integrity problem, in Apple Pages '09.

(You can reveal that something funny is going on as follows. Start with some text in Helvetica Light, say. Now bold it. If you bold again, you'll be back to Helvetica Light. But if before you do that, you pull down the font style menu showing Bold, and you click on that highlighted menu item, you will now have cleared the hidden state, and it will revert to Regular when bolded again.)

It's important to note that Apple's style mechanism does not permit partial styles to be dened, losing the key benet of separating out bold and italic as settings independent of the font subfamily. e 2009 version of Apple's productivity apps did allow partial styles (see Figure 8.12 in Chapter 8), but this had other problems. Instead of treating a professional font as a single typeface family, it broke the family down into "subfamilies"—a classication dened for both TrueType and OpenType fonts. In the screenshot of Apple Pages '09 (Figure E.10), you can see that the "font" is set to "Magma Light," which represents one of the subfamilies of the Magma typeface. If the subfamily has exactly the four variants (regular, bold, italic, bold italic), this works nicely. But some subfamilies (like Magma Light) are dened by their weight, so they don't have a bold variant!

Adobe InDesign does have the format toggle concept insofar as having bold and italic actions. ese suer from the same problem as TextEdit's. But unlike in Apple's productivity apps, bold and italic are not available as seings for styles, so are missing where they would be most useful.

112. No backup in Google drive. Google Drive has no built-in backup facility. It does save old versions of les—a valuable feature—but if the le itself is deleted, the old

versions are deleted along with it. Google's synchronization utility is confusingly called "Backup and Sync," but the backup refers to backing up les from your computer to the Google Drive, not to backing up in the other direction.

113. More on the Google Drive accident. When Google Drive synchronizes a folder that is empty on your local machine, it doesn't permanently delete the les in the cloud, but instead moves them to the trash. Unfortunately, in the scenario I described, the user emptied the trash: "I was organizing my les on my local computer. I moved them around and out of my Google Drive folder which syncs les. I didn't think anything of it. In the process I got an email from Google saying I'm running out of storage. So I go to the Google Drive site and empty the trash. I didn't think anything of it."

e trash is hardly a protection for the problem described here, because an unsuspecting user might aempt to move les out of a synchronized folder precisely to allow the trash to be emptied and thus to gain space in their drive.

For the full sad story, see the web page hp://googledrivesucks.com. Perhaps one measure of the seriousness of a usability problem is whether it causes enough pain for someone to go to the trouble of registering a domain in protest.

114. is book's website and forum. To spare you the trouble of registering your own domain to complain about this book, I have created a website that includes a link to a discussion forum for topics related to the book and to concept design. Please visit hps://essenceofsoware.com. I look forward to your participation.

תושלב"ע

Draft: not for distribution or quotation. © 2018 DanielJackson

References

• [1] Jean-Raymond Abrial. e B-Book: Assigning Programs to Meanings. Cambridge University Press, 2005.

• [2] M. Ainsworth, A. H. Cruikchank, P. J. L. Wallis, and L. J. Groves. Viewpoint speci cation and Z. Information and Soware Technology, 36(1):43–51, 1994.

• [3] Christopher Alexander. Notes on the Synthesis of Form. Harvard University Press, 1964.

• [4] Christopher Alexander. A Paern Language: Towns, Buildings, Construction. Oxford University Press, 1977.

• [5] Christopher Alexander. Timeless Way of Building. Oxford University Press, 1979.

• [6] Christopher Alexander. e Nature of Order: An Essay on the Art of Building and the Nature of the Universe (4 volumes). Center for Environmental Structure, 2002.

• [7] Charles Bachman and Manilal Daya. e Role Concept in Data Models. Proceedings of the ird International Conference on Very Large Data Bases, Tokyo, Japan, Oct. 6–8, 1977, pp. 464–476.

• [8] Don Batory and Sean O'Malley. e design and implementation of hierarchical so ware systems with reusable components. ACM Transactions on Soware Engineering and Methodology, Vol. 1:4, Oct. 1992, pp. 355–398.

• [9] Nels E. Beckman, Duri Kim, and Jonathan Aldrich. An empirical study of object protocols in the wild. Proceedings of the European Conference on Object-Oriented Programming (ECOOP '11), 2011.

• [10] Dines Bjørner. Soware systems engineering—From domain analysis via requirements capture to soware architectures. Asia-Pacic Soware Engineering Conference, 1995.

• [11] Dines Bjørner. Domain Engineering: Technology Management, Research and Engineering. Japan Advanced Institute of Science and Technology ( JAIST) Press, March 2009.

• [12] Gerrit A. Blaauw and Frederick P. Brooks. Computer Architecture: Concepts and Evolution. Addison-Wesley Professional, 1997.

• [13] Laurent Bossavit. e Leprechauns of Soware Engineering: How Folklore Turns into Fact and What to Do about It, 2017.

• [14] Douglas Bowman. Goodbye, Google. 20 March, 2009. At hps://stopdesign.com/ archive/2009/03/20/goodbye-google.html.

• [15] Harry Brignull. Dark Paerns. At hps://www.darkpaerns.org.

• [16] Robert Bringhurst. e Elements of Typographic Style. Hartley & Marks, 1992

• [17] Frederick P. Brooks. e Mythical Man-Month. Addison-Wesley, Reading, Mass., 1975; Anniversary edition, 1995.

• [18] Frederick P. Brooks. No silver bullet—essence and accident in soware engineering. Proceedings of the IFIP Tenth World Computing Conference, 1986, pp. 1069–1076.

• [19] Frederick P. Brooks. e Design of Design: Essays om a Computer Scientist. Addison-Wesley Professional, 2010.

• [20] Julien Brunel, David Chemouil, Alcino Cunha and Nuno Macedo. e Electrum Analyzer: Model checking relational rst-order temporal specications. Proceedings of the 33rd ACM/IEEE International Conference on Automated Soware Engineering (ASE 2018), Association for Computing Machinery, New York, NY, USA, pp. 884–887, 2018.

• [21] Jerome Bruner. Toward a eory of Instruction. Harvard University Belknap Press, 1974.

• [22] Glenn Bruns. Foundations for features. In S. Rei-Marganiec and M.D. Ryans (eds.), Feature Interactions in Telecommunications and Soware Systems VIII, IOS Press, 2005.

• [23] Jerry R. Burch, Edmund M. Clarke, Kenneth L. McMillan, David L. Dill and L. J. Hwang. Symbolic model checking: 1020 states and beyond. Information & Computation 98(2): 142–170, 1992.

• [24] William Buxton. Lexical and pragmatic considerations of input structures. ACM SIGGPH Computer Graphics, Vol. 17:1, January 1983.

• [25] Stuart Card and omas Moran. User technology—From pointing to pondering. Proceedings of e ACM Conference on e History of Personal Workstations (HPW '86), 1986, pp. 183–198.

• [26] Stuart K. Card, omas P. Moran, and Allen Newell. e Psychology of Human-Computer Interaction, Lawrence Erlbaum Associates, 1986.

• [27] Peter Chen. e entity-relationship model—Toward a unied view of data. ACM Transactions on Database Systems, Vol. 1:1, March 1976, pp. 9–36.

• [28] Michael Coblenz, Jonathan Aldrich, Brad A. Myers, and Joshua Sunshine. Interdisciplinary programming language design. Proceedings of the ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reections on Programming & Soware (Onward! 2018), 2018.

• [29] Richard Cook and Michael O'Connor. inking about accidents and systems. In K. ompson and H. Manasse (eds.), Improving Medication Safety, American Society of Health-System Pharmacists, 2005.

• [30] Nigel Cross. Design inking: Understanding How Designers ink and Work, Bloomsbury Academic, 2011.

• [31] David L. Detlefs, K. Rustan M. Leino and Greg Nelson. Wrestling with rep exposure, SRC Report 156, Digital Systems Research Center, July 29, 1998.

• [32] Edsger W. Dijkstra. e Structure of the "THE"–multiprogramming system. ACM Symposium on Operating System Principles, Gatlinburg, Tennessee, October 1–4, 1967.

• [33] Edsger W. Dijkstra. A position paper on soware reliability (EWD 627). 1977. At hp://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD627.html.