Edit: corrected statement “total collapse of all fished species in 50-100 years” to read “we have depleted large predatory fish communities worldwide by at least 90% over the past 50–100 years” (the article it linked had the second statement, not the first; although it does say “We conclude that today’s management decisions will determine whether we will enjoy biologically diverse, economically profitable fish communities 20 or 50 years from now, or whether we will have to look back on a history of collapse and extinction that was not reversed in time”). I think the original statement is true, but I couldn’t find a reference for it.

Factory farming

Factory farming (and industrial fishing) is a mindset: reducing production costs to the absolute minimum, ignoring or “externalising” costs such as environmental degradation, human disease or animal suffering. Nature becomes an obstacle to overcome.

Factory farming possibly accounts for more than 99% of all animals used for meat, milk or eggs. As for industrial fishing, we have depleted large predatory fish communities worldwide by at least 90% over the past 50–100 years (see also Sylvia Earle’s TED talk, not mentioned in the book but related). It doesn’t help that the so-called “bycatch” is actually much more than the actual fish: typically 80% to 90% (and up to around 98%), which is tossed back (dead) into the ocean.

Diseases/shit

There is scientific consensus that new viruses, which move between animals and humans, will be a major global threat into the foreseeable future. According to the WHO the “World is ill-prepared for ‘inevitable’ flu pandemic“. The factory farm conditions encourage diseases in animals (some of them virtually unknown outside of factory farming), that end up in the actual food in the supermarkets. It’s even worse considering the animals are constantly fed with antibiotics (livestock gets almost 6 times more antibiotics than humans… if you trust the industry’s own numbers!), making the resulting diseases much harder to fight off for humans. The whole chapter 5 is filled with descriptions of filthy, dangerous and disgusting practices that are absolutely common and normal in (US, at least) factory farming.

Factory farming animal shit is a big problem both because of the quantity and for being so poorly managed: it kills wildlife and pollutes air, water, and land in ways devastating to human health. Its polluting strength is 160 times greater than municipal sewage, and yet there’s almost no waste-treatment infrastructure for farmed animals. Ignoring these problems are part of why factory farming is so “efficient”. The problem, of course, is not the shit in itself but the desire to eat so much meat and pay very little for it.

Environment

Simply put, someone who eats factory farmed animals regularly can’t call herself an environmentalist.

It takes 6 to 26 calories fed to an animal to produce 1 calorie of animal flesh (the vast majority of the food produced in the US is fed to animals). The UN special envoy of food called using 100 million tons of grain and corn a “crime against humanity”, but what about animal agriculture, which uses more than 700 million tons of grain and corn per year, much more than enough to feed the 1.4 billion humans in poverty?

The FAO/UN summarised in “livestock’s long shadow — environmental issues and options” (which has been criticised BTW!):

The livestock sector emerges as one of the top two or three most significant contributors to the most serious environmental problems, at every scale from local to global. The findings of this report suggest that it should be a major policy focus when dealing with problems of land degradation, climate change and air pollution, water shortage and water pollution and loss of biodiversity. Livestock’s contribution to environmental problems is on a massive scale [...]

Factory farmer perspective

Some interesting comments from a factory farmer (note that I don’t find them convincing, but there are some good points that need to be explained or considered when proposing alternatives to factory farming):

In fact, we have a tremendous system. Is it perfect? No. [...] And if you find someone who tells you he has a perfect way to feed billions and billions of people, well, you should take a careful look. [...] If we go away from it, it may improve the welfare of the animal, it may even be better for the environment, but I don’t want to go back to [...] starving people.  [...] Sure, you could say that people should just eat less meat, but I’ve got news for you: people don’t want to eat less meat. [...] What I hate is when consumers act as if farmers want these things, when it’s consumers who tell farmers what to grow. They’ve wanted cheap food. We’ve grown it. [...] It’s efficient and that means it’s more sustainable.

Closing thoughts

We shouldn’t kid ourselves about the number of ethical eating options. There isn’t enough nonfactory pork in the US to serve New York City. Any ethical-meat advocate who is serious is going to be eating a lot of vegetarian fare.

Ending factory farming will help prevent deforestation, curb global warming, reduce pollution, save oil reserves, lessen the burden on rural America, decrease human rights abuses, improve public health, and help eliminate the most systematic animal abuse in world history.

A good number of people seem to be tempted to continue supporting factory farms while also buying meat outside that system when it is available. [...] Any plan that involves funnelling money to the factory farm won’t end factory farming [...] If anyone find in this book encouragement to buy some meat from alternative sources while buying factory farm meat as well, they have found something that isn’t here.

Other quotes

I can’t count the number of times that upon telling someone I am vegetarian, he or she responded by pointing out an inconsistency in my lifestyle or trying to find a flaw in an argument I never made (I have often felt that my vegetarianism matters more to such people than it does to me).

Virtually all of us agree that it matters how we treat animals and the environment, and yet few of us give much thought to our most important relationship to [them]. Odder still, those who do choose to act in accordance to these uncontroversial values by refusing to eat animals [...] are often considered marginal or even radical.

It might sound naive to suggest that whether you order a chicken patty or a veggie burger is a profoundly important decision. Then again, it certainly would have sounded fantastic if in the 1950s you were told that where you sat in a restaurant or on a bus could begin to uproot racism.

