Choose a better tool than email for some of your communication jobs.

Mark Hurst has been blogging about email bankruptcy a fair amount recently - the idea that overwhelmed executives sometimes feel there's no option but to delete their inboxes and start again. With estimates saying that the average knowledge worker will send/receive 199 corporate emails per day by 2010, it's clear that something is very wrong.

Mark lambastes a number of people for asking for a technological solution to the problem. He also advocates a change in behaviour - his "bit literacy" approach. All sensible enough - but then I noted that there already is a technological solution the problem. Sort of.

But first you have to reframe the question. Intead of "how can I get through email with less pain?" try this one: "How can I optimise the way I communicate overall?"

My colleague Kelsey Smith has been working on a project for a global organisation that makes it money handing information. His experience there showed him an organisation thriving by using a range of different communications media:

"Email is a blunt knife. So they use multiple channels, each with different properties and used in different scenarios. Email is a data flow - a continuous stream of low-urgency background conversations happening on various lists. Blogs and Twitter fulfil a similar purpose: context. Instant messaging is used for near-synchronous conversations without being as intrusive as a phone call. And face-to-face conversation is used for urgent and complex subjects that require focus and nuance."

So - the best solution to email overload comes from selecting the right medium for each conversation you want to have.

Try an experiment. Find a contact or colleague who is already a happy to use IM. Next time you want to sort something out with them, force yourself to use IM instead of email. See if you get better results with less effort. It worked for me.

I could be way off, of course. Jakob Nielsen classified IM as "information pollution" back in 2004. And Linda Stone reminds us that monitoring too many information channels at once can be very stressful.

On the other hand, Facebook has just introduced chat, and GMail has had built-in chat for several years. And plenty of younger users dismiss email as too much bother. (If you are going to use email, here as some good tips from a 19-year-old).

We have a landscape of communication tools - including blogs, wikis, twitter IM and email. Using them right, can help stave off email bankruptcy.

The most valuable part of the day at CHI is CHI madness, a 30 second overview of each and every paper that will be presented that day. In the spirit of CHI madness, here are three quick ideas about displaying and manipulating maps and videos. Enjoy!

Want to advance video without struggling through the scroll bar? Just click someone and move them across the screen.

Planning a route that is too big to fit on your screen at once? Well, just fold the map in your screen.
And my favourite technique, Wedge. allows you to display items of interest that would otherwise appear just off-screen.

Far too many consumer technologies are proposed to "fix" perceived problems that users don't think they have. What if we start to design technology that celebrates the good stuff in our lives instead?
At the premiere user-centred design conference, CHI 2008, Andrea Grimes presented her paper, written with Richard Harper Celebratory Technology: New Directions for Food Research in HCI which got me thinking about just this issue.

Andrea and Richard point out that a lot of the experimental systems that address food implicitly seek to find and solve some problem the user has with food. They described a few experimental systems that have been developed in recent years. One tried to help users choose more nutritional food, so if you were making a recipe with bacon, it might encourage you to half the portion size to cut down on saturated fat. Another system sought to help the user cook complex recipes by offering guidance on timing to make sure the user didn't get distracted and make mistakes.

Now, both these systems have laudable goals. Who wouldn't want to eat better food and make fewer mistakes when cooking? But Andrea and Richard argue that this focus on helping users make mistakes displays a fundamental emphasis on correcting human frailties and failures through technology. And this emphasis, to me, radically reduces their appeal to users. Who wants a computer system nagging them everytime they pull out some chocolate from their cupboard? It'd be like living with Gillian McKeith, a fate surely worse than death.

Instead of focusing on 'correcting' human behaviour through technology, Andrea and Richard argue that we should look at aspects of human life that we want to celebrate. Food is a great example of this. For many people cooking is a fundamentally creative and satisfying act that gives them great please. Eating is also a very social occasion, that can strengthen family or friendship bonds. Why not design a system that focuses on these positive elements of our lives, and thereby enriches us as humans?   

Social eating.Want some?

A fridge could suggest new recipes for the ingredients inside it, a microwave might show you pictures of your grandmother when you're heating up some of her leftovers, family members might sit around a multimedia table and share videos and pictures of their day, supporting storytelling and anecdotes. Imagine if your kitchen helped you make and share memories with your family.

 Their fundamental point applies to all technologies that impact the home and our everyday life. I won't rant about this now, but I believe that far too many consumer technologies are proposed to "fix" perceived problems that users don't think they have. So here's a question for you: Apart from anything designed by Apple and Nintendo in the last few years, name one technology that takes a treasured part of your life and makes it better.

 (thanks to wickenden for the photo)

This diagram shows a patent application recently filed by Apple for an OS X gesturing control panel.

Thanks to macRumours.com

Apple are leading the pack in gestural interface design at the moment, with iPhone, iPod and Macbook Air. (But synaptics, who make most of the the worlds touchpads, are in hot pursuit. They say they expect that "80 to 90 percent of consumer notebooks will have these new multigestures by the end of the year.")

