The User Experience (UX) disease

Some businesses get user experience, but for every one that does there are 999 that don’t. Companies like that aren’t interested in serving the needs of their users.

In the past Cennydd’s had to make companies take usability seriously. Now, undercover user experience is designed to help usability professionals to progress in these companies.

The Undercover Usability Manifesto

• Go undercover
• Ground up, not top down – don’t approach your boss asking for resources, just do it.
• Change through small victories
• Delivery, not deliverables
• Good today is better than great next year
• Work with people, not against them
• Action, not words

Let’s take action. Two big things you can do now:

1. Expert Review

Using heuristic evaluation. Step through processes with your website, is it:

• Made for humans – is it relevant, useful or enjoyable? Does it fit their mental model?
• Forgiving – does the site prevent errors, does it minimise them?
• Accessible
• Self evident – is it clear what the site’s for?
• Predictable – does it use known web conventions
• Efficient – is the site responsive
• Accurate

2. Analytics

This is a topic that’s not given enough attention in user experience. Looking at the stats, consider:

• Visits per unique user – are people coming back?
• Entry pages
• Bounce rate
• Referrers
• Keywords
• Navigation paths
• Registration / purchase conversions – where are the largest drop offs?
• On-site search – an underused trick. A real gold mine of understanding what the user is looking for. Test those search terms, are they finding what they want?

The real user experience process takes time. Do your business research first. It’s tempting to jump in without finding out:

• Objectives of the project
• Requirements
• Un-requirements
• Exclusions – things that cost too much or services like Flickr have sewn up

You can never find all this stuff out because it’s held in tacit knowledge. If you can never know everything, you are allowed to get it wrong. This is a relief, you don’t have to get it right first time.

The best way to be a user experience designer is to understand the culture of the company. Several warning signs exist.

1. Cash cows. Most companies have them. You won’t be able to make changes to these unless you can prove you’re going to make the company more money. These are dangerous because changes may go wrong and you might lose the company’s interest in usability. Be careful.
2. Paralysing process. It’s difficult to get new processes and new techniques into these companies. It’s only when you come up for air, that’s when people will challenge your work. Don’t be overly eager to share your work until it’s ready. If results are already positive that will skew the company’s view in your favour.

OK, real UX

You can do some quick and dirty qualitative research. Remote research is becoming a big topic in user experience. Phone your users up, yes you’ll miss some nuances, but at least you’ll get something. Speaking to your customer service staff is also useful, their insights can help you understand who’s coming to your site.

Quantitative research is also easy.

Finally, market research can give you information on psychographics and demographics. Data driven personas help you design for a particular type of user. Data driven personas don’t require much one-to-one research with users. It’s not scientifically valid, but if you treat this as a living document it’s still much easier to design for this ’person’ than a collection of numbers.

If you’ve done your research, make some small changes and see if they work, if they do you’ll start to be included in decision making discussions.

At Clearleft they use design games like divide the dollar (which I think is this) to come up with ideas.

The undercover UX designer needs to stay as low-fi as possible (e.g. pen and paper). It doesn’t matter on the tool, you need to convey as much information as possible in the smallest amount on time.

Test informally. Use a laptop and a cafe. They use Silverback (since they made it). Get people to talk aloud and explain any difficulties they have. You can even do remote testing. The videos and the output you get can be very persuasive.

You need to make sure the business is happy with the work that the user is happy with. As designers, UX people get much more then developers because everyone has an opinion. To run a quick critique session, get the stakeholders in the room. Explain the decisions you’ve made before you show them your designs. The real trick is to not get into an endless loop of changing things.

The idea is to list what needs to change to meet the clients approval and the users approval. Then get these changes signed off.

Don’t make user experience combative.

There are three tiers he uses when discussion usability decisions with clients:

1. Direct feedback from the user, if he doesn’t have that he’ll go back to the…
2. Research he did at the start. If he has neither of these he’ll fall back just on…
3. General points of good design.

Getting to know people (and beer) help the process.

Q and A

I didn’t really take notes on this except he mentioned a new service called Performable just out of beta, worth checking out. Of course you can use Google Website Optimiser as well. Of course, this presentation was also a lead up to his own book, Undercover User Experience.