We can’t plead ignorance, only indifference [...] We are the ones of whom it will be fairly asked, What did you do when you learned the truth about eating animals?

It shouldn’t be the consumer’s responsibility to figure out what’s cruel and what’s kind, what’s environmentally destructive and what’s sustainable. Cruel and destructive food products should be illegal. We don’t need the option of buying children’s toys made with lead paint, or aerosols with chlorofluorocarbons, or medicines with unlabelled side effects. And we don’t need the option of buying factory-farmed animals.

Main message

Complexity in itself is neither good nor bad, it’s confusion that is bad. Good design can help taming complexity, not by making things less complex, but by managing the complexity. There are two keys to cope with complexity: design that show its underlying logic to make it understandable, and our own skills and understanding of that logic. People need to take the time to learn, understand, and practice, because systems that deal with complex activities will not be immediately understandable, no matter how well they’re designed.

The misguided cry for simplicity

The argument between simplicity and features is misguided: people want more capabilities and more ease of use, but not necessarily more features or more simplicity. What people want is understandable devices. It’s not even a trade-off between simplicity and complexity because (a) simplicity is not the goal, and (b) you don’t have to give up something in order to have more simplicity.

We seek rich and satisfying lives, which goes along with complexity. Too simple and it’s dull; too complex and it’s confusing. This happens in every subject (also music, movies, etc). The problem is when complexity is arbitrary and unnecessary.

What makes something simple or complex is the conceptual model of the person using it: many activities we think of “intuitive” now, like swim or ride a bike, have taken us years to learn and master. We can often use something by following instructions, without having a good conceptual model. But then we run into problems, and we complain that it’s too complicated. Comparisons with tools like hammers are wrong, because (1) even if the tool is simple, mastering its usage actually takes a long time; and (2) users of those tools typically need many of them, and each one has to be mastered separately.

On anti-social machines

Machines are often anti-social when things go wrong: they become unresponsive and unhelpful, like bureaucracies. The problem is that the designer typically focuses on correct behaviour (ie. not a lot of work on error conditions). This is worse when systems are designed by engineers who view things from their logical point of view, feel people “get in the way” (the “foolproof” systems syndrome).

We try to add intelligence to machines, but what they need (and this is seldom considered) is communication skills, etiquette and communication. We often need to change our goals in the middle of an operation, or want to substitute or skip some steps, or do them in a different order, or are interrupted and have to finish a task at a later point. Most systems don’t allow this. Isolated, context-free intelligent tools can’t be sociable.

System thinking

System thinking (considering the entire process as a human-centred design) is the secret to success in services. This is part of what has made Apple so successful: (1) design cohesive systems, not isolated products; (2) recognising that a system is only as good as the weakest link, and (3) design for the total experience.

Desire lines (like messy trails besides the designed paths in the real world) can often teach us something about what people want and how the design might have gone wrong. Neglect of usage patterns can turn simple, attractive items into complicated, ugly ones, and also turn simple components into a complicated combination when they are put together. Everyday life is often complex not because of a single complex activity, but because of many simple activities with different requirements or idiosyncrasies.

Waiting lines

Waiting lines have been studied from the efficiency point of view. But what about the experience? Principles to improve the latter:

1. Provide a conceptual model (perhaps the most important principle): uncertainty is an important cause of emotional irritation; people need assurance when they have problems.
2. Make the wait seem appropriate: people should know why they wait, and agree that it’s reasonable.
3. Meet of exceed expectations: always overestimate waiting time.
4. Keep people occupied: it’s psychological time, not physical, that is important. Give people things to do, keep lines moving and make them appear short.
5. Be fair: emotion is heavily influenced by perceived causal agents.
6. End strong, start strong: in order of importance, the end, start, and middle are the most important to take care of.

The memory of the whole event is more important than the details of what happened. When there are positive and negative components, it’s best to: finish strong, segment the pleasure but combine the pain, and getting bad experiences out of the way early.

Principles to manage complexity

Note that this list is heavily edited compared to the book.

1. Make things understandable. Good conceptual models have to be communicated effectively. Jurg Nievergelt and J. Weydert argued for the importance of three knowledge states: sites, modes and trails, which can be translated into three needs, namely knowledge of the past (knowing how we got into the present state; many systems erase the past so we may not know how we got there), present (knowing the current state, how are we regarding starting point and goals, and what actions are possible now) and future (knowing what to expect).
2. Avoid error messages. They indicate the system is confused, not the user. Don’t scold her. Good design means never have to tell the user “that was wrong”.
3. Structure. Divide the task into manageable modules that are easy to learn, or find a different way to frame the problem so it’s less complicated.
4. Automation. Many tasks can be simplified by automating them, but this only helps if it’s reliable: when there are errors, it can be more complex to switch back and forth between automated and manual than to not have any automation at all.
5. Nudges and defaults. Sometimes forcing functions (constraints that prevent unwanted behaviour) are too strong, all is needed is a gentle nudge. Defaults are an effective way to simplify the interaction with the world, and a strong tool to drive people’s behaviour.
6. Learning aids. Instruction manuals are rarely read. When people use a new service or system, they have a goal, they’re not going to read the instructions first. Most people want “just in time” learning and learn better when they need to. The best explanations are in context and show how the task is done (short video demonstrations work well).

