81a4d0a2fe
raw/book/EssenceOfSoftware_Eng/ — Daniel Jackson (2021) 원본 11개 폴더 추가 wiki/sources/ EOS 챕터별 한국어 페이지 8개: - EOS-overview: 전체 개요, 설계 3수준, 핵심 원칙 - EOS-part1: Ch1-3 동기 (Backblaze/Dropbox 사례, 개념 역할) - EOS-ch4: 개념 구조 (5요소: 이름·목적·상태·행동·운영 원칙) - EOS-ch5: 개념 목적 (좋은 목적 4기준, 미스피트 사례) - EOS-ch6: 개념 조합 (동기화, 시너지, 과잉/과소 동기화) - EOS-ch7: 개념 의존 (의존 다이어그램, 제네릭 개념) - EOS-ch8: 개념 매핑 (다크 패턴, UI 매핑 딜레마) - EOS-part3: 원칙 Ch9-11 (특정성·친숙성·무결성) wiki/index.md Sources 섹션 EOS 8개 등록, wiki/log.md 기록 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
468 lines
73 KiB
Markdown
468 lines
73 KiB
Markdown
#### 8: concept Mapping
|
||
|
||
| achine: Daniel Mac Pro 👂 Files upl | oaded from: 2020-01-01 12:00 to 202 | 21-02-17 12:00 | Go |
|
||
|------------------------------------|--------------------------------------------|----------------|------------------------|
|
||
| Folders | ≅ Filters <sub>▼</sub> | | |
|
||
| Select all folders and files | Name | Size | Modified |
|
||
| ▼ □ design book | 00-reading-guide.txt | 10.39 KB | Feb 15, 2021, 07:57 PM |
|
||
| ▶ □ archive | □ 01-why-wrote.txt | 11.52 KB | Feb 15, 2021, 08:02 PM |
|
||
| ▼ □ book copy | 02-discovering-concepts.txt | 27.51 KB | Feb 16, 2021, 02:54 PM |
|
||
| chapters | <ul><li>03-how-concepts-help.txt</li></ul> | 30.92 KB | Feb 15, 2021, 08:15 PM |
|
||
| ▶ ☐ images | ☐ 04-concept-structure.txt | 23.22 KB | Feb 15, 2021, 09:15 PM |
|
||
| | ☐ 05-purposes.txt | 36.41 KB | Feb 15, 2021, 09:19 PM |
|
||
| ayout | 06-composition.txt | 39.31 KB | Feb 16, 2021, 11:29 AM |
|
||
| distribution | 07-dependences.txt | 20.31 KB | Feb 16, 2021, 09:04 PM |
|
||
| ▶ ☐ ideas | 08-mapping.txt | 26.06 KB | Feb 16, 2021, 09:10 PM |
|
||
|
||
fig. 8.8 *e Backblaze dialog for restoring les: the om and to dates lter which le versions are shown, a seemingly plausible mapping.*
|
||
|
||
les that were modied aer that date; by seing the *to* date, you choose which version will be restored. For example, if you choose les *from* January 1, 2021 *to* March 1, 2021, you will be shown only les that were modied (or created) aer the start of the year, and the version that you restore will be the last version that was backed up at or before the start of March.
|
||
|
||
is sounds ne, but there's a snag. Suppose you discover that an important le got corrupted somehow. You'd like to restore the last uncorrupted version. If you know on what date the corruption happened, you can just enter that date in the *to* box of the dialog. But if you don't know the date, you now have to search through old versions to nd it.
|
||
|
||
You might start with yesterday, and move back one day at a time, restoring the le, and checking it until you nd an uncorrupted version. If you know the corruption happened sometime between January 1 and March 1, you'd start with March 1, repeatedly restoring and checking until, in the worst case, you check 60 times and go all the way back to January 1. 90
|
||
|
||
is might not seem like a big deal, but unfortunately, every time you change the *to* date in the dialog, you have to reload the folder tree (which takes about 20 seconds), and then, because the tree has been reset, you have to navigate down again to the le of interest. en you have to download it and examine it.
|
||
|
||
Needless to say, this is a laborious process. e underlying concept is ne: the old le versions are all accessible; the problem is that the mapping makes it dicult to get your hands on them. One possible solution to this (adopted by other backup utilities such as Carbonite and Crashplan) is to show all the
|
||
|
||
| Version history of "HTML Snippets.html" <u>Back to results</u> | | | |
|
||
|------------------------------------------------------------------|------|----------------------------------------------------------------------|--|
|
||
| ☐ MODIFIED DATE | SIZE | STATUS | |
|
||
| ☐ <b>2</b> 9/30/2019 11:39 AM | 3 KB | Will restore as "HTML Snippets (Restored) 09-30-<br>2019 11.39.html" | |
|
||
| ☑ @19/25/2019 10:58 AM | 3 KB | Will restore as "HTML Snippets (Restored) 09-25-<br>2019 10.58.html" | |
|
||
|
||
fig. 8.9 *e Carbonite dialog for restoring les, which shows a list of all versions of a le.*
|
||
|
||
versions of a le together with their modication dates, and let you download them in one go (Figure 8.9).
|
||
|
||
# *A Live Filtering Conundrum*
|
||
|
||
Suppose an app allows you to display a collection of items, dened by some property that they all satisfy; and that, furthermore, while viewing the collection, you can modify the items. e design question is this: what happens if your modication of an item invalidates the property that made that item a member of the collection?
|
||
|
||
Apple Mail's *flag* concept ts this paern: there are ags of seven dierent colors, which users can interpret as they please, and actions to aach a ag to a message, and to display all messages with a given ag.91
|
||
|
||
e *flag* concept maintains, as its state, a mapping from messages to the ags they carry. When you click on a ag icon in the sidebar on the le, the app displays all the messages that carry the ag of that color (Figure 8.10).
|
||
|
||
You might think, at rst, that clicking on a ag maps to an action in the *flag* concept that nds all items with that ag. But it's beer to think of the click as part of a more elaborate mapping that switches the interface into a mode in which the agged items are displayed. is is beer because it allows the display to be live, updating on the y if the set of agged messages changes spontaneously (for example, because a message just arrived and got agged by a rule).
|
||
|
||
Now the conundrum. What happens if, while viewing the list of agged messages, you select one of them, and remove its ag? A seemingly obvious solution is to remove that message immediately from the list, in order to ensure consistency (namely that the displayed messages are exactly those that carry the given ag).
|
||
|
||
#### 8: concept Mapping
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_2_Picture_1.jpeg)
|
||
|
||
fig. 8.10 *A skillful mapping of the ag concept in Apple Mail: messages with yellow ags are being shown. e ag has been removed om the rst message, but the message is still listed.*
|
||
|
||
In practice though, this would be a bad mapping design. Just think what would happen if you toggled a message accidentally, removing its ag and then wanting to reinstate it. When you removed the ag, the message would disappear from the list, your selection now cleared. You may not even be able to nd that message to reinstate its ag—ironic, since you likely agged certain messages *precisely* because nding them was hard!92
|
||
|
||
A preferable behavior is, counterintuitively perhaps, to not update the display, and to retain all those messages that were originally shown. When you unag a message, the message remains; but if you switch out of the ag view, and return to it later, then you will notice that the message no longer appears.
|
||
|
||
For this scheme to work, each message in the list must be agged individually. is might seem gratuitous at rst, since every message in the initial display must, by denition, be agged. But when you toggle the ag on a message, you can see the ag disappear, and the message remains right there—and still selected—allowing you to easily reinstate the ag. is is exactly how Apple Mail behaves: in the screenshot, I have unagged the message at the top, but it is still showing.
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_3_Picture_1.jpeg)
|
||
|
||
fig. 8.11 *A mapping dilemma for the collection concept in Adobe Lightroom: with two collections showing, selecting a photo for removal does not identify which collection to remove it om.*
|
||
|
||
# *Resolving Ambiguous Actions*
|
||
|
||
Oen the user's gestures are easy to interpret. But sometimes they're ambiguous. is can happen especially when an action's arguments depend on previously made selections. Let's look at an example of this.
|
||
|
||
In the *collection* concept, items can be added and removed from collections that represent a possibly overlapping classication of items. Examples of applications that use collections are: Zotero, which lets you organize citations of papers into collections; browsers such as Safari, which oer collections for bookmarks; and Adobe Lightroom, which lets you dene collections of photographs or movies.
|
||
|
||
e distinguishing feature of the *collection* concept that makes it distinct from the *folder* concept is that an item can belong to more than one collection. Mapping the action *collection.add(i,c)*, in which item *i* is added to collection *c* is usually straightforward, and may be accomplished (for example) by leing the user drag the item to the collection.
|
||
|
||
e action *collection.remove(i,c)*, in which item *i* is removed from collection *c*, is trickier. e problem is that, in some applications, more than one collection may be selected at once. is is an important feature, because it lets the user see the items belonging to multiple collections in a single view. In Figure 8.11, two overlapping collections of photos have been selected in Adobe Lightroom.
|
||
|
||
Indicating the arguments for the *remove* action is now no longer straightforward. You might expect to be able to select an item, and press the delete buon (for example). But if the selected item belongs to both collections, it's not clear which to remove it from.
|
||
|
||
#### 8: concept Mapping
|
||
|
||
<span id="page-4-0"></span>
|
||
|
||
| Font | | New c | haracter style: |
|
||
|-------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|-----------------|
|
||
| Font Adva | nced | Name: | Emphasis |
|
||
| Cambria (Theme Body) Calibri (Theme Headings) Adobe Caslon Pro Adobe Caslon Pro Bold Adobe Caslon Pro Bold Italic Font color: Underline style: | | Fon Size | |
|
||
| Character Style Options Style Name: Emphasis Location: Basic Character Formats Font Family: Font Style: Italid | | Sha | dow: Off |
|
||
| Kerning: Y | eading: \$\circ\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightarrow\rightar | | |
|
||
|
||
fig. 8.12 *Mapping the "none" value in partial style dialogs. Recent versions of Word and InDesign (lower le) use extended widgets, such as dropdown menus whose selected entry can then be edited as text; an earlier version of Word had a separate selector for the font that populated an editable text eld (top le); Apple Pages 09 (right) used checkboxes.*
|
||
|
||
is is a nasty mapping problem. When I rst draed this chapter (in late 2020), Lightroom displayed an error message if you tried to do this, informing you that the deletion request was ambiguous. Now (in February 2021), it simply deletes the item from *all* the collections that it belongs to that are currently selected.93
|
||
|
||
# *When Standard Widgets Aren't Enough: Entering No Value*
|
||
|
||
Some concept actions take an argument that can either be drawn from some set of values, or can be "none," indicating that no value has been chosen. In the *format* concept, for example, you may have an action *set (p, v)* that sets format property *p* to have the value *v*; if you set a property and then wanted to *undo* the setting, you might then set it to the value *none*.
|
||
|
||
is subtlety arises in the partial styles example that I mentioned in Chapter 4. To recall, the idea is that you can dene a *style* that species the values of only some formaing properties. For example, you might dene a character style
|
||
|
||
called *emphasis* that sets the font style to *italic*, but leaves every other font property (such as the size and choice of typeface) unchanged.
|
||
|
||
Now consider how this might be mapped to a user interface. We'll need not only to be able to set the font style to *italic*, say, but also to *unset* it: that is, to set the font-style value to *none*, its default. at's not the same as seing it to *roman*, which would cause type already in italics to be modied.
|
||
|
||
In recent versions of apps that oer partial styles (such as Microso Word and Adobe InDesign), this is achieved by using extended versions of the standard user interface elements ([Figure 8.12, lower le\).](#page-4-0) e boolean checkbox becomes a three-state widget (on, o, and not set), and the dropdowns are extended so that, in addition to picking a value from the dropdown menu, you can also *edit* the chosen value (as a text eld) and thus delete it (to unset it). is is less counterintuitive than it might seem, since the text eld can be used for autocomplete too, which is helpful when the menu contains many entries.
|
||
|
||
In earlier versions of these programs, the extended user interface elements were not available, and users had to tolerate clunkier interfaces or apply workarounds. In Word, for many years, a partial style could be unset only by writing a Visual Basic script; then at a later point, a complicated dialog let you choose a font from a list, which then populated a separate text eld that you could edit [\(Figure 8.12, upper le\)](#page-4-0). In InDesign, once you set a property, there was no way to unset it, except by using the "reset to base" action which would clear *all* the properties of the style. e iWork '09 version of Apple Pages [\(Figure 8.12, right\)](#page-4-0) sidestepped the problem by adding a checkbox to each seing; this solution, while clean and clear, and not requiring fancy interface elements, was dropped, presumably because it required so much space.
|
||
|
||
All our previous examples in this chapter would apply in any user interface framework. is last example is interesting because it exposes a limitation of contemporary user interface toolkits, which generally do not oer a way to "unset" a value that was previously selected.
|
||
|
||
#### *Lessons & Practices*
|
||
|
||
Some lessons from this chapter:
|
||
|
||
· Concepts have to be *mapped* to a concrete user interface, with actions mapped to gestures such as clicking on buons and concept state mapped to display views of various sorts.
|
||
|
||
#### 8: concept Mapping
|
||
|
||
- · User interface design principles apply, but concepts help focus the mapping concerns. In the Java example, we saw how conating installing and uninstalling in the same dialog causes confusion, and a mapping that paid more aention to the underlying concept structure would have been clearer.
|
||
- · Some concepts are inherently more complicated, and call for more ingenuity in the mapping, and sometimes even explicit explanations in the user interface.
|
||
- · Aempts to make the user interface simpler than the underlying concepts may backre. In the Gmail example, labels are aached to messages, but the interface associates them with conversations, simplifying the visual appearance but compromising usability.
|
||
- · e mapping must take into account typical usage paerns, which as the Backblaze and Apple Mail examples suggest, may be more complicated than performing a single action.
|
||
- · Despite their expressiveness, visual interfaces may not resolve all ambiguities, and interface toolkits may constrain the mapping design.
|
||
|
||
### And some practices you can apply now:
|
||
|
||
- · When approaching user interface design, think rst how each concept can be mapped individually. en you can expand your view to consider how the mapped concepts t together on the screen, and what transitions and links are needed between them.
|
||
- · As you design a mapping for a concept, start by ensuring that each action is available in the interface (when relevant), and that the state of the concept is displayed (when needed) in an intelligible way.
|
||
- · Check your interface design against the concept's operational principle and the most likely ways in which users will want to use the available actions.
|
||
- · As always, a key advantage of a concept-based approach is that concepts, by factoring out generic functionality, make it easier to identify predecessors that can inform your work. So when designing the mapping for a concept, look to see how that concept is mapped in other apps.
|
||
|
||
| Draft: not for distribution or quotation. © 2018 DanielJackson | | |
|
||
|----------------------------------------------------------------|--|--|
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
|
||
# Concept Specicity
|
||
|
||
is chapter explains a simple principle that is surprisingly far-reaching in its ability to expose problems in a design. In fact, it is so simple that you may be tempted to dismiss it, but I hope the examples will convince you of its value.
|
||
|
||
e rule says that, in the design of a soware product, concepts and purposes should be in one-to-one correspondence. at is, for every concept there should be exactly one purpose that motivates it, and for every purpose of the product, there should be exactly one concept that fullls it.
|
||
|
||
You are probably not surprised that a concept should have at least one purpose: without one, what's the point? Or that a purpose that has been identied as signicant for a product should have a concept that delivers it. at each purpose should be delivered, avoiding redundancy, by at most one concept is surely plausible too: why waste eort?
|
||
|
||
More radical is the suggestion that a concept should fulll at *most* one purpose. And yet that aspect of the specicity principle turns out to be one of the most useful insights of concept design, and will take most of our aention in this chapter.
|
||
|
||
# *Concepts Without Purposes*
|
||
|
||
A concept without a purpose is a strange beast, but we saw examples earlier (in Chapter 5): mostly cases, such as the editor buer, in which an internal mechanism is exposed to the user. is section itself thus has no purpose, since I've discussed the topic at some length already.
|
||
|
||
# *Purposes Without Concepts*
|
||
|
||
A critique of a design might reveal an essential purpose that has no corresponding concept to fulll it. Since all soware products evolve over time, new needs will always arise—but this is not what this category of design aw entails. Rather, it points to concepts whose absence is egregious and obvious from the start.
|
||
|
||
If a concept is obviously missing, why would a designer not immediately add it? One reason is that it presents a challenge that is not easily resolved. For example, most email clients lack a concept of *correspondent* that would serve the purpose of identifying senders and receivers of email messages. is is easy to do within the connes of a closed email system such as Gmail, but to provide it more widely would require a universal authentication infrastructure.
|
||
|
||
With this concept in place, the sender eld of an email message could not be forged, and spam would be much easier to control. It would also bring a more mundane but much needed benet. In Apple Mail, you can't reliably search for messages from a given sender. e search bar misleadingly oers the option of searching by "people," but that turns out to mean nothing more than matching strings in the from- and to-elds of messages.
|
||
|
||
Most people have used more than one email address, so searching for them brings up multiple, distinct "people." And some format their name dierently in their various email accounts, so you might need to search under dierent strings to nd all the emails from a single person. In Figure 9.1, you can see that a search using my wife's name even brings up my own email address (probably because someone sent a message to my email address but with both our names in the to-eld.)
|
||
|
||
Some more examples of purposes without concepts:
|
||
|
||
*Deletion warnings in backup*. Most backup utilities have a disquieting loophole in their terms of service (and in the behavior of their *backup* concept). Files that are deleted from the machine being backed up will also be deleted from the backup itself aer some time period (say 30 days) has elapsed. e rationale for this policy is clear: it prevents customers from using the backup service as unlimited cloud storage.
|
||
|
||
It's ironic, however, that one of the main reasons people need backup is that they delete les by accident. It would be helpful and reassuring for backup utilities to provide a concept that tracks deletions, and warns you when they have occurred, so that you can determine whether or not they were intentional, before it's too late and the le has been cleared from the backup before you notice. e design of this concept is nontrivial, and would also have to account for renaming.
|
||
|
||
*Missing style concept*. Sometimes, a concept is routinely used in one class of application, and yet not available in another, even though it would be very
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_10_Picture_1.jpeg)
|
||
|
||
fig. 9.1 *How lack of a correspondent concept in email leads to arbitrary search results.*
|
||
|
||
useful there. e concept of *style* is ubiquitous in word processors and desktop publishing tools, but was only recently introduced in Apple's slide presentation app, Keynote; it is still missing from Microso PowerPoint. Without styles, it is not easy to maintain consistent formaing, especially for texts such as formulas, code and quotations that are usually distinguished typographically.
|
||
|
||
*Vestigial template concept*. Occasionally, a concept is included in a design, but in such a limited form that it fails to fulll its usual purpose. Most website-building apps include the concept of a *template* (sometimes called a *theme*), whose purpose is to decouple visual design from content. is lets you concentrate on the content of your site, and separately select a template that determines the layout, colors, fonts, etc. Key to this decoupling is that you don't need to commit to a template at the outset; you can start with any one that looks reasonable, put in some content, and then try others to see how your content looks with them.
|
||
|
||
is concept was implemented in Squarespace, but, inexplicably hobbled in version 7.1 released in early 2020, when they eliminated the ability to switch templates. is has le users in a bind because the new version brought several improvements (most notably a uniform data model across all templates, which one might have thought would have made template switching easier to implement).
|
||
|
||
With the proliferation of technology, it's easy to think that all real problems have been solved. ese orphaned purposes suggest, reassuringly, that some of the most basic needs have yet to be fullled, and there is still important design work to be done even in the most familiar contexts.
|
||
|
||
| ☐ Prima | ry | Social 23 new | Promotions 100+ new | + |
|
||
|---------|-----------------------|--------------------------|-------------------------------------------|-------|
|
||
| | Google | New sign-in from Cl | nrome on Mac - New sign-in from Ch @ 12:3 | 0 pm |
|
||
| | Keith Muhammad at De | eMont. DeMontrond Auto G | iroup - 14101 North Freeway Housto 12:1 | 9 pm |
|
||
| | AT&T High Speed Inter | rnet. AT&T High Speed Ir | nternet Service Activation - Your Al 10:3 | 7 am |
|
||
| | Keith Muhammad at De | eMont. DeMontrond Auto G | roup - 14101 North Freeway Housto Au | ıg 26 |
|
||
| | betterbatonrougejobs. | com Job Update 2015- | 08-26 - Looking For An Advantage W Au | ıg 26 |
|
||
|
||
fig. 9.2 *Gmail's categories, a redundant concept.*
|
||
|
||
# *Redundant Concepts*
|
||
|
||
A concept is redundant when another concept already exists to serve the same purpose. is may happen because the designer initially saw two distinct purposes, but they turned out to be variants of a single, more general purpose.
|
||
|
||
*Gmail categories*. Gmail introduced the concept of *category* whose purported purpose was to support the automatic classication of incoming emails (Figure 9.2). Rather than showing all the messages in a user's inbox in one list, the new concept oered a division into categories: "primary" (for email from personal contacts), "social" (for messages associated with social media accounts), "promotions" (for sales pitches), "updates" (for notications, bills, receipts, etc.), and "forums" (for messages associated with groups and mailing lists).
|
||
|
||
You might have expected this new concept to have been greeted only with enthusiasm. Aer all, it provided powerful new ltering, promising to declutter inboxes and giving users more control. e new concept was met, however, with a barrage of negative articles and blog posts. And for a long time, a Google search for "Gmail categories" listed, as the rst question above the search results, "how do I get rid of categories?"
|
||
|
||
e reason for this negativity, I believe, is that the *category* concept is redundant. Several of the critical blog posts noted that Gmail's *label* concept already met the same purpose: classication of messages. Moreover, that concept already included "system labels" (such as *sent*) that are aached without the user's intervention and could easily accommodate a new classication algorithm.
|
||
|
||
Why then didn't Google simply implement the new categories as system labels? Had they done so, users would not have had to understand the new concept of *category* and the apparently arbitrary restrictions that distinguishes categories from labels—for example, that only categories can be assigned to tabs, or that only labels can be used to classify messages outside the inbox.94
|
||
|
||
*Zoom broadcast*. In the Zoom videoconferencing app, you can move the participants of a call into "breakout rooms." e host of a call can send a message to all the participants using the concept of *broadcast*.
|
||
|
||
Why is this concept needed? Zoom already has a concept of *chat* that allows participants to exchange text messages throughout a call. e chat menu allows a participant to select whether a message is sent to a particular participant or to "everyone." Confusingly, in a breakout room, "everyone" takes on a dierent meaning and refers only to those in the room; there is no option to send a message to participants in other rooms. Moreover, the host cannot send messages to participants once they have been moved into breakout rooms; nor can participants address participants in other rooms. So the *chat* concept does not allow the host to send a message to breakout participants, which is where the *broadcast* concept comes in.
|
||
|
||
A beer design might do away with *broadcast* entirely, and extend the *chat* concept so that chat messages can be sent across breakout rooms. Like Gmail's categories and labels, chat and broadcast messages are curiously incomparable even though they fulll the same purpose: broadcast messages ash across the screen but chat messages appear in a rolling message log; broadcasts can cross breakout rooms but messages cannot; messages persist in the message log but broadcasts disappear. Most frustratingly for users, broadcast messages only appear for a few seconds, any links they include cannot be clicked on, and their content cannot be copy-pasted.
|
||
|
||
Ideally, the *chat* concept would oer the features of both concepts. Within a breakout room, the chat menu would let messages be directed to everyone in a room or everyone in the entire session; it would support messages to all participants individually, even if in dierent rooms; and, in particular, the host would be able to send messages to everyone in breakout rooms despite belonging to none of them.<sup>95</sup>
|
||
|
||
*Search and rules in Apple Mail*. Apple Mail has a search box that allows you to enter various properties of a message (such as text occurring in the body, or the name of a sender or receiver) and then lters the displayed messages accordingly (Figure 9.3). ere is also a dialog for creating a rule that lters incoming mail that allows you to select messages satisfying certain criteria (such as whether the to-eld mentioned you by name).
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_13_Picture_1.jpeg)
|
||
|
||
fig. 9.3 *Apple Mail's lters (top) and rules (below), embody two versions of one concept.*
|
||
|
||
Underlying these two features is a common purpose, which we might call *message ltering*, that lets you dene a subset of messages, in one case to be displayed, and in the other, to have some action applied (such as being moved to a folder). And yet this single common purpose is actually implemented twice within two distinct concepts, *rule* and *filter*, each time oering slightly dierent features. Rules but not lters can specify inexact matches (*contains* rather than *equals*, for example); rules but not lters can check the *cc* eld; lters but not rules can specify that a message is signed; and so on. Gmail, in contrast, unies rules and lters in a single concept.<sup>96</sup>
|
||
|
||
In all these cases, eliminating redundancy would have saved the developer work *and* given the user a simpler and more powerful tool.
|
||
|
||
# *Overloaded Concepts*
|
||
|
||
Now the most interesting criterion: that a concept should have at *most* one purpose. A concept cannot serve two purposes well.97 A purpose guides every aspect of a concept's design. If you have two dierent purposes, they will necessarily pull in dierent directions, and the concept design will have to compromise in favor of one over the other. More likely, the design will end up satisfying neither purpose in its entirety, because it is pulled in one way here and another way there.<sup>98</sup>
|
||
|
||
A concept that serves two purposes is *overloaded*. In the next few sections, I'll give examples of overloading, classied into four kinds by its cause:
|
||
|
||
· *False convergence* occurs when a concept is designed for two dierent functions that were assumed (wrongly) to be aspects of the same purpose.
|
||
|
||
- · *Denied purposes* are ones that were ignored by the designer, despite the desires of users.
|
||
- · *Emergent purposes* are new purposes for old concepts, oen invented by the users themselves.
|
||
- · *Piggybacking* occurs when an existing concept is adapted or extended to accommodate a new purpose.
|
||
|
||
Each of these overloadings has its remedy:
|
||
|
||
- · False convergence is avoided by making an eort to articulate a single purpose precisely, and checking that dierent motivations for the concept are truly reections of the same purpose.
|
||
- · Denied purposes are avoided by taking seriously the opinions and experience of users, especially those who are less technical and more reluctant in their technology adoption.
|
||
- · Emergent purposes are the hardest to avoid, since nobody can predict all the ways in which a design will impact the context of its use and create new uses. Just recognizing emergent purposes as they arise, though, allows them to be addressed, say by adding new concepts to accommodate the new purposes.
|
||
- · Finally, piggybacking is avoided by developing an awareness of the urge to "optimize" a design by puing concepts to contradictory purposes, and learning that the eort saved in such reuse leads to a complexity that eventually exacts a high price.
|
||
|
||
# *Overloading by False Convergence*
|
||
|
||
Sometimes two dierent purposes of a concept seem to be so well aligned that the designer treats them as a single, converged purpose, until it becomes clear that in fact the purposes are not only distinct but may be inconsistent with one another.99
|
||
|
||
In Facebook, for example, you might describe the purpose of the *friend* concept as "allowing two users to establish a relationship in which they can see each others' posts." e problem with this formulation is that it hides two distinct purposes. One is *ltering*: by promoting posts from your friends, Facebook saves you the trouble of siing through posts from people you're not interested in. e other is *access control*: by choosing your friends, you can choose who gets to see your posts.
|
||
|
||
For most users these purposes are indeed oen aligned because human relationships tend to be symmetrical: if I'm happy for you to see posts about my personal life, I'm probably interested in seeing posts about yours too. But for celebrities, the symmetry breaks down. I might want to read Barack Obama's posts, but I doubt he would want to read mine.
|
||
|
||
Recognizing this, in 2011, Facebook added the concept of *follower*, which serves only the ltering purpose and not the access control purpose. e *friend* concept still plays both roles, but you can use it solely for access control by turning o "following" for friends whose posts you don't want to see.
|
||
|
||
# *Overloading by Denied Purpose*
|
||
|
||
Like false convergence, *denied purpose* involves a second purpose that existed at the time of the initial design. But in this case, the designer rejected the purpose, deciding that it did not merit recognition in the design.
|
||
|
||
Listing and then rejecting candidate purposes is oen admirable. It's a key strategy for preventing bloat in application design. It's so tempting to build a Swiss Army Knife application that solves every possible problem, but the result is not likely to be a happy one. e agile mantra to build e Simplest ing at Works applies both in selecting purposes to address and in the design of the concepts that fulll them. Sometimes, though, omiing a purpose can be an act of obstinacy and denial, ignoring the needs of the user in the name of purity of vision.
|
||
|
||
Twier's*favorite* concept (discussed in Chapter 5) is an example of this. Prior to 2018 when Twier introduced the *bookmark* concept, its users had no way to save a tweet except by making it a favorite, and revealing this choice publicly. So the *favorite* concept was forced to serve two incompatible purposes: signaling approval and saving tweets for later.
|
||
|
||
I have generally avoided talking about programming tools because they're not familiar to most people, but here is an example I hope I can explain convincingly. Programmers use version control systems such as Git, Subversion and Mercurial to manage team work on a codebase, and to keep track of multiple versions of les. In practice, though, many users—especially less expert ones—use these tools for backup too.
|
||
|
||
Just think about it. All these systems allow you to frequently copy your work from your machine, which might fail at any time, to a server, and to maintain
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_16_Picture_1.jpeg)
|
||
|
||
fig. 9.4 *Example of denied purpose: using commits for backup. e lower, gray path is a separate "branch" in which a programmer builds a new feature. She commits her work when she has set up the basic structure of the feature, and nally when it's complete. But she also commits in the middle at an incoherent point because she wants to backup her unnished work.*
|
||
|
||
multiple versions of each le going back in time, which you can revert to at any point. Isn't that exactly what a backup system does? If you're using such a system already, why wouldn't you use it to back up the same les that are already being stored in the repository?
|
||
|
||
Unfortunately, the designers of these tools generally do not share this view. e concept that is relevant here, the *commit*, was designed for a dierent purpose, namely for storing snapshots of a project that correspond to coherent states of development. For example, you might perform a commit when a feature is complete, or when your work is in a suciently polished state to benet from peer review.
|
||
|
||
is purpose is not compatible with the backup purpose, because you want to back up your les as frequently as possible. If you do a large piece of unnished work, you would certainly want to back it up, but it may not be in a coherent state. So you have a dilemma. If you commit the work product, you will be misrepresenting it, and (as developers say) "polluting the commit graph" by inserting commits that have no coherent meaning and may not even compile (Figure 9.4). But if you don't commit it, it won't get copied to the cloud, and you risk losing it if your machine fails.
|
||
|
||
# *Overloading by Emergent Purpose*
|
||
|
||
A concept may have a single, compelling purpose at the time of its design, but may acquire additional purposes later as users discover new uses for the concept. e story of the plain old subject line of email messages is a case in point.
|
||
|
||
e *subject line* concept can be seen as an instance of a more general concept, *precis* say, whose purpose is to make it easier to nd, lter and assimilate long
|
||
|
||
fig. 9.5 *Subject line used for emergent purpose: identifying listserv origin.*
|
||
|
||
texts by giving a short summary that is created along with the original text or added later.
|
||
|
||
With these modest origins, one might not have predicted the many glorious roles the *subject line* came to play. Listserv soware added a prex to the subject line with the name of the listserv, making it easier for recipients to tell that the message was not sent directly to them, apparently replicating the purpose of the *to* eld (Figure 9.5). Later, email systems such as Gmail started using the subject line as a heuristic for grouping messages into conversations.
|
||
|
||
ese newly emerging purposes might seem harmless, but they're not. A friend told me of a case in which someone in his department sent a message to multiple colleagues. ey blind-carbon-copied the recipients, including an email address of a listserv for a handful of departmental ocers. e listserv duly revealed itself as a target of the message in the subject line, undermining the privacy guarantee that the *bcc* concept is supposed to provide.
|
||
|
||
e use of the subject line for conversation grouping is a known problem, because it spuriously associates messages that happen to have the same subject. One of my students told me that he likes to assign dierent labels to messages associated with dierent trips, so he can see all the messages associated with a given trip by ltering on the respective label.
|
||
|
||
Unfortunately, his travel company uses "your upcoming trip" as the subject line for all conrmations, causing messages about dierent trips to belong to the same conversation. And since ltering on a label in Gmail brings up all messages in the same conversation as a labeled message—a design aw I explained in Chapter 8—he can't use labels to show the messages for one trip without seeing messages for other trips too.
|
||
|
||
# *Overloading by Piggybacking*
|
||
|
||
e most common reason for overloading is that a designer sees an opportunity to use an existing concept to support a new purpose, avoiding the need for a new concept—and thus saving the trouble of designing and implementing it. e designer might also imagine that users will appreciate the economy of
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_18_Picture_1.jpeg)
|
||
|
||
fig. 9.6 *Epson printer driver: paper feed piggybacked onto paper size.*
|
||
|
||
fewer (and richer) concepts, but this is oen illusory. Beer to have more concepts that are coherent and compelling than fewer concepts that are complicated and confusing.
|
||
|
||
*Epson's unusual concept of paper size*. In Apple's macOS operating system, a printer driver can oer printer-specic seings in the print dialog. Epson photo printers oer many categories of special seings, allowing you, for example, to choose the paper type, adjust the drying time between prints, and so on.
|
||
|
||
ese printers typically oer several dierent feed options for dierent kinds of paper: from the top, from the back or the front, from a roll of paper, and so on. How is this *paper feed* concept controlled?
|
||
|
||
Apple has a built-in concept of *paper size* that is set in most applications through the page setup menu. e purpose of *paper size* is to make it easy to dene standard paper sizes just once, and then reuse them. In addition to the built-in paper sizes (such as standard leer size), you can dene custom sizes of arbitrary dimensions, along with margins. When you choose a paper size in an application, it sizes the page appropriately (wrapping text and respecting margins). And when you print the page, the paper size is passed to the printer so that it can check that it matches the size of the paper that is loaded in the printer.
|
||
|
||
Sadly, rather than adding *paper feed* as a new concept, Epson choose to piggyback it on the *paper size* concept. When you open the page setup menu, the names of the paper size options include the paper feed seing (Figure 9.6)!
|
||
|
||
is might seem to be a small hack but it creates major havoc:
|
||
|
||
· When you choose the paper size for a document that you intend later to print on your Epson printer, you have to commit to one of these specialized
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_19_Picture_1.jpeg)
|
||
|
||
fig. 9.7 *Shooting with a square aspect ratio: a great feature of mirrorless digital cameras.*
|
||
|
||
options. You would rather not commit even to a particular printer (so that you can later choose which printer to use in the print dialog), let alone a feed option.
|
||
|
||
- · Because the feed option is hard-wired into some standard paper sizes that come with the printer driver, you can't create new custom paper sizes, because the feed options are not available as a user-customizable seing.
|
||
- · Some applications use the page setup for dening presets. Adobe Lightroom has a concept of *printer preset* that lets you dene borders and layout for a given paper size. You might, for example, dene a postcard preset for creating a postcard from a photo. Because the preset relies on the paper size, if you want to print to an Epson printer, you need to choose one of the piggybacked paper sizes that includes the feed. As a result, your printer presets are now feed-specic.<sup>100</sup>
|
||
|
||
*Fujilm's aspect ratios*. Fujilm cameras let you set the *aspect ratio* of the image in camera. e purpose of this concept is to allow you to frame the image in the viewnder at shooting time with a particular aspect ratio for the nal image. You can choose to shoot square images (Figure 9.7), for example.
|
||
|
||
To set the aspect ratio, you open the ominously named *image size* menu (Figure 9.8, le). You can see that I've chosen a square (1×1) ratio, but, strangely, I also had to choose the image resolution—in this case, "L" for large.
|
||
|
||
A dierent menu called *image quality* (Figure 9.8, middle) lets you choose how the photo is recorded on the memory card: as just a raw le, or as a JPEG (in normal or ne quality), or as a combination.
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_20_Picture_1.jpeg)
|
||
|
||
fig. 9.8 *Piggybacking in Fujilm cameras: Seing image size/aspect ratio (le); seing image quality (middle); choosing "W" as quality greys out the size option, and with it the ability to set a custom ratio (right).*
|
||
|
||
Suppose you want to take square photos and save them only as raw les. If you switch the image quality to raw, you'll nd that the image size seing is grayed out and replaced by the word "W" (Figure 9.8, right). is makes sense for the image sizes—such as the large seing that we chose—because they don't apply to a raw le, which always includes all the sensor pixels. But why is our aspect ratio lost now too?
|
||
|
||
ere's no good reason. e aspect ratio concept works perfectly well on raw les (elegantly saving the crop outline as editable metadata), but because it's tied to JPEG dimensions through overloading, it can't be applied to them alone. In practice, this means that if you want to just record your images in raw, and you want a custom aspect ratio, you have to choose the image quality seing that includes JPEG les with the raw les, and then delete the JPEG les later!
|
||
|
||
e remedy is simply to provide an *aspect ratio* concept that is distinct from the *image size* concept. Making these orthogonal would make custom aspect ratios independent of the le type. e menus would also be simpler: instead of the nine entries needed for all the combinations of three image sizes and three aspect ratios, there would be two menus of three entries each.
|
||
|
||
is might seem like a small detail, but I wonder if it's behind Fujilm's reluctance to oer more aspect ratios, which many users have requested (there's even an online petition). Without a distinct *aspect ratio* concept, however, the quadratic growth in menu options would make the image size menu grow unacceptably as new ratios are added.101
|
||
|
||
# *Purpose Granularity & Coherence*
|
||
|
||
Whether a design exhibits redundancy or overloading will depend on how purposes are formulated. You may be wondering whether this isn't a rather subjective and arbitrary judgment. What if we just aempted to resolve overloading by declaring a new purpose that merges what were previously two distinct ones? Would that eliminate the problem of having two purposes for a single concept? Of course not: we need some test of *coherence* to reveal when multiple purposes are masquerading as one.
|
||
|
||
Ideally, a purpose will be formulated without separating cases, so that its coherence is evident in the wording itself. For example, when I talked earlier in this chapter about the *template* concept used by website-building apps, I said the purpose was to "decouple visual design from content." is formulation implicitly unies a variety of activities without suggesting multiple purposes.
|
||
|
||
But suppose I had instead described the purpose as "making it easier to build a website with aractive visual design by leing you start with a template designed by someone else, and then changing the template later without having to start again." is is certainly an inelegant purpose, and by referring to the details of particular actions it's beginning to resemble an operational principle. But it's not wrong to present this as a single purpose, because the various parts are aspects of a single and coherent purpose (albeit beer summarized in terms of decoupling). Indeed, this was my criticism of the Squarespace design, which treats each part as if it were a purpose in itself.
|
||
|
||
If a purpose is expressed in multiple parts, then, how are we to know whether it is coherent? Here are some criteria:
|
||
|
||
- · *Reformulation*. Is there a compelling reformulation without multiple parts?
|
||
- · *Common stakeholders*. Do the benets of each part accrue to the same stakeholders?
|
||
- · *Common mission*. If we identify a higher-level purpose for each part (which we might call a "mission" to distinguish it from the concept's immediate purpose), would the parts have the same mission?
|
||
- · *Non-conict*. Are the parts non-conicting, or can we imagine a scenario in which a user might want one but not the other?
|
||
|
||
Let's take a look at an example to see how these criteria can be applied.
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_22_Picture_1.jpeg)
|
||
|
||
fig. 9.9 *e like concept in Facebook: the emoticons have tooltips that identify them as "like," "love," "care," "haha," "wow," "sad," and "angry."*
|
||
|
||
#### *Applying Coherence Criteria: Facebook Likes Has Multiple Purposes*
|
||
|
||
When you click on the "like" buon below a Facebook post, seven emoticons are displayed, oering dierent sentiments from love to anger (Figure 9.9). If we were to treat this a concept—let's call it *like*—what would the purpose of the concept be?
|
||
|
||
Several things come to mind. Most obviously, clicking on one of these emoticons conveys an emotional reaction from you back to the author of the post (albeit publicly). is is probably what most Facebook users have in mind as they click away.
|
||
|
||
But there's more going on. If you play around with Facebook, you'll discover that what you like aects which posts you're shown, and the order in which they appear. By indicating which posts you like, you are curating your feed for the future, making it more likely to contain posts you will want to see.
|
||
|
||
Less helpfully, your clicks are tracked by Facebook to build up a prole of personal data that is used to target you with advertisements. From the content of your posts, and your reactions to the posts of others, Facebook classies you on a host of metrics from hobbies to sexual orientation.
|
||
|
||
In summary, we might say that the purpose of the *like* concept is to "convey emotional reactions, curate your newsfeed, and provide tracking data for targeted ads." Regarding these as three distinct parts, we can now apply our criteria.
|
||
|
||
*Reformulation*. "Reacting to a post" sounds plausible, but it is not need-focused, and thus not a purpose (as explained in Chapter 5). I'm not sure I can do beer though.
|
||
|
||
*Common stakeholders*. Facebook would no doubt argue that selling your data to advertisers to allow them to target you more eectively benets you as well,
|
||
|
||
by showing you more relevant advertisements. But most of us would resist this claim, and see the advertisers and Facebook itself as the beneciaries. In contrast, curating your newsfeed is for you alone; and conveying emotions is a benet shared with a larger community. In short, it seems that each part bene ts a dierent group of stakeholders.
|
||
|
||
*Common mission*. Likewise, the missions of the parts diverge. Emotional reactions serve the building of relationships and communities; curating your newsfeed serves your need for more engaging and informative content; and tracking for advertisers serves Facebook's boom line.
|
||
|
||
*Non-conict*. Finally, the parts are in conict too. Certainly most users would like to be able to curate their feed, but would prefer not to be tracked. Sending reactions is not well aligned with curating your feed either; you might want to send a supportive gesture to a friend but prefer not to see more of their posts. e "angry" emoticon is especially confusing: are you being angry *with* the author of the post (expressing support for their outrage), or are you angry *at* the post? It seems that this reaction is used in both ways, but according to Facebook, all of the reactions have the same eect in terms of curating your feed, and indicate (as the main buon suggests) that you "like" the post, even if it makes you "angry."
|
||
|
||
In summary, our compound purpose is revealed by the coherence criteria to be multiple purposes, and the Facebook *like* concept is therefore an example of overloading.
|
||
|
||
# *Spliing a Concept: Facebook Likes Should Be Multiple Concepts*
|
||
|
||
e remedy for overloading is to split a concept up, with one new concept for each purpose. In this case, we could split *like* into three concepts: *reaction*, whose purpose is to covey emotional reactions to posts; *recommendation*, whose purpose is to allow you to curate your feed; and *profiling*, which is used to construct an advertising prole for targeting ads.
|
||
|
||
When making such a split, the most encouraging sign is that the new concepts already exist. And, indeed, the *reaction* concept (reactions without curation) appears in communication apps such as Slack and Signal; the *recommendation* concept (curation without reactions) appears in Netix, where a thumbs-up or thumbs-down inuences which movies are suggested; and the *profiling* concept
|
||
|
||
is used by Google's Gmail service to target advertisements based on the content of your email messages.102
|
||
|
||
By treating these as three distinct concepts, we can now explore varying degrees of synchronization. At one end of the spectrum, we might have a free composition with almost no synchronization at all. In this version, users would have to click separate buons for each of the concepts. is is not entirely implausible, because it would give users complete control, but it would not suit Facebook's interests, since very few people would click on the proling buons.
|
||
|
||
At the other end of the spectrum, the concepts would be fully synchronized, so that clicking on an emotional reaction corresponds also to upvoting the post for curation and contributing to your proling. is of course is how Facebook is designed now. e problem of overloading has been converted into a problem of over-synchronization. But at least with the concepts separated there is a clearer indication in the design that the concepts have been coupled together, and less risk that the concepts themselves will be corrupted in an aempt to navigate between conicting purposes.
|
||
|
||
Between the two extremes, there are other design points. One option would be to continue to hide the *profiling* actions, but to tease apart *reaction* and *recommendation*, with one collection of buons for sending a reaction, and separate buons for upvoting or downvoting a post.
|
||
|
||
In fact, Facebook users have asked for a "dislike" buon, and Facebook has turned the suggestion down, arguing that dislikes would introduce a negative spirit into the platform. is seems disingenuous, and it assumes that the *like* concept has not been split. With a split into *recommendation* and *reaction*, you could dislike a post (executing the *recommendation.thumbs-down* action) *without* sending any social signals.
|
||
|
||
No doubt Facebook's designers have considered all these factors and more. What concepts bring is a new framework in which to analyze a design and make principled trade-os. Spliing concepts is valuable in large part because it allows an idiosyncratic concept (such as Facebook's *like* concept) to be decomposed into concepts that are more coherent and more familiar—and thus a beer basis for a comprehensible user experience, and a beer structure for recording and preserving design knowledge.
|
||
|
||
# *Lessons & Practices*
|
||
|
||
## Some lessons from this chapter:
|
||
|
||
- · e specicity principle says that concepts should be one-to-one with purposes. is simple rule has some profound implications for concept design.
|
||
- · Concepts without purposes are rare, but can arise from exposing to the user mechanisms that should have been hidden.
|
||
- · Purposes without concepts to fulll them may indicate constraints that originate outside the designer's domain, or sometimes just egregious omissions.
|
||
- · Redundancy, when multiple concepts serve the same purpose, confuses users and wastes resources.
|
||
- · Overloading, in which a single concept has multiple purposes, arises in several ways: from false convergence, in which the designer mistakenly imagined that multiple purposes were actually one; from denied purposes, in which the designer intentionally ignored a purpose for which users then marshal an existing concept; from emergent purposes, in which concepts nd new (and oen incompatible) purposes over time; and from piggybacking, in which the designer aempts to save design and implementation effort by hitching a new purpose onto an old concept.
|
||
- · Violation of any of these results in an increase in complexity and a loss of clarity: purposeless concepts needlessly cluer the interface and confuse users; missing concepts lead the user to work around the omission with more complicated interactions; redundant concepts introduce confusing distinctions between two concepts that should be one and the same, and force the user to learn dierent ways to do the same thing; and overloaded concepts bring unexpected complexity from the coupling of unrelated purposes.
|
||
- · Unwelcome restrictions on functionality oen result too. Redundancy is often a symptom of concepts appearing in specialized contexts, perhaps by subteams, without the kind of design aention that is paid to the core concepts of an application. And overloading leads to restrictions because the second purpose is forced into the procrustean bed of an existing concept.
|
||
- · Coherence criteria help determine whether a purpose expressed as multiple parts is really one purpose or several. ey include: whether reformulation as a single purpose is possible; whether the parts have common stakeholders;
|
||
|
||
whether they serve a common mission; and whether they conict with one another.
|
||
|
||
And some practices you can apply now:
|
||
|
||
- · When you're designing an app, ask yourself early on if there is an essential purpose that you have not even considered. In analyzing feedback from users, consider whether any problems that users have might be due to an omitted concept.
|
||
- · Compare each of your concepts pairwise to make sure you have no redundancy, and look more deeply to see if there are shared functions of concepts that could be factored out into their own, common concepts.
|
||
- · If a concept becomes complicated, or doesn't seem to work intuitively and exibly for your users, it may be overloaded. Formulate a purpose as precisely as you can, using the purpose criteria of Chapter 5; and if you can only express the purpose in multiple parts, apply the coherence criteria of this chapter to determine whether the parts reect distinct purposes.
|
||
- · When you determine that a concept is overloaded, try to split it into more coherent concepts, each with a more compelling and unied purpose. Be on the lookout for standard concepts that you have seen elsewhere; a composition of familiar concepts is more exible and powerful than a single, idiosyncratic concept.
|
||
|
||
| Draft: not for distribution or quotation. © 2018 DanielJackson | | |
|
||
|----------------------------------------------------------------|--|--|
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
| | | |
|
||
|
||
# 10
|
||
|
||
# Concept Familiarity
|
||
|
||
Design novices oen imagine that expert designers have an uncanny ability to pull brand new ideas out of thin air. But what looks like momentary inspiration is more oen insight drawn from years of experience. A great designer has a repertoire of designs in mind, ready to inform each new design problem she encounters. Only when the standard solutions prove inadequate will she reach for something new.103
|
||
|
||
In this respect, soware is no dierent from any other design eld. To apply the lessons of previous designs, you need rst to be able to extract design ideas as reusable fragments. at's what concepts aim to do. A concept is a particular solution to a particular design problem—not a large and vague problem, but a small and well-dened need that arises repeatedly in many contexts.
|
||
|
||
Inventing a new concept to fulll a purpose for which a perfectly good concept already exists isn't just a waste of eort. It also tends to confuse users who are likely to be familiar with the existing concept. In this chapter, we'll look at some examples of this. But rst the good case—when familiar concepts are successfully reused.
|
||
|
||
# *Successful Reuse of Concepts*
|
||
|
||
Concept reuse is rampant, especially in web apps. In fact, it sometimes seems as if every social media app is fundamentally the same—a variant of a ubiquitous super-app that lets you make connections with people and communities, share text, images, and video with them, and react to the contributions of other users with comments and ratings. Viewed from a lile distance, many of the popular apps—Facebook, Twier, Instagram, WhatsApp, SnapChat,, etc.—seem to be barely distinguishable, varying only in small details.
|
||
|
||
When yet another app in this category appears, you might initially be puzzled by how it diers from existing apps. But you won't have any trouble guring out how to use it, because it will likely oer all the concepts you are already
|
||
|
||
/30.%20Concept%20Garden%20Development/EssenceOfSoftware_Eng/concepts-121-150/_page_29_Picture_1.jpeg)
|
||
|
||
fig. 10.1 *e Twier user with the most followers.*
|
||
|
||
familiar with: *post*, *message*, and *comment* for creating content; *friend*, *follower*, and *group* for accessing and ltering it; *rating*, *upvote* and *moderation* for quality control; *notification*, *favorite*, and *recent activity* for highlighting content; and so on.
|
||
|
||
e same concept may appear under dierent guises. So the old *chatroom* concept becomes a *group* in WhatsApp or Google Groups or Facebook, and a *channel* in IRC or Slack. Twier provides a nice example of connecting its design to an existing concept. Here, for example, is how it explains the concept of *follower* (Figure 10.1):
|
||
|
||
*What does it mean to follow someone on Twier? … When you follow someone, every time they post a new message, it will appear on your Twier Home timeline.*
|
||
|
||
In answering the question, Twier provides the concept's operational principle. It is exactly what a Twier user needs to know. e meaning of following someone isn't explained in terms of some abstract notion of liking them or even wanting to read their tweets. It's given as a simple scenario: you follow, they post, you see the message on your timeline.
|
||
|
||
But I omied a crucial part of Twier's explanation (marked by the three dots). e full answer begins:
|
||
|
||
*Following someone means you've chosen to subscribe to their Twier updates. When you follow someone…*
|
||
|
||
e rst sentence is what's relevant here. Saving you the trouble of learning the concept if you already know it, it notes that *follower* is just a form of the familiar *subscription* concept, in which you subscribe to some set of events—in this case tweets from a given user—and are notied when they occur.104 |