He also mentioned a book by Dan Saffer, Designing for Interaction.

Some background about the presenters

Presented by Molly Stevens from the New York office and Jens Riegelsberger who works in London. Jens works on Google Maps. Before working for Google he worked on Microsoft’s Xbox 360. He got into usability ten years ago. Molly is a user experience researcher who’s been with Google for three years working on products for advertisers. She has a Masters from Georgia Tech University.

What is user experience at Google?

Some can’t understand what research and design goes into Google products. What do you really need to do to a search box? The point is, the box has stayed the same for all these years. The focus for Google is on simplicity and the core task. The User Experience department is a small part of Google, the number of people employed in it is in the low three digits. For comparison, Product Management is larger – in the low four digits and Engineering larger still – in the low five digits.

Google’s approach

The most important thing is be agile for your users. A lot of what they do is data analysis. For example, with Google Analytics they conduct a lot of A-B testing, just like the functionality in Google Website Optimiser. They invite people into user testing labs to observe and test. They also do in-the-field observations. For example at Victoria Station in London, they did ad-hock observations of how people navigate. They also look at how people navigate shops etc.

Adwords (case study)

Molly displays a picture of an advert-laden door in a street in Cairo. This is the original Adwords. Targeting users to give the most relevant content possible is important for Google. They go into offices to see what kind of data people need as they use their products. They notice the equipment people use, computers, notebooks etc. Context is important.

Users don’t often appreciate their own behaviour. A lot of people ask ‘who really clicks on ads’ in Google products? People do, they just don’t know it. Some background: The system is designed for realtime; it’s a pay per click model of advertising; with Adsense, bloggers and publishers can make money on their websites with ad blocks; ads are made relevant to the content of the page.

In 2007 they started a project to update Adwords, it hadn’t been updated since it was built. Since 2003 they’d added more tools like Ad Scheduling. Additional reports and tools were coming into the interface but the framework wasn’t there to support it. User experience was asked to understand what the experience is now, plus it needed to be as usable as possible around the world. They focussed on three things:

• Lab studies
• Field visits (to understand context)
• Task analysis

They travelled the world to get to diverse markets. Visited large advertisers and small businesses and other users of their service. One example – they went to a small Canadian business that GeoTargets Ads to Canada (picture shown of small mom-and-pop business), the owner finds it works.

The researchers came up with some key tasks. They focused on the task that advertisers spend the most time on. In the new Adwords interface, things that came out of this:

• ROI – needed to be clear to the users, so they could tell what they were getting from it
• Efficiency – with the task and analysing ROI
• Clarity – how clear can we make it about exact costs

Design principles in addition:

• Speed
• Guidance – important to be given at the right time
• Consistency – so users are thinking about the activity not navigating the interface

The redesign took two years from 2007. In 2009 they visited Google advertising agencies and search marketers in Mexico City and used them as a test model. They looked at two things:

• User experience now
• What’s happening in the field

They found Mexico was similar to other markets but some of the pain-points were exaggerated. E.g. If you’re in Mexico city the traffic is really bad, also it’s also difficult for advertisers to target people in their local vicinity based on the technology available. However even new people with little marketing experience were happy with Adwords. Google expected more unhappiness, but couldn’t find it.

Some things they saw:

• One of the larger advertisers set their language to English(US) which meant the date format defaulted to US format in the interface. So there were some things they were able to fix on the product
• In Mexico there were less people educated in the web, there’s a much less robust tech infrastructure and level of knowledge about how to do things effectively. Google identified a need to find a way to get this knowledge into the population.

Changes to Adwords from this work – they set up a navigation panel and gave deeper links. They also added a help widget that gives relevant content for the topic of the page.

Google Maps for mobile (case study)

Jens presented this case study starting with explaining a field trial from two years ago. The UK and Germany had poor uptake of mobile maps. They went to Hamberg, Munich, Manchester and London. They had  six people in each location using the maps software on their normal phones. They had install parties. Where phones don’t come with it pre-installed, getting maps onto the phone is the biggest hurdle (depending on the phone, of course some have app markets).