And that’s it. Hope you enjoyed  it.

Introduction

How valuable are UI design guidelines depends on who applies them. They often describe goals, not actions, so they can’t be followed like a recipe. They also often conflict with each other. This book tries to give rationale to make them easier to apply.

Visual content

• Structure: Gestalt principles (proximity, similarity, continuity, closure, symmetry, figure/ground, common fate), see on p. 11-22. They act together, and sometimes they produce effects we don’t want: review designs with each of these principles in mind to see if they suggest a relationship that shouldn’t be there.
• Text: we’re wired for language, but not for reading. Typical text-related mistakes: geek-speak, tiny fonts (if the text is hard to read, it probably won’t be read, so you might as well remove it), burying important information in repetition, and using just too much text (use just enough to help most users get to their intended goals).
• Colour: our vision is optimised to detect contrasts (edges), and our ability to distinguish colours depends on how they are presented (colours are harder to distinguish if they’re pale, in small/thin patches or separated from each other). Guidelines for colour: (1) distinguish by saturation/brightness, not only hue, (2) use distinctive colours (red, green, yellow, blue, black and white), (3) avoid colour pairs that colour-blinds can’t distinguish (tips on p.59-60, including http://www.vischeck.com/), (4) don’t rely on colour alone, and (5) don’t place strong opponent colours next to each other (see p. 62).
• Peripheral vision: we only have good resolution in the centre of wherever we’re looking. Peripheral vision (1-2 centimetres from peripheral vision) mostly only provides cues for our eye movement (good example of bad error message, based on this, on p. 71). To make an error message visible: (1) put it where users are looking, (2) mark it (often it’s enough placing it next to what it refers to), (3) use an error symbol/icon, and (4) reserve red for errors. Heavy artillery (use with care!): (1) pop-ups, (2) sound (makes users scan the screen for errors; make sure they can hear it!), (3) motion or blinking (but not for more than a quarter- or half-second).
• Visual hints: use pictures where possible to convey function (quicker to recognise; memorable icons hint at their meaning, are distinguishable from others and consistently mean the same even across applications); thumbnails depict full-sized images effectively if they keep features; use visual cues to let users recognise where they are (distinctive visual style, colours, etc).

Expectations

Our perception is biased by our experience, current context and goals. Implications: (1) test your design to make sure different users interpret it in the same way; (2) be consistent with position, colours and font for elements that serve the same function; and (3) understand your users’ goals (they can be different, too!) and make sure you support them by making relevant information clearly visible at every stage.

Memory

We’re much better at recognising than at remembering (“see and choose” is easier than “recall and type”). Tips: (1) avoid modes, or if you can’t, show the current mode clearly; (2) show search terms when showing search results (they’re easy to forget if we get interrupted for whatever reason); (3) when showing instructions for a multi-step process, make sure the instructions are there while following the steps.

Attention and goals

When people focus their attention on their tools, it is pulled away from the details of the task. Software applications should not call attention to themselves. Short-term memory and attention are very limited, so don’t rely on them. Instead indicate what users have done versus what they have not yet done, and/or allow users to mark or move objects to indicate which ones they have worked on versus the rest.

Support people’s goal-execute-evaluate cycle: provide clear paths, including initial steps, for the goal; software concepts should be focused on the task rather than implementation, for the execution; provide feedback and status information to show users their progress towards their goal, and allow users to back out of tasks that didn’t take them toward their goal, for evaluation.

While pursuing a goal, people only notice things that seem related to it, and take familiar paths whenever possible rather than exploring new ones, esp. when working under deadlines. After they’re done, they often forget cleanup steps: design software so that users don’t need to remember, or at least to remind them.

Misc. tips:

• Don’t expect users to deduce information, tell them explicitly what they need to know.
• Don’t make users diagnose system problems. They don’t have the skills.
• Minimise the number and complexity of settings. People are really bad at optimising combinations of settings.
• Let people use perception rather than calculation, when possible (some problems, when presented graphically, allow people to achieve their goals with quick perceptual estimates instead of calculations).
• Make the system familiar (concepts, terminology, graphics), by following industry standards, by making the software work like an older application the user know, or by basing the design on metaphors.
• Let the computer do the math, don’t make people calculate things the computer can calculate for them.

Learning

We learn faster when operation and vocabulary is task-focused, and when risk is low:

• Task-focused operation: you have to understand the users’ goals in order to reduce the gap between what the user wants and the operations supported by the tool is called “the gulf of execution”. To understand goals: perform a task analysis (checklist on p. 135) and design a task-focused conceptual model (the list of objects/actions analysis the user should know about).  The second should be as simple as possible (ie. less concepts), avoid overlapping concepts, and not have things “just in case”. Only then sketch and design a user interface, based strictly on the task analysis.
• Task-focused vocabulary: it should be familiar and consistent (“same name, same thing; different name, different thing”), mapped 1:1 to the concepts.
• Low risk: often people are afraid of being “burned” and don’t learn or explore. People make mistakes, so systems should try to prevent errors where possible, make errors easy to detect by showing users what they have done, and allow users to undo/reverse easily.

Responsive systems

Responsiveness is not the same as performance, it can’t be fixed by having faster machines/software. Principles:

• Let you know immediately your input was received
• Provide some indication of how long operations will take
• Free you to do other things while waiting
• Manage queued events intelligently
• Perform housekeeping and low-priority tasks in the background
• Anticipate your most common requests

When showing progress indicators (always an operation takes longer than a few seconds): show work remaining; total progress, not progress on the current step; start percentages at 1%, not 0% (and display 100% only briefly at the end); show smooth, linear progress, not erratic bursts; use human-scale precision, not computer precision (“about 4 minutes” better than “240 seconds”).

Display important information first. Don’t wait to have all the information to show everything at once.

Summary

There has never been a “natural” body: bodies have always been the expression of a specific period, geography, sexual, religious and cultural place. However, today only a few aspirational and idealised body types are taking the place of all possible bodies. We’re losing body variety as fast as we’re losing languages. Again like with languages, there’s a critical period for “body acquisition”. We can feel alienated of our own body (for the rest of our lives) if we don’t learn to feel comfortable with it in that critical period.

The individual is now deemed accountable for his/her body and judged by it, turning “looking after oneself” into a moral value. A search for contentment around the body is a hallmark of our times, and a belief in both the perfectible body and the notion that we should accede to improve it has contributed to a progressively unstable body.

The body is becoming akin to a worthy personal object. Body transformation is today less of a social ritual, and more wanting to produce an acceptable body (wounded soldiers vs. TV contestants on p. 84-85). We seem to believe that almost anything about the body can be changed by the individual, turning plastic surgery into a consumer item: a treat, like a holiday. Sexuality has to be conjured and performed, it doesn’t exist or flow naturally.

The new grammar of visual culture, which is not even real (Photoshop), produces that even children photos are “enhanced”, generating frustration and even making people lose accurate records of their visual history (very interesting notes on p. 87-90). We fall into the trap of us “enjoying fashion and beauty”, believing we’re agents instead of victims, but we aren’t being creative with our bodies or having fun with them: we feel at fault for not matching up to the current, impossible to reach imagery. We take for granted that looking good for ourselves is going to make us feel good, find faults in our bodies and say that it makes us feel better, more in control, to improve them.

Review

I generally liked the book, but sometimes I thought it was a bit too long. Many of the important points are already made in the introduction, and the rest of the chapters are more stories and references supporting the initial points. Worse yet, I sometimes found those arguments or stories not completely believable or convincing (eg. using controversial material like some Harry Harlow experiments or Victor of Aveyron‘s story to support her points). In other cases, some relatively bold claims were not backed up by references, which made me feel could be not representative or poorly-researched or, at least, made them weaker because of a lack of context.

However, the book is well written and made me reconsider several things, which is what books like this should do. Recommended if you’re interested in psychology or if you find it intriguing to learn about our relationship to our physical bodies. Although I skipped them in the summary, some of the stories (like the man who didn’t want to have legs) are pretty mind-blowing and interesting in themselves.

EDIT: Manuela wrote another, easier to read summary.

Escaping flatland

The methods in this book work to increase the number of dimensions that can be represented on plane surfaces and the data density. Nearly every escape from flatland demands an extensive compromise, trading off one virtue against another. Even our language often lacks capacity to communicate a sense of dimensional complexity. Some design strategies are found again and again (examples of over 380 years of sunspot data analysis). These design strategies are surprisingly widespread, albeit little appreciated, and occur independently of the content of the data.

Massive Java railroad line example on p. 24-25. The train diagonals cleverly multiple-function, recording six variables at once (p. 26). Example of criminal activity for a trial on p. 30-31. The chart invites reading both horizontally and vertically. The eyes detect curious patterns, which make these displays persuasive and memorable. Visual displays of information encourage a diversity of individual viewer styles and rates of editing, personalising, reasoning and understanding. Unlike speech, visual displays are simultaneously a wideband and a perceiver-controllable channel.

We envision information to reason about, communicate, document and preserve that knowledge. Chartjunk on p.34: data-thin, uncontextual graphs. Its promoters imagine numbers to be dull and tedious, requiring ornament. If numbers are boring, you got the wrong numbers. The audience might be busy or eager to get on with it, but not stupid. Chartjunk looks more like a poster, meant to be looked at from a distance (thin data density).

Micro/macro readings

Detail cumulates in coherent structures. Simplicity of reading derives from the context of detailed and complex information, properly arranged. To clarify, add detail. Stem-and-leaf plots of statistical analysis also rely on micro/macro design (examples on p. 46-47).

We thrive in information-thick worlds because of our marvellous and everyday capacities to select, edit, single out, structure, highlight, group, … Visual displays rich with data are not only an appropriate and proper complement to human capabilities, but also such designs are frequently optimal. If the visual task is contrast, comparison and choice, then the more relevant information within eyespan, the better. Low-density requires visual memory, a weak skill. High density also allows viewers to select, narrate, recast and personalise data for their own uses.

What about information overload? The question misses the point. Clutter and confusion are failures of design, not attributes of information. Interesting quote on typography on p. 51. The deepest reason for displays that portray complexity and intricacy is that the worlds we seek to understand are complex and intricate.

Layering and separation

This technique is one the most powerful devices for reducing noise and enriching the content of displays. The various elements interact, creating non-information patterns and texture simply through their combined presence (1 + 1 = 3 or more). Colour effortlessly differentiates between annotation and annotated (example on p. 54). What matters is the proper relationship among information layers (example of old + improved design on p. 54-55). For tables, try to do without rules altogether, only use when absolutely necessary. Example of map (good and bad) on p. 58. Example of (non-)dull background on p. 59. Notes on how 1 + 1 = 3 can also be applied to noise on p. 61-62. Example of use of colours (another bad + good design) on p. 63.

Information consists of differences that make a difference. A fruitful method for the enforcement of such differences is using layering and separation.

Small multiples

Quantitative reasoning is based on “compared to what?”. Small multiples answer by visually enforcing comparisons of changes, of the differences among objects, and the scope of alternatives. Information slices are positioned within the eyespan, so that viewers make comparisons at a glance. Example of drawing a Kana character on p. 69. Simultaneous two-dimensional indexing of the multiplied image, flatland within flatland, significantly deepens displays with little added complication in reading.

Colour and information

Example of Swiss mountain map on p. 80. Fundamental uses of colour in information design: label (colour as noun), measure (as quantity), represent or imitate reality (representation), enliven or decorate (beauty). Principles to minimise colour damage: (1) pure, bright colours have loud, unbearable effects when they stand unrelieved over large areas adjacent to each other, but can work very well when used sparingly on or between dull background tones; (2) placing of light, bright colours mixed with white next to each other usually produces unpleasant results, esp. if the colours are used for large areas; (3) large area background or base-colours should do their work most quietly, allowing the smaller, bright areas to stand out most vividly (strongly muted colours, mixed with grey, provide the best background for the coloured theme).

What palette of colours should we choose to represent and illuminate information? Use colours in nature (familiar and coherent, possessing a widely accepted harmony to the human eye), esp. those on the lighter side such as blues, yellows, and greys of sky and shadow. Great examples on p. 90.

In the ocean map, quantities are shown by a value scale, progressing from light to dark blue. Colour rainbows confuse viewers to mumbling colour names and the numbers they represent (“To see is to forget the name of the thing one sees”). Colours are sensitive to context. In the ocean map, contours (which are very helpful) are labelled with depth measurements. Edge lines allow very fine value distinctions, increasing scale precision. Example of bad map/good colour on maps on p. 94-95.

Narratives of space and time

Example of bad/good train schedule on p. 104-105. Space-time grids have a natural universality, with nearly boundless subtleties and extensions. Great, assorted examples on p. 110-111. Example of “tale of two cities” on p. 112-113.

Final notes

I’m aware that this summary is not very useful if you can’t see the different diagrams being examined, but it’s partly for myself :-) Anyway, if you like the ideas in the book, go buy it, it’s a great book in a big format, with really nice paper and full of very interesting examples of both good and bad information design.

