hello@flow-interactive.com flow-interactive.com @flowinteractive Flow

Archive for April, 2008

Can't communicate - too busy with email

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.

Google interface: Move some fo the load from email to chat

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.

3 comments

New mapping and video control techniques: Dispatches from CHI 2008

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.

No comments

Celebratory Technology: Dispatches from CHI 2008

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?   

Family eating
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)

1 comment

Tapping on my desk

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

Apple gesture interface control panel patent

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.")

Sme of Apple MacBook Air's trackpad gesture

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.

1 comment

Are design patterns a truly useful design tool when designing interfaces?

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.

1 comment

Next Page »