In the study they asked to record the participants’ searches and sometimes even called them to get the context of the searches. Through this they got detailed information on the goal, plus what did and didn’t work so well.

They went back after two weeks. They found that some small issues get larger by rubbing people up the wrong way over time. One such feature was that the map reverts to default view every time you start it. This upset people on their mobiles since they may want to start the map where they left off.

They set competitions to test the speed of the app vs. the real world equivalent – for example, go to a petrol station and ask someone directions. From this they realised minimising app startup time was important.

Zoom function. The engineers assumed people would learn the maps interface (‘They’ll find the zoom button the second time they use the app’). Using these real world tests they could show people had difficulty finding the button on repeat use. The interface had to be changed.

Jens’ favourite bug story was of a Manchester participant who tried to pull up Manchester Airport, however in maps she found herself teleported to Manchester Airport in New Hampshire (US). App  teleporting, or ‘warping’ users over to the US has been improved but it’s still not perfect. Importantly they combined real usage with detailed logging to find these problems.

Driving directions in India (case study)

The question, what’s the best way to use Google Driving Directions to show which way to go? Even with complete data a list of turns would not be good. The initial research on this happened in India and the US, they spent a long time looking at human way-finding. From this research they came up with a proposal that was literally test driven in India through the busy traffic using landmarks. The final product was launched in November 2009. They decided to includ confirmation landmarks in directions (as well as turnings), but these weren’t necessarily places where you change direction.

Google Maps India uses a Wikipedia model, maps and landmarks are contributed by users. Google chose to give colloquial directions to people to make it clear in the same way you’d give directions to a friend, this took a lot of engineering.

Five things they’ve learned

1. 20% products are important to Google. Molly and Jens work on the usability of other people’s 20% products. For example, an engineer worked on search insights looking at the top five things in rising search trends. They turned this turned into flu trends, they found this correlated with actual cases. Countries are now using this to track diseases. In fact it was used in Mexico during the swine flu outbreak.
2. Prototyping. Important to do. Sometimes using a paper prototype is good or engineers hack something together.
3. Launch early and listen.
4. Observe in the field. A recent study in Tokyo showed that a large number of users take pictures of PR codes (not sure what this is?). Instead of using maps on their phone, they bring up Google Maps on a computer and take a picture of the screen with their mobile.
5. Everyone at google is a gatherer. The usability guys collate. Being a user researcher is often like being a doctor, you diagnose.

Q and A

Q. With the 20% projects, what’s your process of selection?
There isn’t one.

Q. Where do designers fit in this?
(Jens and Molly only mentioned designers once in the presentation). They work so closely with the designers they forgot to mention them. They are a part of the same team as the Interaction Designers etc. Jens and Molly only emphasised engineers because they wanted to stress their importance. Besides, everyone on the Product team came from an industrial design background.

Q. Road names change, some have two, some don’t have any – how does Google Maps handle that?
This happens in India quite often, it also apparently happens in Greece. Every road can have multiple names in Google Maps. Google also like to emphases other aspects like landmarks.

Q. Questioner likes the idea of 20% projects, are they peer reviewed?
There are project fairs (where employees can pitch for help with their project) but no review board. 20% projects are bottom up, if it has a good technology it might grow naturally.

Q. Do 20% projects get shoved to the bottom of the pile? Do employees end up spending 2% of time on them? What happens when things get busy?
It varies from person to person. You can bank up time so the deadline for your main project is passed you can sometimes spend weeks on your 20% project.

Q. Does Google prefer usability stats over qualitative insights?
The most effective is a combination of the two. For example, the teleporting maps problem in Manchester. This was taken back and found to have happened more often than they would have liked so things were changed.

Q. Do you ever take a lead in the research strategy? Meaning, is it always lead by engineers?
The Google Maps India landmarks research was a good example of a significant project (over two years) that was driven by the Product team.

Q. Field studies. You mentioned one big one, but do you think you spend enough time in the field?
Field studies happen in parallel and in multiple locations. Jens actually feels he spends too much time away.

Q. How do you keep up with all the products that Google produces?
We don’t. The Product team are a limited group.