But enough with the reasons. It’s starting to look like it was a pretty useful mini-project. Not just because I learned a bit more Javascript, the excellent express web development framework and other things, but also because the result itself, even though it didn’t take long to develop (and it was pretty fun, even!), feels useful. It feels like a nice place to put all my notes, TODOs, random ideas for projects, etc. A similar feeling of freedom as when I started using my first Moleskine. Not that I would ditch paper for computer-anything, but it’s useful and freeing in its own way, for specific purposes.

About the technology, I used the Markdown format for the pages thanks to the markdown-js library (it’s really nice that the module has an intermediate tree format that you can parse to add your own stuff before converting to HTML, like e.g. wikipage links!), express for the whole application structure and js-test-driver + jsautotest + a bit of syntax sugar from Sinon.js for the tests (but looking forward to trying out Buster.js when it’s released!). The deployment to Joyent’s Node.js SmartMachine was reasonably easy. Actually, it was pretty easy once I figured the following:

• You must not forget to listen in the correct port, with server.listen(process.env.PORT || 8001)
• There are a couple of pretty useful Node.js-related command-line utilities to check logs, restart applications and so on
• The configuration of the application can be done via npm config, see npm integration on Joyent’s Wiki

If you’re curious to see the code, play with it or use it yourself, take a peek to the Wiki-Toki repository on GitHub. Happy hacking!

