Kindle Notes & Highlights
Read between
August 23 - October 15, 2024
With this new perspective, designers can focus their work more effectively, and users can understand software with greater clarity, empowering them to exploit their software to its fullest potential.
Pretty interesting to target builders and users.
So be warned: the devil is in the details—and the angels are too.2
I mean “design” here in the same sense that the word is used in other design disciplines: the shaping of some artifact to meet a human need.
Design, as the architect Christopher Alexander put it, is about creating a form to fit a context.
These questions have no right or wrong answers, only better or worse ones.5
if your software has the wrong design, there’s no amount of defect elimination that will fix it, short of going back to the very start and fixing the design itself.9
The software engineering researcher Michael Jackson credits not the logic per se but the very difficulty of using it, and once mischievously suggested that the quality of software systems might be improved if designers were simply required to record their designs in Latin.
the determinant of success when you’re developing software isn’t whether you use the latest programming languages and tools, or the management process you follow (agile or otherwise), or even how you structure the code. It’s simply whether you know what you are trying to do.
If your goals are clear, and your design is clear—and it’s clear how your design meets the goals—your code will tend to be clear too.
a book should aim to start a conversation, not to end one.
The actual concepts that Dropbox uses are very different (Figure 2.4, right). When an item sits in a folder, the name of that item belongs not to the item itself but rather to the folder containing it. Think of a folder as being a collection of tags, each containing the name of an item (a file or folder) and a link to it. This concept, which I’ll call unix folder, was not invented by Dropbox, but, as its name suggests, was borrowed from Unix.15
I did not know this and it definitely broke my mental model
In programming, there is a familiar and important distinction between abstraction and representation. An abstraction captures the essence of a programming idea, and may be expressed as a specification of the observable behavior. A representation is the realization of that essence in code.
A bad solution to this problem is to try and educate users.
The task of the user interface designer is to project what the usability researcher Don Norman calls a “system image” that corresponds faithfully to the conceptual model, so that users will acquire a mental model aligned with it.25
But most important of all is aligning the model in the head of the user with the model in the head of the programmer, and that is achieved by explicitly designing concepts that are shared by user and programmer alike, and conveyed clearly in the user interface.
Software design is conducted at three levels: the physical level, which involves designing buttons, layouts, gestures and so on that are matched to the physical and cognitive capabilities of human users; the linguistic level, which involves designing icons, messages and terminology to communicate with users; and the conceptual level, which involves designing the underlying behavior as a collection of concepts. The two lower levels are concerned with representing the concepts in the user interface.
This is partly because the senders and recipients of text messages are uniquely identified by their phone numbers, whereas email users tend to have multiple addresses, which makes grouping into conversations unreliable.
Is that why? Or is it that email is effectively a broadcast with different people popping in and out?
Concepts not only distinguish individual apps, but also unify families of apps. Programmers, for example, commonly use text editors (such as Atom, Sublime, BBEdit and Emacs) to edit program code; people use word processors (such as Word, OpenOffice and WordPerfect) to create documents of all sorts; and professional designers use desktop publishing apps (such as Adobe InDesign, QuarkXPress, Scribus and Microsoft Publisher) to organize documents into finalized layouts in books and magazines.
Photoshop became the dominant photo editing program due to its layer concept, which made non-destructive editing possible, and, in combination with the mask concept, allowed local edits
What is the single most important strategy in problem solving? The prize, I believe, must go to separation of concerns, in which different aspects or “concerns” are addressed separately, even if they are not entirely independent.
You might not have thought to mitigate the cost of storing the identity of the user with each vote by freezing voting on archived items (so that the identities associated with prior votes can be discarded).
Take an app that you are familiar with and identify a small number of core concepts that characterize it. Consider similar apps, and see if you can explain the commonalities and differences in terms of their concepts.
Seems like a good exercise
Concepts don’t make all design problems go away, of course. They do, however, help you localize challenges by recognizing them as specific to a particular concept. A concept becomes a container not only for the behaviors that it embodies but also for all the accumulated knowledge about its design, the issues that have arisen in practice as it has been deployed, and the various ways in which designers have dealt with them.
We might therefore say that the purpose of the trash concept is not deletion but the undoing of deletion.40
It’s not enough to know why you’re designing a product. You need to have a why for each element of your design, a purpose for every concept.
Need-focused. A purpose must express a need of the user, and not just recapitulate a behavior whose significance is unclear. Take the bookmark concept that browsers offer. It’s not helpful to say that the purpose of a bookmark is to “mark a page” or to “save a favorite page”: these just beg the question of why you would want to do such things. Instead, the purpose might be to “make it easier to revisit a page later,” or perhaps to “share a page with another user.” Don’t worry if a purpose isn’t precise initially; if your formulation immediately raises questions (may “revisiting later” be on a
...more
Sometimes, a design you’re working on presents multiple options that seem equally plausible, and there seems to be no rational basis for selecting one over another. In many cases, this dilemma is a result of not understanding the purpose deeply. Once the purpose is understood, it becomes clear which option is the right one.
Presumably this is why Apple changed the behavior of all its applications (in OS X Lion, 2011) so that changes are written to disk from the start, and “saving” to a file just entails naming the file. In other words, the purposeless editor buffer concept was eliminated.55 With buffers gone, the save-as action (in which the contents of the buffer were saved to a new file of a given name) no longer made sense; users were now expected to duplicate the file and rename it (Figure 5.3).56
TIL
The essence of design is the challenge of creating a form for a given context. The desired outcome is a perfect “fit” between form and context, in the way that a piece in a toddler’s wooden puzzle board fits snugly into its hole.60
Automation doesn’t do new things that you could not previously have done manually; it just makes them inevitable.
Paradoxically perhaps, synchronization never adds new executions. It merely removes some executions: in this case the ones that don’t make sense.
In design, decide first which concepts to include, and then how they to synchronize them. Start with synchronizations to remove bad behaviors. Then consider automations, but make sure to leave enough flexibility to the user.
The dependencies discussed in this chapter arise from the role that concepts play in the context of the product as a whole, and is more a property of the product than of the concepts it contains.
Some software products must emerge from the womb fully grown. An aircraft or nuclear power station cannot be deployed with software that is only a “minimum viable product,” with a plan to adjust the software as needs arise.
But in most cases an incremental development is better, because it allows the developers to get early feedback on their design work, assess the value of the work already deployed, and handle misfits as they are discovered. So it’s useful to think about designing a new software product as growing it, a few concepts at a time.
For all these reasons, it’s useful to be able to represent succinctly the possible growth of a software product, and—equally importantly—the ways in which it may be trimmed back.
In fact, you might ask, why not just use one of those existing apps? Often that will be the best approach to solving a problem.
Even the identification concept, which might have seemed to be very bird-specific, has been cast in more general terms, in the hope that this will make it easier to draw inspiration and lessons from related concepts (such as tag in Facebook).
More insidiously, after you sign a petition, you get a request to make a donation (Figure 8.3). Most people assume, quite reasonably, that this donation concept is synchronized with the petition concept in a particular way: that their donation is being passed to the petition organizer to help them fund their cause. In fact, the money pays for advertising on change.org (whose domain extension is misleading too: it is not a nonprofit). In the case of my own petition, supporters contributed over $2,000 to change.org. Had I understood the operational principle of “chipping in,” I would have warned
...more
Concepts have to be mapped to a concrete user interface, with actions mapped to gestures such as clicking on buttons and concept state mapped to display views of various sorts.
The rule says that, in the design of a software product, concepts and purposes should be in one-to-one correspondence. That 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 fulfills it.
Piggybacking occurs when an existing concept is adapted or extended to accommodate a new purpose.
We definitely do this all the time. "its a shared abstraction" we might say. "reduce duplicative code". BAD!
Finally, piggybacking is avoided by developing an awareness of the urge to “optimize” a design by putting concepts to contradictory purposes, and learning that the effort saved in such reuse leads to a complexity that eventually exacts a high price.
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.” The problem with this formulation is that it hides two distinct purposes. One is filtering: by promoting posts from your friends, Facebook saves you the trouble of sifting through posts from people you’re not interested in. The other is access control: by choosing your friends, you can choose who gets to see your posts. For most users these purposes are indeed often aligned because human relationships tend to be
...more
The agile mantra to build The Simplest Thing That Works applies both in selecting purposes to address and in the design of the concepts that fulfill them.
The designer might also imagine that users will appreciate the economy of fewer (and richer) concepts, but this is often illusory. Better to have more concepts that are coherent and compelling than fewer concepts that are complicated and confusing.
What are your most valuable concepts? Do you have a killer concept (like Photoshop’s layer or the World Wide Web’s url) that is responsible for the success of your product and your competitive advantage? Are some concepts (like Gmail’s label) the linchpin of your product without which it could barely function? Are some concepts key to revenue, perhaps because they define a premium version of your product, or because they bring the greatest value to your customers?
Do you have troubled concepts? Does your product include concepts that have confused users, as evidenced by frequent help requests, or whose complexity has led to a disproportionate share of defects or system outages? If so, are these troubled concepts shared with your competitors, or might they be self-inflicted wounds?
What is the purpose of each concept? For each concept in your inventory, can you give a simple and compelling purpose? Do these purposes contribute to the larger goals of the product, and the vision of your organization? Whose purpose does each concept serve? Does the purpose serve the interests of your customers? If so, which customers does it serve—the users or the advertisers? If it serves the interests of your organization, does it exact an unnecessary cost from customers? Are the purposes that are intended to serve the interests of customers communicated effectively to them, and do they
...more
Can you implement the concepts as separate modules? If your implementation entangles concepts together, is the lack of modularity really justified? Or are you building up technical debt that will eventually have to be repaid? If you have succeeded in modularizing concepts, are there code dependencies between them that can be eliminated so they can be modified and reused more easily?