iMetLion.com

He started off by explaining from personal experience, how autism affects the way people use the web. Autism is about processing. It’s just a different way of thinking. Most people with autism are affected by changes in sensory input. For example, Jamie sometimes can’t read when there’s a background sound. So having an audio file play when your site loads is not only irritating it’s inaccessible.

Language processing can also be a challenge. When people talk very quickly he often can’t keep up. For example, when web videos cut quickly from scene to scene he finds he gets left behind, he has to rewatch them over and over. This can be stressful.

Following a theme from the previous presentation, Jamie expressed an issue with literal commands. His experience is, early in his life when asked to wash his hands ‘in the toilet’, that’s literally what he did. Subtleties in life and on the web can cause problems. For example, when adding friends in Facebook, the function performed by the site can be different depending on the context. On some pages the functionality is to simply add people who are already registered, on other pages you’re expected to enter their email addresses.

After this initial section the presentation changed format. Seeing as it seemed to have worked in the past, Jamie then struck up an interview dialogue with Henny. She posed questions along with the rest of the audience. The next bit follows that format (with a stream of consciousness thrown in).

Q. You said with video you have to rewind. This would be awful when streaming video (e.g. iPlayer), how can this be made more comfortable?

A. Captioning and transcripts. The BBC now has a nice live text captioning system using HTML5. However, sometimes he uses a screen reader when he gets stressed, Jamie explained. In fact, to help him process information he built his own screen reader using a Mac, the inbuilt VoiceOver and some AppleScript. His reader uses Microformats and embedded semantics. He built it because he uses non-sighted navigation quite often to understand a page, but can find this difficult because the visual and code order of the page are often different. This means unmodified VoiceOver can be difficult to understand. Using AppleScript he gets the website to read in the order he wants. Snow Leopard now has intelligent select so VoiceOver has caught up with what he needs.

Q. Is his screen reader source available?

A. Err… Yes but it’s hacky and built specifically for him.

Jamie is keen to break down assumptions on assistive technology, it’s not just blind people who use screen readers. With this in mind, his opinion is that web designers should not use the title attribute. He’s noticed an obsession with using nice long titles. Often web designers use title and ALT text plus the usual copy all at the same time. Jamie hears all of them. An example of this is the Amazon website. It’s really accessible with all of these attributes, perhaps too accessible.

The discussion moves to VoiceOver and any specific features that make it easier for Jamie to use:

• Detection, one to one representation of movement on the keyboard and movement on the screen, this is new with the Mac gestural track pad.

Of note, screen readers can be too fast for Jamie. Also there are some that try to sound clear and others that go for a human voice. So which does he choose? His answer was enlightening, he chooses a human sound if the page is written in a human voice, this helps his understanding. Concatenative speech engines sound better but are less responsive. Most developers are not even aware that there’s more than one voice. One problem with VoiceOver is it can take too long to read keywords.

Q. Did he create his own presentation design?

Yes. ;)

Antonia (hiantonia.wordpress.com) has been working in accessibility for 10 years. She’s a web designer and consultant. See Antonia’s notes at her blog or see her slides.

Her belief is that people are not defined by their disability, partly because they could have many. There are lots of ways to go online, not just one fit. Learning disabled people have increasing control of their lives, and expect to be able to use the web. On the web people like to take their time and not feel judged by their disability. However, many people are locked out of websites. Design is often the key to whether a site is accessible.

Antonia played her first video interview. It features Martin, a man with autism, using the eBay site as Antonia sits beside. Generally he likes it. He likes the wealth of information displayed and the clean layout. He could comfortably associate items with the descriptions. For him the interface fails when he sees the first ‘buy it now’ icon.

He clicks on it, gets confused when nothing happens (it’s not a link) and this stalls his flow. Once he was through to the product page he understood what parts of the page were actionable.

Websites sometimes use context as part of their interface, this causes issues for those who fail to pick up on such subtleties. That’s a cognitive accessibilty problem.