Gain experience

Your brain is made to learn by exploring and building mental models on your own, not by receiving information passively (see amazing footage of tennis teacher in Alan Kay’s Doing with Images Makes Symbols, starting on 55:30). In real life there’s no curriculum, you’ll make mistakes and it will get messy: the kind of feedback you need. We learn by “playing”, but that doesn’t mean easy or non-business-like. Papert students called it “fun” because it was hard, not in spite of.

Leveraging existing knowledge helps learning new skills: we can often find similarities, literal or metaphorical, with existing skills. However, careful not to stick with the similarity. Fully embrace the new skill’s unique characteristics.

Failures are valuable because they can lead to study and understand what went wrong and how to fix it. They are critical to success, but only when well-managed. A good environment for good failures needs freedom to experiment (few problems have a single solution; prototype more than one solution to a problem), ability to backtrack to a stable state, reproduce any work product as of any time (source control, and the ability to run those versions of the program), ability to demonstrate progress (get comparable feedback between versions). Version control, unit testing and automation give this environment. A supporting environment can make or break learning for anyone.

Tip: to raise awareness when some code fails without apparent reason, try to imagine what the code should look like, then compare it to the real thing.

Time pressure actively shuts things down. Your vision narrows, and R-mode doesn’t get the chance to work at all.