I've found myself sitting at my desk "trying out" these gestures. Would the three-finger paste gesture, above, be easier than the gesture I already use for pasting - Ctrl-V? Note that typing Ctrl-V is a gesture in itself. And when you're well trained using a QWERTY keyboard it's pretty easy to remember and perform.

Try it yourself. Tap on the desk. What do you think?

I wasn't sure at first, but on balance, I think Apple's gesture for paste is better than Ctrl-V.

Designing the right gesture

What makes touchpad gestures better than key combinations?

• The most valuable gestures seem to encompass "degree" - not just "zoom in" but "zoom in this much".
• But even for a binary operation like paste or cut, a gesture can be simpler, more comfortable and slightly more memorable than a keyboard shortcut, if it's chosen to match an analogous real-world action. It will be easier to use if it's closer to what our caveman brains evolved to cope with.
• The position of the touchpad itself might also play an important role. I find myself wanting to throw out my mouse but keep a modified the mouse mat - a multitouch version connected to my computer. With my left hand on the keyboard and my right hand on the mat, I could mix keystrokes and gestures very comfortably.

New book on gestures

Dan Saffer of Adaptive Path is working on a book called "Interactive gestures: Designing gestural interfaces." He points out the importance of well-designed gestures. They must be comfortable to perform once or several times. And they mustn't embarrass the gesturer, or inconvenience people nearby.

The first chapter is available for free and is a good read. There's also a blog and a wiki.

Much like genres (see previous post: Can we describe interfaces as genres?), design patterns aim to create a classification scheme. Alexander created his methodology, in response to his feeling that designers in a post-industrial society lack the knowledge of materials and construction methods that people in a pre-industrial society have, via tradition. The slow evolution of tradition allows humans to adapt, slowly, in context, therefore identifying optimal solutions (optimal for humans, optimal for nature and the materials in use). To compensate for the lack of tradition in new materials and construction methods, Alexander described a methodology that consolidated research about human behaviour and the form that is required to support that behaviour into a hierarchical ‘language’.

He describes his methodology as a language with elements that have an explicit relationship up and down the hierarchy: in a way that the syntax of a language might work. Users of the pattern language identify the pattern (unit of the language) most relevant to their design problem (perhaps designing a house). They should look up and down the hierarchy to identify the other patterns (designing a street of houses or designing a kitchen) that also have an effect on the problem. In this way the designer can discover the entire context in which the problem sits and circumvent the lack of tradition.

Often with patterns the issue of stifling creativity is raised. Patterns are created and presented in a way that present the context, form and a high level solution to a problem without specifying the detail. Alexander went so far as prescribing the way patterns should be communicated: relying on clear labels, open descriptions and what he calls constructive diagrams (diagrams that appear in sketch format, describing the solution at a high level) to describe the pattern. Patterns can be used to speed up the design process, ensuring that designers do not reinvent the wheel with every new project they undertake. A designer can focus on adding to our body of knowledge and tackle new, more demanding problems when familiar and common problems clearly are described.

The question is whether we, as interface designers, can create languages that apply to our design problems? Interfaces have a history of only approximately 40 or 50 years; design patterns would definitely help us overcome our lack of tradition. There are reoccurring problems that occur. My opinion is that, yes, we could create a pattern language for interfaces if the focus of that language was user behaviour in reaction to a context and not specific interface layout.

Many people have created pattern languages for interfaces. Among the most referred to are: the Yahoo! pattern library and Tidwell’s Designing Interfaces. Both are interesting and provide insights that add to any design challenge. However I find them quite prescriptive. There is a lack of overt hierarchy and solutions seem to be specific where writers have chosen to include individual examples rather then stick to the high level constructive diagrams that Alexander described. I did find one example (after an inexhaustive search: other examples are welcomed) that I found to be true to his methodology and useful to me. The Design of Sites, although potentially out of date now, provides an almost hierarchical organisation scheme and describes the relationship up and down that scheme; informing the designer of contexts and reactions to them. Solutions are described using constructive diagrams, allowing for creativity.

I think that we are only beginning to conduct enough research to create a true pattern language and all interface pattern languages should be regarded as works in progress as there are many more contexts to understand thoroughly. We will get there however; it did take Alexander 10 year and he had many collaborators to provide us with his one example.

I was invited to talk to the students at the Akademie Fur Kindermedien in Germany on the topic of classifying interfaces. Two other speakers also spoke: Mario Giordano and Nicole Kellerhals (a consultant script writer).