Next Antonia asks Martin to visit the Amazon website. He likes it, it’s nice and bright with lots of colours plus using search is OK. But Antonia asks ‘How would you buy an arsenal shirt?’ He selects a size, this brings up another window with sizes to select. It puts an orange border around the selection, he notices that the information on the right side of the page changes. He knows where the checkout is because the icon looks like a shopping cart. Beyond this he gets frustrated. He thinks the link to account is the ‘go to shopping’ button. He’s right, it’s hard to find. How to logout? He finds this difficult as well. He either wants to close the browser window or use the back button. In the end he had to be told where the sign-out button was.

Generally the Amazon site doesn’t have enough good or meaningful icons, in Martin’s case he only understood the shopping cart. Signposting was not relevant. There was bad typography and poor contrast between elements. Buttons were not defined enough, this denied Martin access to parts of the site.

But won’t catering for people with cognitive disabilities cause more design ‘noise’ on a website?

When designing for cognitive accessibility, making everything literal is key. In the same way as designing for someone with a physical disability, making your site accessible can often benefit everyone. Antonia displayed a poster meant to convey the message not to run on the tube. The poster was less than clear. Making it literal, e.g. with a big red cross over the runner, could’ve improved the explanation for all.

Design advice

• Use a hierarchy of visual language, e.g. headings that decrease in size.
• Group elements of a similar type or function. Sometimes less is more. Anecdotally, Antonia surveyed eight people and only one knew what ‘i’ meant when signifying information, the rest understood ‘?’. Sometimes it’s good to have one link that takes us through to a page that groups things together.
• Sometimes different sized icons are useful. Apple’s Interface Manual uses different colours for different contexts.
• Hovering states are really useful.
• Colour coding is also really useful, despite designers sometimes thinking it will ruin their design.
• Giving users alternative ways to change text size is important. They often can’t remember (for good reason) where to do it in the browser. Education can be the key here, often people don’t know the difference between a browser and a website. Discoverability for preferences is an issue. Just being able to get back to the view window is important, sometimes this becomes a major challenge.
• Use adequate spacing. For example, the BBC homepage is complicated but good because things are grouped with adequate gutters. Putting things into modules makes them look bigger.

Is this my responsibility?

It’s not just down to developers. It’s everyones responsibility, including the browser makers. Cohesion and consistency when working as a team is important. Martin was a confident user, but most people think their inability to use a web interface is their own fault.

Where to go from here?

Where can we get more information?

• Changepeople.co.uk are working on a manual for this kind of accessibility.

With its Symbian OS, I’ve always recommended it with the warning that it’s a bit of a geeks phone. Downloading applications from the net, they don’t go through the same vetting that takes place with the Apple App Store. Some can be a little less stable than others and in some instances they conflict. Feature-wise it’s a solid phone if you’re prepared to perform the odd restart and fault find.

I’ve always thought it’s the utilitarian answer to the iPhone. Where Apple customers are until now unable to copy and paste, you can with an N95, but the button is somewhat hidden. Patches, fixes and apps exist for the Nokia where the system is not as locked down. What’s great about the N95 is that, where the need arises, someone’s usually solved a functionality problem in advance. The answer is hardly ever ‘we don’t support that’.

So before I get swept away in Apple and Palm hype, I thought I’d log my favourite apps. Here goes:

