Book summary: Writing Monsters

This is my (partial) summary for the book “Writing Monsters” by Philip Athans. It’s a book with advice and tips for fiction authors on writing effective monsters for your stories. Instead of following the book structure, I’m going to try to summarise a selection of its ideas.

Predictability is the enemy of horror

This is by far the most important idea in the book, and many of the tips stem from this principle. I have marked in italics everything connected to this.

What is a monster?

Uniquely strange creature that we instinctively fear. A distortion in appearance, behaviour or thought. Characteristics:

• Monsters have a disturbing capacity for violence.

• They are amoral and beyond our control: cannot negotiate with them, don’t seek or respect our opinion.

• They turn us into prey, sometimes isolating us and/or taking our weapons.

Note that shape, appearance (hideous to beautiful) and size (giant to microscopic) don’t matter!

A strange, terrifying creature might not be a monster once its behaviour is understood.

Uses of monsters

• Villains: Monsters don’t have to be villains, and villains don’t have to be monsters. If a character is both, build the villain facet first.

• As transformation: We’re afraid of what we can’t control, including ourselves and other people (werewolves, Jekyll & Mr. Hyde, etc). Our psychological well-being is as important as the physical, maybe more, because otherwise we’re expelled from society and civilisation.

• As “natural disasters”: They bring the best and worst in people. Useful to explore honesty, loyalty, vanity, etc., not just good/bad.

• As obstacles: Simply what stands between the protagonists and some goal. Note that “defeating” a monster might mean understanding it, helping/rescuing it, or sending it home.

Defining Your Monster

When defining your monster, define its offence (why it’s dangerous), defence (why it’s hard to get rid of it) and utility (features that gives it “colour”, like Blair Witch Project making stick figures and putting victims in a corner). Make rules for it, even if they’re never fully explained to the reader. You can use a monster form as a reference.

Archetypes like vampires, zombies, dragons, etc., are useful, but you need to define your own twist to them, see eg. 30 days of night and 28 days later. Otherwise, they’re unoriginal and, worst of all, predictable.

Describing Your Monster

Show, don’t tell! Describe the visceral experiences of the protagonists/victims (eg. use of “shuddering” instead of “being afraid” in Lovecraft’s Dagon excerpt on p. 142), the monster’s effects on people, and its possible intentions. Not knowing what the monster is, or not seeing it, is effective.

Think of all the senses. Limiting one, or all but one, can be effective. We don’t have to be turned away by appearance, smell, etc: sometimes predators use good smell to attract prey.

Revealing Your Monster

Monsters should be revealed in three stages:

1. Initial contact: Announces there is something. It’s fast (uses few words) and dramatic.

2. Build-up: Reveals aspects of it, takes the most space: increasing the threat, leaves reader wondering where does it stop. Reveal no more than necessary (our imagination makes them scarier), use “red shirts” (side characters who die) to show the danger.

3. Final encounter: Play with expectations and wait as long as possible to show the monster. Don’t actually show the monster until the end.

Conclusion

There’s much more to the book than what I’ve written here: I just included the parts that were more interesting for me personally. I have to admit that I was a bit disappointed with the book: it seemed messy, some of the ideas and examples I didn’t find enlightening or useful, and some ideas were repeated several times (didn’t feel like reinforcement, just messy writing/structuring). Maybe I had too high expectations.

That said, the book was interesting and useful, at least for a n00b like me. So I recommend it, just not wholeheartedly.

• fiction
• horror
• review
• writing

Book review: Javascript Web Applications

This is my review of “Javascript Web Applications” by Alex MacCaw, part of the O’Reilly Blogger Review Program (in a nutshell: you can choose an ebook from a given selection, and you get it for free if you make a review and post it in any consumer site). It’s a book about using Javascript to write (mostly) client-side web applications. The book cover says “jQuery Developers’ Guide to Moving State to the Client”, which is somewhat misleading: although most examples that could be written with jQuery are written with jQuery, it’s a book that anyone interested in Javascript can use, enjoy and learn from, regardless of their library of choice. It doesn’t even assume you know jQuery, and there’s a whole appendix dedicated to introducing the reader to the library, should she need it.

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.

• books
• javascript
• programming
• review
• web

Book summary: Ending Slavery (I)