We were asked: how can the rules of genre help define the creative and productive process. Immediately this statement made me uncomfortable. The use of the word genre seemed inappropriate as it promised more then we currently know. The definition of genres, in writing, film, theatre etc., has developed over a long time. When a particular genre is mentioned, instantly we (the general public) have an idea of what it refers to; take a thriller film as an example. The thriller genre has a fast pace with frequent action; they are full of suspense and often end in cliffhangers. In this way films can be arranged into clear categories, genres, which the audience understands. Producers and publishers exploit our understanding of genres in order to market new releases.

Genre is used as a tool during the creation process where authors can use the rules of a particular genre to guide them. Nicole Kelerhals spoke about this: describing the commonly understood elements of many film genres, she showed how each have their own distinctive elements. Mario Giordano gave authors instructions based on Raymond Chandler’s rules of crime stories. For example: do not give the detective a love interest as it detracts from the main story line, the mystery.

Interfaces, I feel, do not have such clear definitions or rules. I use the IA organisational schemes, taxonomy versus folksonomy, as metaphors to describe the difference:

• A producer or publisher identifies an item as it is released into a genre much like an information architect creates a taxonomy.

• Interfaces are created and released without explicit association with a type. The creators of interfaces vote for types by choosing to create them.

Genres are created in a top down method while interfaces, unconsciously, are created with a bottom up approach.

If the objective is to identify a model to aid the creative and productive process then we do have such things, but they are not genres. Without the years of development that it has taken for genres to form we need to learn about the context of use. The tools that I use in order to do this are: research, iterative design, design patterns and personas and scenarios.

Much like genres, design patterns aim to create a classification scheme via which we can aid the creative process. They do not talk about rules but outline the context, form and solution of the problem allowing the designers to resolve the problem. I talk about my understanding of UI Design Patterns in the ‘Are design patterns a truly useful design tool when designing interfaces?’ post.

Mario, Nicola and I had a discussion where they suggested that patterns were genres by another name. Could it be that in order to identify a genre the patterns for that genre need to be clear (fast pace, frequent action, suspense, cliffhangers)? Interfaces do not yet have genres, as we have not yet identified complete pattern languages for them. Each practitioner is consciously or unconsciously identifying patterns as they work. In time perhaps we will have UI genres when we amalgamate and rationalise our patterns, but we are currently too young for that as we are only just discovering the patterns.

There was an interesting online tussle recently between 37 Signals, creators of online collaboration applications, and Donald Norman, revered usability expert. Is designing products to suit yourself a good idea or not?

In a recent Wired article, David Heinemeier Hansson of 37 Signals said,

I'm not designing software for other people, I'm designing it for me.

In response, Norman said,

If you want a hobby, fine, indulge yourself. If you are running a business, then the needs of your customers come first. This means understanding them, understanding the activities they do, designing for them. [...] To say 'I’m not designing .. for other people,' is an attitude that will not only lead to failure, it is one that deserves to fail.

It's great when your users are just like you

This can't be disputed: to design a successful interactive product you have to understand your users' needs, behaviours and motivations. But getting right to the bottom of what people need and want can be time-consuming and difficult. In the dot.com world, time scales and budgets can be tight and launching your product often changes the very user behaviour you're designing for.

But sometimes, just sometimes, you get lucky: You find you're designing for people who are just like you.

Some great inventions have occurred when designers just designed for themselves. Scott Berkun, quotes two in "the Myths of Innovation": Craigslist.com and the MacDonalds' fast food production system.

I think Hansson is talking about just that. He designs apps for intelligent, pro-technology users just like himself, who need to collaborate on projects fairly similar to the kind of project he works on. And, because he's got a nice tight design brief, 100% in-depth access to the psyche of his user and a very large marketplace he delivers a very popular and successful product.

Designer expertise counts

Both Norman and Hansson agree on one thing: user involvement alone is not enough. Designer vision, expertise and discipline is a vital part of successful innovation.

Norman:

It does not mean throwing features together haphazardly. It does not mean doing everything customers request. It still means being disciplined, having a clear conceptual model of the product, and sticking to that model.

37 Signals:

If some customers tell us to add bananas to our lasagna, we’re not going to make them happy at the expense of ruining the dish for everyone else. [...] That’s why it’s our job to be editors. [...] To pick out the ideas that will benefit the most people and disappoint the least people. And sometimes that means doing nothing at all.

Designing exactly what customers ask for is usually disastrous.

And while we're at it, Steve Jobs:

We figure out what we want. And I think we’re pretty good at having the right discipline to think through whether a lot of other people are going to want it, too. That’s what we get paid to do.

A designer's vision, often informed by personal beliefs or needs, has got everything to do with the design process. Market-beating results don't usually come from just listening to users. As Henry Ford said, "If I’d asked my customers what they wanted, they’d have said a faster horse."

Lessons in successful design

Every time we have this debate at Flow, we conclude pretty much the same thing...

• Understand user needs, abilities and motivations.
• Follow a disciplined design process, inspired by user research.
• But don't just do what the users tell you. You need personal inspiration and vision as well as skill and hard work.
• So for best results, design something you believe in.