• Fring. One of my favourite apps for functionality. It links with Skype and you can have what looks like a normal phone call through WiFi (free if you’re calling someone on their computer). I regularly talk to people in Australia on this and after a few hitches (generally with the net speed at the other end) it now works perfectly. It also works with other social networking sites.
• Gmail. An amazingly fully featured app from Google. It keeps a local copy of your email but syncs with their server. You’ll never lose a message and it has better functionality than the iPhone app. I’m able to search, a feature iPhone users have only had through their web version up until now.
• YouTube. Another Google usability triumph. Although it doesn’t always seem to be as up-to-date as the web version and clicking on browser web links don’t open the app automatically, it does have one killer feature: it’s the only app I have that (without hacking) streams video over the 3G network. Really useful.
• Google Maps. Simply amazing. This app takes advantage of the inbuilt GPS receiver in the phone. With this I’m never lost, I can always find directions to a destination from my location to within a few metres. Coupled with Google Latitude, it’s a great tool for keeping up with people across London. I can also access Google Street View from my phone, I can’t count the number of times this has been really useful.
• WirelessIRC. Despite the name red-herring, I actually use this to access Twitter. Unlike most other Twitter apps, it runs happily in the background. Whenever I want to update myself on other’s activities I can immediately view, rather than take the time to launch an app > connect to the network > download tweets etc etc. I can easily copy and paste text to re-tweet (RT) and using Nokia’s inbuilt functionality, I can copy and paste posted URLs to my web browser. (NOTE: On the N95, the copy and paste functions are found under the key that looks like a pencil on the bottom left below the screen).
• BBC iPlayer (1.5). Although newer versions exist, they seem to have been blocked from working on the N95. Don’t despair, you can still download the app from sources across the web. BBC iPlayer is a fantastic boost to the multimedia capabilities of this phone. As long as you’re not worried about the jump between the listings app and the in-built RealPlayer to stream programmes, you’re never going to miss a programme again. Shame it only works on WiFi (unless hacked) and doesn’t support downloads.
• Opera Mini. A web browsing experience comparable with a PC. I use this mainly to access Google Reader. The Mini browser comes with the ability to create ‘bookmarklets’, something that when mixed with a little Javascript, allows me to post interesting links to Delicious. All of this functionality is a life-saver on long train rides (or even the cramped commute to work).
• Web development apps such as SIC! FTP and s60HTMLed. This combination means I can effectively edit web pages from anywhere. s60HTMLed is a great application but takes some setting up. You need to download Python for S60, the ‘appuifw2′ extension and in my case I had to Symbian Sign the web editor.
• Shozu. A multipurpose photo up-loader that allows me to tag and describe pictures that I upload to Flickr.
• Snaptweet. A service that scans my Flickr account and adds pictures with the ‘snaptweet’ tag to my Twitter stream.
• GooSync. Synchronise your inbuilt calendar with Google Calendar. Simple and effective.
• Last but not least, the other inbuilt features like the WebKit browser (yes, the iPhone isn’t the only one that comes with this); 5Mpixel camera; and accelerometer for quick transition between landscape and portrait display. (NOTE: to set the display, go to Menu > Tools > Setting > General > Personalisation > Display > Rotate screen ‘Automatic’).

My advice for N95 users is to every-so-often, backup everything and look for system updates. I think an amount of this functionality will not work, or would be more buggy with older software. Where lots of phone manufacturers forget about updates only months after release, Nokia have been consistent in their support so you may as well take advantage of this goodwill. The phone isn’t perfect and there’s lots of other software I haven’t mentioned, but I thought I should acknowledge this phone’s 15 months service to me before I upgrade.

Apart from the BBC internet blog and backstage etc. @media 2008 had the fortune of hearing a whistle-stop tour of the redevelopment of the BBC homepage. This site has haunted many web designers since it’s launch with comments from colleagues of “Why can’t we do… {insert name of feature here}… like the BBC homepage?”. It became a shining example of what can be achieved.

Tom Cartwright and Claire Roberts presented their short piece on the development of a site that: took them three months to build; had to cater for 6 million users per month; couldn’t contain loops in the code; couldn’t process XML; had to be accessible; where 5% of users (that’s 300,000) didn’t use Javascript. This is web development at the sharp end.

A point of interest is that they managed to get 60 image requests down to just 3 using sprites. This had the affect of reducing the number of HTTP requests, a big saving on a highly trafficked site.

The size of this project is reflected in the fact that the development team recognised a need to drop JQuery as a Javascript framework and develop their own. Tom described Glow (www.bbc.co.uk/glow), a new framework that supports Safari 1.3 (apparently unlike JQuery). We were told that Glow would be available as open source software towards the end of the year, but judging by the password it looks like this still hasn’t been finalised. They also mentioned that their next project will look towards a pan-BBC identity system for users. The idea is that they’d have implicit and explicit personalisation and that, once logged into one BBC site, your credentials would follow as you traverse the sites. In support of this the BBC joined the OpenID federation, looking at becoming a consumer.

For insights into the future of the BBC homepage see www.bbc.co.uk/home/beta/. They recommended Steve Souders’ High Performance Web Sites (he really knows optimisation).