Ending Slavery is a book about modern slavery and the possibility of ending slavery forever. It defines slavery, shows that there is still a lot in this world, explains how it works, why it still exists, why people end up in slavery, and finally it describes a plan to end it once and for all. It’s a very good book, although sometimes I wished that there were less “stories” and more “information”. That said, the summary ended up being huge, especially for a relatively small book (250 pages).

This first post will cover the introduction, and the chapters “The Challenge” and “Building the Plan”. Other posts will cover “Rescuing slaves today”, “Home-grown freedom”, “Governments”, “Global problem, global reach”, “Ending the product chain”, “Ending poverty to end slavery to end poverty to end slavery” and the coda and appendix.

EDIT: see the second, third, fourth and fifth parts.

Introduction

5000 years of slavery can end forever, as well as 200 years of pretending we don’t have slavery. We just need a plan, and this book helps in laying it out. Freedom is not just possible, it’s inevitable, for the seed of freedom grows and grows. Our job is to nourish those seeds.

The Challenge

It used to be clear for everyone what slavery was. It was defined and protected by law. When it became illegal, many people thought it was over, and it became less clear what slavery is. In essence, slavery it controlling people through violence and using them to earn money. It doesn’t depend on the duration.

In modern times, slaves are cheap and disposable. Three factors after World War II led to resurgence of slavery:

1. World population explosion: from 2 to over 6 billion people in about 50 years, most in the developing world.

2. Dramatic social and economic changes. As colonies gained independence, they opened to western businesses. In that process, the poor were left behind and they had even less opportunities and resources. If we compare poverty and slavery levels, the pattern is obvious.

3. Police corruption, In rich countries there’s slavery in spite of the police. In many other countries it flourishes because of it. If the policeman salary is $10/$20 a month, getting $100 extra a month is the difference between being able to feed your children and have electricity or not. Question: how was “corruption” measured?

Looking at everything supporting slavery, it’s discouraging: world poverty, corruption, greed, population explosion, environmental destruction, armed conflicts that impoverishes countries, international debt, governments not applying laws. But not everything has to be done at once, and not everything has to be solved to end slavery. People in extreme poverty has fallen from 1.5 to 1.1 billion people (from 1981 to 2001) even with the world population increasing. Many changes are already taking place, just need a plan to support them.

Building the plan

When releasing slaves, freedom is the beginning, not the end (as in most of the challenges start then). The obvious thing when a slave is freed would be to consult the body of knowledge by doctors and psychologists, except it doesn’t exist. It’s being compiled now.

When freeing a slave making rugs, some questions point at us: who buys them? do the wholesale vendors know they’re profiting from slavery? how do we differentiate slave rugs from others? If we stopped buying rugs, would that help slaves? Ending slavery is solving a lot of puzzles. Did rich countries end slavery, or did they move it to other countries while keeping the benefits without the moral discomfort?

Key ingredients to end slavery:

1. Public awareness. We have three advantages over abolitionists in the past: (a) the moral argument is already won, (b) the monetary value of slavery is very small, it doesn’t threaten any country’s livelyhood, and (c) for the most part, laws are already in place. The missing link is governments enforcing laws: until it reaches the public agenda there will be slaves.

2. Education. Many slaves are tricked into it, violence only comes when it’s too late to escape. It’s an ancient method. Education is key to fight slavery, but we’re hardly taking advantage of it. There are large sums for teen pregnancy and drugs, but how much for slavery? Question: it that a good argument? Training is needed in law enforcement too. The US spends more than any other country in law enforcement, but it was only in 1998 that a human trafficking task force was created. It has started training police, but has been criticized for being low-priority and haphazard. Question: by whom?

3. Honest law enforcement. In poor countries, police not only needs training, but overhauls to remove corruption. If the pay is poor, they’ll find ways to make more cash. Corruption levels there now are similar to those in the US in the 19th century.

4. Government action.

5. Economic support for anti-slavery workers.

6. Rehabilitation. Essential to sustained freedom. Some return to slavery by choice, because they only find insecurity. Without help to create a new life, people often can’t by themselves. When equipped with skills and education, ex-slaves are empowered and committed to end slavery, become village leaders, and are not afraid of confronting police. A single ex-slave can change a whole village.

The UN millennium development goal for 2015: provide every child in the world with basic education. That’d be around $28 billion, and while it sounds like a lot that’s what Michigan charities spend a year, the personal wealth of IKEA’s owner, or what Philip-Morris had to pay a single person who sued them.

There are other costs: anticorruption campaigns, debt reduction, police training, rehabilitation, training/paying anti-slavers workers. But in the end, there’s profit in ending slavery.