Manage Focus

When not doing anything, the L-mode will produce incessant mental chatter, which interferes with R-mode processing. Meditation helps controlling the L-mode “monkey voice”.

When meditating you don’t want trance, falling asleep, or “contemplate the big mystery”, but to sink into a relaxed awareness of yourself and your environment without judgement or making responses. Meditation exercise suggestion: find a quiet spot; sit in a comfortable, alert position with a straight back (become aware of any tension and fix it); close you eyes and focus your awareness on your breath; be aware of the rhythm (don’t try to change it, just be aware); keep your mind focused on your breath (do not use words or start a conversation with yourself); when you start thinking about some topic or having a conversation with yourself, let the thoughts go and get the focus back on the breath. Even if you mind is wandering often, the exercise of bringing yourself back is useful.

You have to let your thoughts “marinate” to get the best results. Different people have different methods to marinate (sitting around doing nothing, humming, eating a crunchy snack, making paper dolls…). Thinking about at least three solutions to a problem gives you the confidence that you have thought “enough” about it. Then, you can let those ideas marinate and come up with the best solution.

Assorted tips:

• Develop your exocortex (mental memory or processing outside your physical brain: book collection, notes, favourite IDE, etc).
• Deliberate switching to e-mail/IM. Close what you’re working on, take a deep breath, then switch.
• Have a way to note things quickly when they come up, without losing the flow or what you were doing (wiki/scratchpad inside you IDE or whatever).
• When stuck or bored, doodle on a piece of paper, or go for a walk (without talking to anyone). That helps against checking the internet or e-mail.
• Don’t answer IM right away, put up a sign (“don’t disturb”) during a debugging session or similar, or close the door if you have one. When you do get interrupted, try to save your mental state before you lose it.
• Get two monitors (same size and brand) to keep the whole context at sight. Organise virtual desktops by task (communications/distractions, writing, coding/checking documentation, surfing), not by kind of application (browsers, editors, terminals).

In summary: learn to quiet your chattering L-mode, deliberately work with and add to thoughts in progress, and be aware of how expensive context switching can be.

Beyond Expertise

Change is harder than it looks, old habits don’t go away easily. Don’t be hard on yourself, just correct it and go back to the right path. Suggestions to make effective change:

• Start with a plan. Keep track of what you have accomplished, it’s probably more than you think.
• Inaction is the enemy, not error. The danger is not doing things wrong, is not doing anything.
• New habits take time. Expect at least three weeks, maybe more.
• Belief is real. If you think you’ll fail, you will.
• Take small, next steps. Keep your big goal in mind, but don’t try to spell out all steps you need to get there.

Possible first steps (complete list on p. 247-248, this is just two highlights): (1) pick two things that’ll help you maintain context and avoid interruption, do them right away; (2) open your mind to aesthetics and additional sensory information (your cubicle, desktop, code: how “pleasing” is it?).

You don’t want to become a “niche expert”: approach learning without preconceived notions, prior judgement or a fixed viewpoint; be aware of your own reaction to new technology and ideas; be aware of yourself and the context. The biggest reason any of us fail is the autopilot.

And this is the end. I hope you liked it.

Get in Your Right Mind

A good way to involve your brain more is to use more senses than usual. For tactile you can use building blocks like Lego, CRC cards, etc. Example of “role-playing” a software design on p. 77. The advantage of using the R-mode is not that it’s a panacea, it’s simply to use the other half of your brain too (reference to pair programming). Story of the climbing teacher on p. 81: the importance of feeling something first (R-mode) before learning it’s theory (L-mode), because it gives you the context to understand the theory and explanations better. Learning can be impeded by trying to memorise facts when you don’t grasp the whole yet. When creating, be comfortable with the absurd and impractical; when learning, get “used to it” before learning and memorising. Using metaphors can open up creativity because they communicate the R-mode and the L-mode (wordnet can help when creating metaphors).

Tip: the “morning pages” technique (p. 98). Write them first thing in the morning (before coffee, shower or anything else); write at least three pages by hand, without computer; do not censor what you write; do not skip a day. Blogging is also a good exercise (what you think about a topic, what you can defend publicly).

Tip: learn martial arts or yoga to improve concentration (p. 103). Tip: break small, daily routines (turn off the autopilot).

Forcing the brain to reconcile unlike patterns broadens the scope of material under consideration (see Zen koans and Greek oracles on p. 107). Reference to oblique strategies (has electronic versions, including an Android version!).

Debug Your Mind