Jeff started by describing his childhood in the 1970s and how at the time the world was changing around him. At a young age he came across a pong game encased inside a table at a restaurant. For him, before then media had been a passive experience, suddenly there was interaction. He terms it as society going through a “conceptual progression in how we can communicate”.

He went on to describe how this expectation picked up momentum as data storage became cheaper and computer processing became more powerful. In his view Moore’s Law works across all technologies. The two key aspects vital to this revolution where the tools for participation and the scale of data.

In 1973 the IBM Winchester 3340  was released with a capacity of around 70Mb. On release it cost $100,000. In comparison, Google currently archives 4 – 5TB of data every afternoon. From this we see that the tools have developed massively and so has the scale of data.

Designers must turn this raw data into information. Whether or not this is achieved is a subjective judgement as it relates to perceptions of the audience. Jeff’s example was to communicate monthly rainfall based on the size of a cartoon raindrop. If the audience had been meteorologists, they’d probably have preferred a numeric representation, perhaps in inches or centimetres. So it is the job of the designer to remember to take the design of data from decorative to actionable. Success comes when the designer has managed to “convey promptly to the eye something that would otherwise require mental calculation”.

A great example of this was John Snow’s mashup of Cholera deaths and location (a street map). Just as valid is Charles Joseph Minard’s map of Napoleon’s March to Warsaw. Edward Tufte was another statistician who used chart’s to bring out the story with the crash of the challenger space shuttle. Also of interest is the air and ground traffic visualisations from Britain from Above (although mostly for entertainment purposes). All were designed to get the heart of the story without being untruthful.

Google Analytics was designed to do just this. Jeff’s tactic with this was to shelve any ideas and reassess them two weeks later. His inspiration for the final graph design was a travel montage from the film Indiana Jones. :)

The point is that the audience is all important. In his work with Adaptive Path, he would identify what people want to do, not what people want – an important distinction. They would take transcripts of user interviews and take out sections that sounded like tasks. Charting the mental model with sticky notes helps provide vital communication for designers and managers. To get the product to production, look at all the options and reduce down to only what you need at launch. What we leave out is more important than what we leave in, we must remember to tell the story.

Some further reading: The Ghost Map, Anything by Edward R. Tufte and of course the presentation.

So, this got me thinking about the whole concept of the click. What is a click? How central is it really to our experience on the web? Can we do without it? And if it was taken away, what would that web look and feel like? Read on for my research and opinion.

Background, FYI

(For the uninitiated, which included me to some degree). Computer mice and clicking have been with us for a while. The first commercial computer to include a mouse was the Xerox 8010 Star introduced in 1981 (according to Wikipedia, I was only just on the planet at this point so can’t vouch for it). Since then the concept behind clicking has been adapted to other input devices including trackballs, touchpads (generally used on laptops), touchscreens, graphics tablets etc.

Clicking is bound up in the WIMP (Window, Icon, Menu, Pointing device) approach to GUI’s (Graphical User Interfaces) and relates to the user clicking and selecting a part of the screen to activate a command on the computer. Before the GUI and the mouse, text based interfaces were dominant and the return key would be the usual part of the keyboard that did the activating.

Since its development, clicking has been so fundamental in the WIMP world that input devices such as touchscreens have extended the concept to variants such as ‘tapping’ etc. The terms may change based on the user experience but the general interaction remains the same, again due mostly to the unchanging fundamentals of the 2D GUI.

How does this relate to the web?

Clicking helps to define the overall experience of the web. For example, it’s the last action before making a payment to make a purchase. It’s in the modern psyche as an expression of intention. Amazon patented ‘1-Click’ in 1999 as it ‘refers to the technique of allowing customers to make online purchases with a single click’. A lot is happening behind the scenes, but for the user this is reduced to a single action/concept. Other examples would include the proliferation of hyperlinks with explanatory text like ‘click to proceed’, ‘click to pay’ and the dreaded ‘click here’.