And that’s it for now. The next post will cover ”Rescuing slaves today” and “Home-grown freedom”.

• books
• human rights
• review
• slavery

Book Summary: Storytelling for UX (3/3)

And this is the last past of the summary of “Storytelling for UX” (first part, second part). In this last part I’ll cover the tips to create stories. At the end I’ll do a mini-review of the book and will add some extra comments.

How to create a story_ _

Stories have four elements: audience, ingredients, structure and medium.

Audience

There are two important relationships in stories: story-audience and you-audience. About the first, you want to include details that fill the gap, and also stories are a good way to make the audience see a different perspective by feeling it. Finally, endings are important. They should be memorable and settled (“take them home”).

Ingredients

See checklist on p. 209.

• Perspective. there isn’t a neutral POV in stories. Types of perspectives are realist (3rd person, “absent” author), confessional (focused on author experience) and impressionist (mixes descriptions of events with a strong structure). The last intends to spark ideas/actions and while they can have an ending, they might end with implicit question. An easy way to add perspective is letting the main character do the talking.

• Characters. One of the reasons why UX stories are useful is because they add specificity and texture to the usually one-dimensional view of users. Also useful to highlight needs outside the mainstream. Tips to build characters: (1) choose (only) details that add meaning; (2) show, don’t tell (show in action instead of describing traits); (3) set up “hooks” that you can use later in the story; (4) leave room for imagination.

• Context. Five types: physical (time, date, location, location scale), emotional (how characters feel), sensory (5 senses), historical (“when phones had dials”), memory (storyteller’s memory, flashbacks).

• Imagery. Things that make us picture the story (example in p. 205). Don’t use too much!

• Language. Tips: (a) speak in the language of the characters, (b) make the story active, (c) focus on telling the story, not describing, (d) don’t judge characters, context or events.

Structure/plot

Structure is the framework/skeleton of the story. Plot is the arrangement of the events. Strong structures help the audience, the author and the story (p. 215). See types of stories on p. 216. “Checklist” for good structure and plot on p. 235.

Medium

Four big media: oral (mind the gap to written, p. 243), written (make the point explicit, keep it short, make use of cultural cues as in p. 253), visual (comics and storyboards work, see p. 258-260), multimedia/video.

See tips on how to integrate stories in reports on p. 265 and p. 266. See strong sides of different media on p. 272.

Mini-review and conclusions

I quite liked the book, although I admit that the last part (the one summarised in this post) was a bit disappointing. I guess it’s hard to give tips about something as complex as creating a story, in a book. The book has a very clear structure and it’s easy to follow and read, which helps in figuring out what to read, what to skim and what to leave for later.

Another thing that really struck me while reading the book (the second book I read following the tips from “How to Read a Book”) is how little I used to understand of the books I read. I now go through the book three times: one to get an idea of the structure and the most interesting parts, one to read the content, and one to review and make a summary. So even while I was reading it for the last time, I made sense of things that I hadn’t realised while reading the book (and that was after knowing the structure, knowing what to expect from each chapter, and having made some preliminary notes!). Not only that, but I also feel that I’m much more critical with what I read and I compare it much more with what I think myself.

If you aren’t doing it already, I strongly recommend that you give those tips a try…

• books
• review
• storytelling
• ux

Book Summary: Storytelling for UX (2/3)

This is the second (and longest) part of my summary of “Storytelling for UX” (see the first part). It will cover how to fit stories and storytelling into the UX design process.

There shouldn’t be “a storyteller” in the team, as many as possible should be familiar with the technique. Prototypes based on stories allow exploration of new ideas, esp. if they’re big changes.

There are several parts of the UX process were stories are useful:

• Collecting input from users. You’re already hearing those stories. Do it consciously.

• Exploring user research and other data. Summary of hard data.

• Experimenting with design ideas. See stories that help launch a design discussion (type) and the role “spark new ideas”.

• Testing designs. They can evaluate if you have stayed true to original needs and if they will work with real users.

Collecting input

Being in the user work environment helps noticing things people don’t mention. When you just arrive, everything is unfamiliar. Take notes then. If you can’t talk to your users, you can get some limited info from: search/server logs, customer service records, people who do training and sales demos, market research and satisfaction surveys.

Getting people in groups can help make people talk (build on each other). Also asking people to recall specific events is really useful.

Tip: be open to tangents, but don’t waste too much time in them if you don’t see value. Also, a user avoiding talking about what you want is information, too.