We make decisions and solve problems based on faulty memory and our emotional state of the time, ignoring crucial facts, etc. Some cognitive biases: anchoring (ref: experiment with numbers and prices in predictably irrational), fundamental attribution error (other people behave based on their personality, we have excuses for our own behaviour; in reality, behaviour is often caused by the context), self-serving bias (“it’s my success”, but “it’s not my failure”; you’re always part of the system), need for closure (naturally uncomfortable with uncertainty; have to learn to live with it), confirmation bias, exposure effect (prefer familiar things), Hawthorne effect (people change when they’re being watched, but after a while they go back to how they were behaving), false memory (easy to confuse imagined events with real memories; every memory read is a write in light of the current context), symbolic reduction fallacy (L-mode is anxious to “symbol-away” complexity), nominal fallacy (thinking that labelling a thing means you understand it).

How to fight biases: understand that “rarely” doesn’t mean “never”, defer closure (you know the most about a project at the end of it, so don’t take decisions too early, be comfortable with uncertainty), remember that you don’t remember well. People are mainly a product of their environment and of the times. Explanation of different American generations on p. 125-131. In summary, generational archetypes are prophet (vision, values), nomad (liberty, survival, honor), hero (community, affluence) and artist (pluralism, expertise, due process). Realise where your thinking is coming from, what are your influences, and what kind of arguments you make. Try to have a diverse team so biases can catch/cancel each other. Myers Briggs Type Indicator discussion on p. 133-135. Trust intuition, but verify. If you think you have defined something, try to define the opposite.

Learn Deliberately

A single intense, out-of-context classroom event can only get you started in the right direction. You need continued goals, feedback to understand your progress and approach it far more deliberately than a once-a-year course.

For any goal (desired state, usually short-term) you have in mind you need a plan, a series of objectives (steps towards that goal). Objectives should be Specific (“learn Erlang” vs. “be able to write a web server in Erlang that dynamically generates content”), Measurable (how do you know when you’re done? related to “specific”. You don’t have to see where you’re going, just a couple of meters ahead of you), Achievable (from the current state!), Relevant (does it matter to you? is it under your control?) and Time-boxed (perhaps the most important: the deadline).

Create Pragmatic Investment Plans (PIP) to learn whatever you want to learn. Major point involving managing the plan:

• Have a concrete plan: devise different levels of goals (now, next year, next five years).
• Diversify: make an effort to choose different methodologies, languages, industries, and non-technical stuff.
• Active investment: need to be able to evaluate your plan and realistically judge how’s going. Adapt/change the plan based on that.
• Invest regularly: you need to make a commitment to invest a minimum of time on a regular basis. Create a ritual, if needed.

Other techniques, like mind maps, talk to the duck and learning by teaching are mentioned in this chapter, but I’m skipping them in the summary.

And this is the end of the second part of my summary. The next one will cover the rest of the book, namely chapters “Gain experience”, “Manage Focus” and “Beyond Expertise”.

EDIT: read the third part of this summary.

Introduction

Despite advances in programming languages, techniques, methodologies, …, the defect density has remained fairly constant. Maybe we’re focusing on the wrong things: software is created in your head.

You don’t get taught, you have to learn. Everything is connected, there’s nothing in isolation, so sometimes small things can have unexpectedly larger effects.

Journey from Novice to Expert

The novice needs clear, context-free rules to operate, but an expert is ineffective when constrained by those same rules. Experts don’t just “know more” than novices, they experience fundamental differences in how they perceive the world, approach problem solving, etc. The stages of learning in the Dreyfus model are:

• Novices. Have little or no previous experience in this skill area (“experience” results in a change of thinking; doing the same for years doesn’t count!). They don’t particularly want to learn, want to accomplish an immediate goal, don’t know how to respond to mistakes and are fairly vulnerable to confusion when things go awry (example of doing taxes for years on p. 20).
• Advanced Beginners. Can start to break from the fixed rule set a little bit. Can try tasks on their own but have trouble troubleshooting. They want information fast (eg. API reference) and can start using advice in the correct context, but don’t have a holistic understanding and really don’t want it yet.
• Competent. Can develop mental models and work with them effectively, troubleshoot problems on their own, and begin to figure out how to solve novel problems, as well as seek and take advice from experts. They’re typically described as “having initiative” or “resourceful” and tend to be in a leadership role in the team (formal or not). They’re great to have on your team because they can mentor the novices while not annoying the experts.
• Proficient. Need the big picture, and thus will seek out and try to understand the larger conceptual framework around the skill. They’re frustrated by simplified information. This is the first level that can correct previous poor performance and revise their approach. They can also learn from the experience of others, which comes with the ability to understand and apply maxims.
• Experts. Primary sources of knowledge and information in any field, continually looking for better methods and better ways of doing things. Statistically, there aren’t many: probably around 1-5%. Experts work on intuition, not reason. They may be completely inarticulate as to how they arrived at a conclusion. They aren’t perfect though, and have the same cognitive biases as everyone else. They’re also likely to disagree with one another.

Most people, for most skills, never get past the second stage. Plus, practitioners at a lower skill level have a marked tendency to overestimate their own abilities. Note that you want a mix of skills on a team. See “10 years to expertise” on p. 32. The dangers of overreliance on formal models (I’m skipping some in this list!):