It’s always interesting to me how the popular perception of a thing shapes its explanation. This is because, of course, for some ‘1-Click’ is actually ‘1-Press-Return-Key’ or ‘1-Tap’. Clicking doesn’t naturally enter into the experience of a command line user or someone using certain types of assistive technology. What is universal in these examples is the activating of the command to progress to another web page or buy a product. This is a fabulous example of why the link text ‘click here’ is so nonsensical (and on its own so non-descriptive and just lame).

Of course the web is built on the hyperlink and for most clicking has become central to this interaction. Which brings me back to dontclick.it. What happens if the click is taken away? Well, it’s disconcerting at first. However, even though the website is initially a strange experience, I found myself getting used to it quite quickly. This made me wonder why I’d been such a blind follower of the click for so long. I’d never questioned.

Click-less future?

Now onto a general theme for this blog; Apple. They’ve just released the MacBook Air to predominantly positive reviews and despite its other boundary-pushing features, the one they’re most keen to promote on their website is the ‘multi-touch’ gesture support.

For the first time, they’ve brought multi-touch gestures from their successful iPhone and iPod touch products into their main computer offering. Although these features don’t replace the click, they could point to (pun intended) a future without it. What about a Minority Report inspired interface where ‘point and click’ becomes just ‘point’?

For many years, Apple’s relationship with the ‘click’ has been embroiled in the one or two button mouse debate. Seasoned computer users have derided their choice to stick with one button mice and even now their offering is a kind of fudge.

With the correct interface, could the click be superseded by a gesture? Gestures in computing are nothing new. Again, according to Wikipedia, the first mouse gesture was “the ‘drag,’ …introduced by Apple to replace a dedicated ‘move’ button on mouses shipped with its Macintosh and Lisa computers”.

For most, removing the click would have a fundamental impact on the psychology of human computer interaction, as expressed in this quote from the dontclick.it site:

clicks make me think of isolated segments this is immersive.
01.17.2008 msg# 37833 by ‘roger doonan’.

Apart from the psychology, what about accessibility/usability? By extension, some replacement for the mouse (pointing device) could help those with motor control difficulties. i.e. not having to click on exactly the right pixel on the screen. Take it a stage further, replacing the keyboard with a gesture based interface could revolutionalise computer usage for those of us for whom the standard QWERTY keyboard represents a barrier.

The end is in sight

There are lots of interface design problems that would need addressing before the clicking could ever stop. I wonder how complex a system could get before a gesture became indiscrete enough to place ambiguity between it and the user. I also wonder if computer interface designers will ever get to purely gesture based interaction without a paradigm (I got that word in Rik!) shift from creating more and more complex interfaces, towards distilling it right down to what the user actually needs.

These are just my thoughts on what may be to come. As always I’m hoping to add to any discussion that’s taking place, this is not a bid for revolution (although could you imagine an online petition to abandon the click? “Click here to abolish the click!” – wholly hypocritical).

Update 22 February 2008: “Apple Depicts Advanced Multitouch Gesturing Control Panel in Mac OS X” – an article written a couple of days ago about possible developments using muiti-touch.

This week I’ve found myself reading Read/WriteWeb more and more. If you’ve not seen it, they produce thought provoking articles on all sorts including some that analyse the past and offer an academic look at the possible future of the web. In the last few days I’ve been contemplating their posts on “Visualizing Social Software Best Practices: Three Approaches” and “Social Graph & Beyond: Tim Berners-Lee’s Graph is The Next Level“. These posts led me to Tim Berners-Lee’s “Giant Global Graph” and Google’s ‘light-hearted’ “Social Design Best Practices“. I found these good for getting to grips with possibilities for the web’s future direction. What’s interesting is that it all seems to tie together the thought as Tim quotes:

It’s not the documents, it is the things they are about which are important

Anecdotally, blue flavor alluded to this last week after recapping on FOWD with the statement ‘content is still king.’. Well actually Tim abstracts this even further by stating it’s what the content is about that’s important, but both follow similar lines by stating the importance of ‘situation-appropriate’ web access (another quote from Tim’s post).

So after digesting all of that freely available info, who needs to go to conferences like @mediaAjax? We’ll actually I do and I was quite sociable at the after conference gathering, although I didn’t have the moola to attend the event.