Tip: Use a structure for the interview (first closed questions, then open), see p. 82. Try to have the interview in the context the product will be used.

Selecting stories

Characteristics of good stories:

• Heard from more than one source

• With action detail

• Make user data easy to understand

• Illustrate an aspect the UX team is interested in

• Surprise or contradict common beliefs

They should help explain something about UX beyond data, bring data to life. They should also connect with other stories and resonate, leading to action.

Experimenting with design ideas

Three possible uses of stories: brainstorming, concept and specification. When no user research is available, you can brainstorm to create user stories. See a good technique/game for it on page 111.

When you do have user research, you can develop those stories. For that, some rules: (1) defer judgement, (2) encourage wild ideas and (3) build on the ideas of others. See adaptation of the game for this case, p. 118. Concept stories should include: (a) focus on activity set in a specific context, (b) description of motivations that trigger action, (c) describe the characters well enough to set them in context.

Specification stories are useful to summarise results. They are included in specs. They keep the real-world context available for reference.

Testing/evaluating designs

Three uses of stories: create scenarios/tasks for usability testing, serve as guide for expert reviews, and quality testing.

If in usability testing you ask the user first what her interests are, you can turn that story into a usability test task.

Stories and personas from them are very useful to set a context for expert reviews. Give each expert a persona and make them try to complete a task from that persona POV.

[I didn’t really get the “quality testing” part, whatever that means, so I don’t have notes about it]

Sharing stories

When communicating with people, stories get the audience attention, set context and inspire action.

Listening exercises make you understand your audience, and make them understand how diverse/similar they are.

There are three typical types of audiences:

1. Strategic leaders: generate and maintain a common vision (p. 143). Things that work for them: identify point of pain and offer a solution, identify gap in market and show how to fill, show new approach by reconfiguring common/existing components, and identify UX trends and show impact on business.

2. Managers: have a mission and have to make decisions (p. 146). Don’t have time to spare, prefer short meetings to brainstorming sessions. If you bring bad news, show why it’s important to care. Don’t go into much detail.

3. Technical experts: implement a vision (p. 149). Can be difficult to reach them with stories, esp. if not grounded in details. Tips: (a) use representative characters and situations and be ready to back up with hard data, (b) make the action of the story specific and tangible, (c) keep the story on track, (d) use technical terminology accurately.

And that was the end of this part of the summary. In the next and last post I’ll cover the tips about creating stories and will write some sort of mini-review and conclusions.

• books
• review
• storytelling
• ux

Book Summary: Storytelling for UX (1/3)

This is book is the first book chosen for Oslo’s UX book club. It was a quite interesting book about using stories and storytelling techniques in different steps of the User Experience design process. The following is the first part of my (long) summary of the book. The summary is mostly intended to remind me things I read, but probably/hopefully it will be interesting and useful to others. As the book is more or less divided in four parts (introduction, listening, how to fit stories in the process and how to create a story), I’ll cover the introduction and the notes on listening in this post, and will leave the other two parts to other posts. Edit: see parts two and three.

Introduction (chapters 1-2)

Stories help keeping people at the center (p. 2). There are different types of stories (p. 5):

• Those that describe context/situation: describe the world today. Not only sequence of events, but also reasons and motivations.

• Those that illustrate problems: show a problem that a new product or design change can fix. They should describe it in a way that opens the door for brainstorming.

• Those that help launch a design discussion: starting point for a brainstorming session. Enough detail to make sense but leave room for the imagination.

• Those that explore a design concept: explain/explore idea or concept and its implications for the experience. Helps shape the design by showing it in action.

• Those that prescribe the result of a new design: describe the world as it will be in more detail. Similar to the 1st, but describe a user experience that doesn’t exist yet.

Interesting quote in page 10, with the message “until you hear a story, you can’t understand the experience”.

Stories are interactive, change with the audience (p. 14). They also not only describe actions, but add context and why (motivation). There is a fine line with how many detail to include in motivation, because of shared cultural understanding and other things (p. 17, 19).

Stories have different roles:

• Explain: give context and sensory experience, not just events. This is different from use-cases.

• Engage the imagination: surpass linear logic and evoke new ideas.

• Spark new ideas: as we fill in the gaps, we can hint details but let people come up with their own ideas.

• Create a shared understanding.

• Persuade.

In any case, stories are not “made up”: they’re based on data.

Listening (chapter 3)