• Confusing the model with reality. It’s easy to confuse the two, but they aren’t the same.
• Devaluing traits that cannot be formalised. Good problem-solving skills are critical to our jobs, but problem solving is a very hard thing to formalise.
• Legislating behaviour that contradicts individual autonomy. You want thinking, responsible developers. Don’t reward herd behaviour.
• Alienating experienced practitioners in favour of novices. Targeting your methodology to novices, you create a poor working environment for the more experienced.
• Oversimplification of complex situations. Every project/situation is more complex than that.
• Demand for excessive conformity. What worked great in your last project might be a disaster in the next one.
• Insensitivity to contextual nuances. Formal methods are geared to the typical, not the particular. But when does the “typical” ever happen?
• Mystification. Speech becomes so sloganised that it becomes trivial and loses meaning (eg. “we’re a customer-focused organisation”).

This is your brain

You have two “CPUs”: the linear, logical thought and language processing CPU (“L-mode”, for “linear”; the “left part of the brain”); and the searching and pattern matching CPU (The “R-mode”, for “rich”; the “right part of the brain”). They share the same bus so they can’t function at the same time.

R-mode can search “asynchronously” and come up with the response (possibly days) later. It doesn’t do any verbal processing, so the results are not verbal either (eg. trying to describe dreams). Also, it’s not under our direct concious control: as it can give answers anytime, we have to be ready to write down anything that comes up (related: everyone has good ideas, but far fewer track them; of those, even fewer bother to act on those ideas, and even fewer of those have the resources to make a good idea a success). It is very concrete, relating things as they are; it makes analogies and doesn’t require reason or known facts to process input. It’s holistic and wants to see the whole thing at once, perceiving overall patterns and structures. It’s intuitive, making leaps of insight, based on incomplete patterns, hunches, feelings or visual images. It’s very useful for software design.

Synthesis can be good for learning, see “Don’t Dissect the Frog, Build It” on p. 62. Aesthetics also make a difference, see p. 66-67. The brain is wonderfully plastic. There’s no limit to the number of skills you can learn, as long as you believe it (ie. what you think about your brain capabilities physically affects the “wiring” of the brain itself).

And that’s all for now. The next part will cover chapters ”Get in Your Right Mind” and “Debug Your Mind”.

EDIT: read the second part of this summary.

Structure

The book teaches how to write web applications using Javascript, always following the MVC pattern. It’s divided in four parts:

1. The first two chapters serve as an introduction to both the MVC pattern and the Javascript language. Although this book is not aimed at total Javascript newbies, you don’t have to know that much to follow the book. For example, it explains prototypes and constructor functions.
2. Chapters 3 to 5 cover the implementation details of MVC in Javascript (one chapter for the Model, another for the Controller and the last one about the View).
3. Chapters 6 to 10 cover many practicalities of client-side web development, like dependency management, unit testing, debugging, interesting browser APIs and deployment tips.
4. The last three chapters cover Javascript libraries: Spine, Backbone and JavascriptMVC.

Additionally, there are three appendices covering jQuery, Less and CSS3.

Highlights and references

• Chapter 10 (“Deploying”) is full of very good tips and information.
• Both the Backbone and the JavascriptMVC chapters were brilliant, looking forward to use any of them soon.
• All the example code is on GitHub.
• Page 24: “The secret to making large Javascript applications is not make large Javascript applications”.
• HJS plugin for jQuery for a nice syntax to create classes.
• ES5-shim for browsers that don’t support Ecmascript 5 yet.
• Chapter 2 was a very good introduction about events. removeEventListener (p. 41), stopPropagation/preventDefault (p. 43), list of properties (p. 44), load vs. DOMContentLoaded (p. 45), delegating events (p. 46) and custom events (p. 47-49), among others.
• Reference to blog post about namespacing.
• Object.create discussed on page 55.
• Using URL hash for URLs on pages 82, 83.
• Didn’t really understand the explanation for the HTML5 history API on p. 85. Alternatively, see the HTML5 history API on Dev Opera.
• Very interesting file API on p. 103 and p. 111. Forget the drag-n-drop (reason) and the copy/paste.
• Tips about when to load your Javascript on p. 156.
• The JavascriptMVC chapter was brilliant, see p. 208-213 for the class syntax (nicer and more compact, supports this._super()), p. 210 for instrospection and namespaces, p. 211, 212 for model attributes and observables, and p. 213 for setters. Very cool server encapsulation on p. 215. Type conversion and CRUD events on p. 218. JMVC views on p. 219. Templated actions and final example on p. 226-228.

Note that all page references are pages in the PDF file, not pages in the book!

Wrapping up

This book is packed with very practical information and a lot of code that will teach you how to write applications in Javascript. It builds up from relatively simple code to more advanced stuff, including tips, use of libraries, etc. It’s one of those books that makes you want to play with all the stuff you’re learning, and try it all in your next project.

However, sometimes the amount of code makes the book hard to read. Some parts (eg. beginning of the chapter about controllers) are a bit tiring as you have to read and understand so much code, esp. if you’re not that used to reading more-or-less advanced Javascript. It also lacks information about some important tools like Dragonfly (it almost feels like there’s nothing for developing with Opera) or js-test-driver.

In summary, this is the perfect book if you know a bit of Javascript and want to learn modern techniques and libraries that will get you started in serious client-side programming. Especially if you are one of those server-side programmers that don’t like Javascript but has to use it anyway (because despite all its warts, it’s a really nice language!). If you’re a Javascript wizard and you have been developing client-side code for years, this book may not be for you.