Really listening to users (e.g. in interviews and such) gives you access to a lot of info you can’t get anywhere else. Open questions are very important for this. Giving time to answer sometimes gives people time for second thoughts (not just what they think you want to hear), which has more value than the first reply. Also, pay attention to the context, people forget to mention “obvious” (for them) everyday facts.

Practising active listening is very important, see the following links:

• Eight barriers to effective listening

• 10 Tips to Effective & Active Listening Skills

And that’s it for the first part. Stay tuned for the rest of the summary.

• books
• review
• storytelling
• ux

Book review: "97 Things Every Project Manager Should Know"

In the last batch of books I ordered from The Book Depository I had “97 Things Every Project Manager Should Know”. It was a thin book and one of the first to arrive, so I figured it was a good one to start. The book is a collection of 2-page articles about project management. It has 198 pages, but I just read until around page 70, then “speed-read” the rest because I was so disappointed that I just wanted to get it over with. This has been the most disappointing book I’ve read in many years, and I rarely stop reading books even if I don’t like them that much (especially if they are as short as this one).

But I hate not trying to be constructive, and just saying that it was disappointing for me won’t tell you much about the possibility of it being disappointing for you, so here we go:

• The choice of articles seemed “random”: clearly some of the authors had very good things to share, but many others didn’t sound that experienced or having so much interesting to say. I could imagine myself writing some of those articles.

• Many articles read like they want to give “general” advice, but extrapolating from circumstances that I may never have (like making a rule out of a “this happened to me once” kind of experience).

• I didn’t find it “inspiring” at all, if I wasn’t a project manager already I would not want to become one. The idea of working as a project manager felt dry, boring, and too focused on processes.

• Many articles feel written for someone that doesn’t have any project management experience whatsoever. That’s cool, but it’s useless for me and should have been clearer in the book I think.

• Many other articles seem written for project managers from other industries (or even simply “managers”) that are going to start managing a software project. That is not only plain useless to me, it also bores me to death. Seriously, WTF is with the definitions of super basic concepts? If you don’t know what an “iteration” or a “hack” is and you won’t check yourself out of curiosity you shouldn’t be allowed to manage a software project. Period.

• Many articles felt too “corporate” to me, there was too much jargon and too many references to job titles, methodologies and contractors instead of really essential stuff based on experience.

• Reading some of the more or less interesting stuff, I couldn’t help thinking that those things would be obvious for someone who has been working as a software developer for years and wants to become a project manager because she finds it interesting.

• Other articles were interesting, but lacked depth to make them really useful.

Don’t get me wrong, there are useful articles, but the book as a whole doesn’t feel that useful. Certainly not worth the time reading the whole thing.

And finally, something that kept popping in my head, even if the comparison is unfair (it’s a different kind of book), is that this book is in many respects the opposite of the things I loved about Making Things Happen (an excellent book that you should read if you have any interest in project management). Oh well.

• book
• book depository
• books
• management
• project
• rants
• review

Review of "Confessions of a Public Speaker"

I had been looking forward to this book since relatively long before it was published. Having read “The Myths of Innovation” and “Making Things Happen”, I knew that “Confessions of a Public Speaker” would be a good book. And all the reviews I had read seemed to confirm it.

“Confessions…”, as you can imagine, is a book about public speaking. It has anecdotes, tips, more general advice and some very frank opinions on the matter. It looks like a very useful book (I haven’t had any talk since I read it, so I can’t confirm yet ;-) ), and the content is concrete enough that it’s easy to learn from it and apply it to yourself. Many stories are funny or eye-opening, and there’s a good deal of food for thought. Speaking on TV feels so scary now :-P

To be honest, I didn’t like “Confessions…” as much as Scott Berkun’s two other books (which I wholeheartedly recommend if you have any interest in innovation or project management!). That doesn’t mean it’s a bad book. Maybe it’s just not as good as the other two. Or my expectations were higher. Or it was at times a bit too snarky or cynical for my taste. Or maybe that I’m less into public speaking than I am into understanding innovation or project management. After all, I don’t have that many talks or workshops, and it’s not even a core part of my job.

But as I said, the book was quite enjoyable and made me write down some of the advice so I could apply it when I can. I read it very quickly (it felt so short!) and I’ll come back to it for reference when I have to talk in public again. In short, a practical, to-the-point, fun book well worth the money and time.

• book
• confessions
• public speaking
• recommendations
• review
• scott berkun