Slaughtering the holy cow - greatness is not forever

A couple of weeks ago, on World Usability Day, I met up with a couple of people in a Manchester pub to talk usability. Our consensus had been that going to the pub was definitely the right thing to do (is this the reason Silicon Valley didn't happen in northern England?) but to keep on message we each had to bring an example of bad design that we thought could be improved.

The first thing that popped into my head was Google. Something I use every day, and that generally makes me very happy, but that I've becoming more frustrated with in recent months. The primary reason for this is that Google lets you search the web, or it lets you search news, or it lets you search images. It even lets you search blogs and video.

My problem is that sometimes I want to search the web and images. Sometimes I'd like to search news and blogs, or perhaps news and video. I can't even find Google's own blog and video search engines without Googling them!

Also, I quite often want to do what Google consider advanced searches. Now, if I was a good geek I'd remember all the syntax to do this in the front page search box, but I'm not. I've only just nailed that it's "-" to exclude a word, not "NOT". And I'm fairly sure I don't use some of the advanced options that I might, because I need to remember they're there - the options aren't available for recall.

So, my solution is to keep the Google page nice and simple - indeed to enhance the simplicity of the page up at the business-end: the text box. But then to add options to search across different types of content directly on that front page.

I'd also like to bring some of the advanced options up to the front page - if I worked at Google, I'd find out what the most popular types of advanced searches were (perhaps they vary by location?) and put these on the front page. As I don't, I've just selected a few at random for the effect.

So, what do you reckon? Do you think this is an improvement?

(Click for a bigger version)

Navigating in the real world

I've been thinking recently about road signs. The long winter evenings really do fly by...

Navigating your way through a city is a complicated problem. There are many thousands of potential routes, many things to find. As a user (or, you might call it, driver) you usually have an idea of where you want to get to, but you need help to choose the right path out of the hundreds available.

You pass through many decision points, and it's important that it's clear to see which one to take. If you take the wrong one by mistake you need further help to get you back on track. And if you get really lost, you need a clear indication of where you are so you can find your way to the correct route.

This all sounds kind of familiar doesn't it? Sometimes, when driving a unknown route (particularly in a new city) you get hopelessly lost. Sometimes though, the signs make it easy to find your way. All of which got me thinking - how do the people designing signed pathways through cities go about it? What's their methodology? How do they work out optimal paths, and make sure they're properly signed? What can information architects and web designers learn from them?

I haven't found out yet, but I'm going to carry on looking. If anyone can point me in the right direction, I'd be very grateful.

Build it, and they will come

I'm part of a circle of friends with a strong interest in music. Just over a year ago, four of us happened to be sitting in a bar (the rather atmospheric Cord) bemoaning the fact that we didn't listen to much new music. Then someone piped up with the idea of forming a new music club, which turned out to be titled (with tongues-in-cheeks) Cutting Edge Club.

The premise of Cutting Edge Club is that these four friends nominate three songs every month, and those songs have to have been released in the past year. There are couple more rules, but that's the basic idea.

After just over a year, it's turned out to be a great personal success for us: we've listened to loads of music that we wouldn't have listened to, bought some great albums as a result, and had some great evenings chatting and generally navel-gazing.

"Great", you're probably thinking, "what a fascinating slice of your life. But where's the user experience?". The user experience is in social networking, of community-building, and user contributed content: simply Web 2.0.

We already have a thrown-together and not very well maintained website (http://www.cuttingedgeclub.com/), but we were thinking about how we could enable other people to have the fun we've had. And, more than that, how we can have more fun by listening to more music we haven't heard before, and maybe learning about people we don't know.

The answer, it seemed to us, was to build a platform for a community: a platform because we wouldn't provide anything except:

• some rules
• an easy way to get started
• some help with communication

This is in the same vein as one of my ultimate favourite sites: Last.fm. And, thinking about some of what I've recently be reading from the 37Signals book "Getting Real", we don't even need to worry about scalabilty. I'm not convinced how sound that proposition is for a commercial enterprise, but for an organic hobby enterprise it probably makes sense to not worry about having 100,000 users until you've got 1,000.

So what's the point? Maybe all you have to do is build an ideologically well-structured, solid, useful platform that your users can develop themselves, and everything else will fall into place...

The separation of the design from implementation - the age of the designer cometh?

I've been learning a (very little) bit about the Windows Presentation Foundation (WPF) of late. WPF, for those who don't know, is the new foundation for Windows UI application development in Vista, replacing Windows Forms.

Now the exciting bit of this, as I see it (and I could be utterly wrong) is that the design of interfaces will be in an XML-like language: Extensible Application Markup Language (XAML). This enables, theoretically at least, an interface to be designed completely independently of an implementation, and then that XAML interface design to be used by one or more implementations.

For non-coding designers, like myself, this offers the possibility to use tools like Microsoft Expression (which I've not had time to download and play around with yet) to effectively produce interfaces and leave the implementation details to programmers. This sits perfectly with my philosophy of designers being architects (considering how buildings work to support people, and making them a pleasure to use) and developers being civil engineers (making sure the materials are right, the building stands up, and the heating works).

This framework releases both designers to design and software engineers to engineer, and has the potential to save much duplicated effort, a lot of wasted time, and to produce more useful, better engineered products than before. Whether it will work like this is another thing, but it's an exciting thing to contemplate.

Going all Gliffy - diagramming online, portable, and free

A couple of weeks ago I found out about a thing called Gliffy. Can't quite remember where, otherwise I'd happily give them credit.

Gliffy is an online diagramming tool, in the style of Visio. Obviously it has nowhere near the feature set (and some quite annoying quirks - inability to set defaults, and no distribute option being top if my list) and it's not quite as reactive. But, and it's a big but, it's:

• Free
• Web-based
• Easy to use

So, if like me, you use a number of different computers in different locations and getting things done quickly is sometimes more important than getting them perfect, I heartily recommend you roll on by and check it out.

Lost in the World Cup

My online presence has diminished greatly over the last 12 days: this blog is not alone. It's all down to the festival of football™ that I am powerless to resist. Saudi Arabia vs. Tunisia was alright, believe me....

I do have some things to post though and will be back soon: the days of the designer cometh.

Are all your users right-handed? Or is it just you?

I was reading an article on the BBC's website (again), about the new controller for Nintendo's forthcoming Wii console. It's being demoed at the E3 games expo in Los Angeles, and it seems like a real breakthrough in interaction.

There are two controllers: one for each hand. One of the controllers is long and thin, one round and curvy. The examples of the games on show at the Expo include a tennis game, a golf game, and a couple of shooting games. It sounds great for tennis: there's an avatar on the screen, and you swing your long thin controller as if it's a tennis racquet and your avatar hits the ball. This is so much more like playing tennis than playing with a normal controller - great innovative stuff.

The shooting game is apparently a bit more difficult to get used to, as you shoot with the long thing controller and use the curvy one to move around. The interesting thing though, is that throughout the article it's described that you hold the long thing controller in your right hand and the curvy one in your left hand. So you play tennis with your right hand, and you shoot your gun with your right hand.

The question is: can you switch hands? The Wikipedia article doesn't mention explicitly which hand you should use, but all the pictures show the long thin controller held in the right hand. This blog suggests right-handers only.

I hope you can use this controller in both hands: it's a really exciting development. I don't see why you wouldn't be able to switch hands, but if you can't then 10% of the population are going to be pretty disappointed (and 50% of chimpanzees). As a left-hander, I have my fingers crossed....

And the lesson to be learnt? Same old lesson: know your users. Think about who they are, what their characteristics are, and what they want to do.

If only I had a pistol . . why are you letting your users do things they're not allowed to do?

I heard about a man in Colorado who shot his laptop because it kept crashing on him. This story, which is a couple of years old now, illustrates just how annoying computers can be.

My view is that computers should avoid being frustrating wherever possible. Or, rather, that designers and programmers should do everything they can to make their devices and software work for the user.

I've just had a very frustrating experience. It's frustrated me on a number of levels:

1. It's told me I've done something wrong, even though it could have stopped me from doing it.
2. It doesn't give me any assistance to solve the problem.
3. The only way I can tell if I've solved the problem is to keep on submitting the data, and be told over and over that I've done the same thing wrong.

This is the technological equivalent of someone pointing their finger at you and laughing. It's unforgivable. And what makes it worse is that it's the fault of one of my all time favourite organisations, and web sites, the BBC.

Here's what happened to me, after I'd written a well-balanced, witty, and dignified comment to a story on the 'drought' currently being suffered by the UK.

So why did you let me type 501 characters? Why not stop me at 500? Or, if you don't want to do that, why not tell me how many characters I've typed so far? Or if you don't want to do that, why not tell me, once you've rejected the message as too long, how many characters I did type?

My only option, as far as I can see, is either to delete the message bit by bit and keep on trying to submit it, or to manually count all the characters in the message. This is nuts, it's crazy, and it's the most infuriating piece of interaction design I've come across for a good little while.

Now, if only I had a pistol....

Is you interface or website already lost in the first blink?

I've recently been reading a fascinating book. It's by Malcolm Gladwell, and it's called Blink.

The thrust of the book, if I've understood it correctly, is that your subconscious makes decisions very quickly, all by itself. This is absolutely vital for our survival - you couldn't for instance, make a rational decision about whether to step out of the way of a speeding car.

Your subconscious makes these decisions based on a number if things, including the experience you've had before (so if you learn about something for years you're likely to make better intuitive decisions), and things that have just happened to you (if you do an exercise with lots of 'polite' triggers, you'll be more polite straight afterwards). And, as people we can't even explain the decisions we've taken: we'll make up explanations that aren't, in fact, even true.

Now this is an interesting book in its own right, but it also got me thinking about how people's instinctive responses to interfaces and other interactive devices might affect what they think of them and how they use them. It took me back to the presentation I saw by Alastair Sutcliffe, described in an earlier post, that went into the ways in which people's views on aesthetics informed their decisions on how usable they thought products were.

The question I asked myself was: have users intuitively made decisions (right or wrong) about an interactive product before they start to use it?

'Blink' suggests that these first impressions can be very long-lasting and difficult to overturn. So how could an experiment be devised to test whether your products can be made more or less usable purely by manipulating the blink?

Perhaps you could show users a one or two second snapshot of a site and ask them to rate it, and then go through a normal usability test and ask them to rate it again. Would there be any correlation between these two ratings? Could that correlation be explained another way?

Perhaps you could perform this exact same experiment again, but this time switch the sites that the real usability test is performed on, so that the site you see for the snapshot is not the site that you do the test on. If there was still a correlation between the two ratings.....

I don't know. Maybe there's a much better experiment than this that could be devised (and, better, actually perform). But even as an idea to lodge in your mind, the idea that the first few moments of a users interaction could be fundamental to the rest of their experience is an interesting one.

Failing to meet your users' expectations – a case study

Oh, dear. Updated at least once per week, it says in the header, and there's been no update for nearly a month. My only excuse, really, is that I don't think I have any users yet..;-)

I've started a further education course recently (and yes, I was thinking of using that as an excuse too). The course is an Open University course on Interaction Design, which I'm taking to formalise some of the experience I have, to broaden my theoretical knowledge, and hopefully learn some practical things I can use day-to-day too. It's based around the book "Interaction Design - beyond human-computer interaction", by Preece, Rogers, and Sharp (there's a good website accompanying this book at www.id-book.com).

One thing that was mentioned pretty briefly, and that really caught my interest, was in the section about why its important to involve users. Why is it important to involve users? The reason that probably jumps to your mind – and the one that jumped to mine – is that only by involving users do you really understand what they want and need, and how they think. However, two other reasons are introduced in the book:

• expectation management
• ownership

In short, the first of these is that by involving users they understand what it is they're going to get, and aren't disappointed by high expectations that aren't met. By involving them, they also gain an idea of what they can and can't do with the product before it actually goes live. This is linked to ownership: by feeling that they have been listened to and involved in the development, your users are more likely to feel that it's not something foisted upon them, but something they can be actively proud of. Note the interesting correlation, by the way, to the discussion on the change curve.

So (if I actually had any users) I would have done a poor job at this. I say that there will be an update every week, and then there is isn't. If I'd said there would be an update every month, would my users be delighted now? They'd probably be happier than they are religously searching for their nugget of wisdom once a week and finding nothing. So Jakob's advice (point seven) on telling people how often you'll be posting only really works if you keep it up.

I very much hope normal service will be resumed . . and I'm sure you all do to.

Do web demos help people use interfaces?

Someone suggested to me recently that we should ship web demos with our products, as part of the user assistance offering. Since then, I've been trying to find evidence either for or against using web demos to help people understand interfaces, and I've come up with absolutely nothing.

There seem to be a couple of ways that web demos are used:

• to show a product to potential customers, particularly if the product is not yet available. Madcap Flare and AuthorIT are a couple I've recently watched.
• in an e-learning context

My gut reaction is that web demos are not likely to be particularly useful for providing interface and system assistance. We know that e-learning is a very different usability challenge from task-based interfaces (I saw this convincing presentation (pdf), by Florence Dujardin, on this subject at the Tekom conference last autumn), and while marketing people might think it's a great idea to ship marketing information with the product, users generally disagree.

We also know that users generally try and discover how things work by experimenting in the interface, and then resort to other sources of information when they get stuck. This implies we should (a) have more self-revealing interfaces, and (b) provide contextual assistance at the point of use.

When they do try and access assistance, they generally have very low tolerance for contextual information – they want to jump straight to their answer, and frequently scan text rather than reading it. This implies that we need to concentrate on providing and highlighting answers to common questions.

So how do web demos fit into this? It seems to me that people need to make a (relatively) big investment in learning about your interface to find them useful. Most people don't care about your interface – they care about getting this report done so they can go home, or getting the answer they need to impress their boss. Maybe in some marginal cases, they want to sit down and be guided through a demonstration/illustration of some complex tasks, but I'm not convinced it's a very compelling need.

What I would love is to find some real facts on this, rather than what I have now – mildly informed opinion. If anyone could point me in the right direction, I'd appreciate it.

Presentations are not reading material

The PowerPoint presentation is an endemic part of corporate culture in the Western (and, as far as I know, Eastern) world.

I probably see ten presentations a week, and if you're like me, you'll see about the same. Oddly enough, of those presentations, I probably see the speaker about twice. And of those speakers I do see, I remember nothing of what they said.

So, you say, we've all got problems. What does this have to do with user experience, with interaction design, with information architecture? Because it's a great example of how easy it is to get into a rut of:

• using the same technological solution over and over again
• trying to make one interface fit two (or more) purposes
• not adjusting structure and layout to address your audience
• always using bullet points (I'm kidding here...)

Presentations are often misused as reference material for people who couldn't attend a meeting, or as something to look back on afterwards. This is not what a presentation is for. A presentation is for you to clearly communicate something, in person, to people who are watching you speak.

Reference material for people who couldn't attend a meeting (this is the other eight presentations I see each week) should be proper reference material – a textual summary of the points perhaps, and a paragraph on the general principle or suggestion. The number of presentations I read and think, "This is great reference material" is precisely none.

For people who can attend the meeting, don't give them half-baked reference material. We've all seen these slides a million times – bullet point, bullet point, nested bullet point, bullet point. Do you have a great experience with these presentations? Do you listen to what the speaker actually says, or do you attempt to read the slide?

And why are we using PowerPoint? Not that there's anything wrong with PowerPoint, but has the presenter thought about whether this is the best way to get her message across, or has she just fallen back on a technological solution she knows?

This is why it's relevant to user experience. Most presenters haven't considered their audience: what their audience want to get out of it; what information they want their audience to access. They've provided one PowerPoint interface to fit two completely different needs, and neither of their user groups is going to be happy. They haven't considered all the methods that might be available to help them communicate most effectively, but have instead implemented a technical solution they know they can deliver.

PowerPoint presentations needn't be bad, but because the audience (aka user) is disregarded, and the presenter (aka designer/developer) doesn't have clear vision, they mostly are.

A mini-book PDF on Really Bad PowerPoint, by Seth Godin

An excellent post on Garr Reynolds' Presentation Zen blog, comparing recent presentations by Steve Jobs and Bill Gates

Something we should all do more often

Vista Help – Can Microsoft see the future?

Microsoft are providing a new sort of Help for Vista. Not just for Windows (a la MS Help 2, the current Help engine for Microsoft programs) but for everybody (a la HTML Help 1.x, the current Help engine for most others).

Now, unlike HTML Help, and WinHelp before it, Vista Help will allow application developers to integrate their help with that of Windows, Microsoft programs, and indeed every other application on the PC. All of the help for the system will be accessed through a single (undockable) pane, at the right of the screen. "Allow" might not be the right word here: "force" might be better.

Vista Help will be based on MAML (Microsoft Assistance Markup Language), an XML-based language that uses pre-defined schemas to describe various types of content – FAQ, concept, glossary, and so on – and that will separate content from presentation, to allow consistency across applications.

It will also provide support for active content: the help system will be able to communicate with the PC and provide help that's relevant to your system state (do you have a printer connected? are you a local administrator?).

Additionally, it has built-in support for partial and pushed updates, so you can get some updated user assistance without needing to replace your whole help system, and as a user you don't need to know anything about it.

So is Microsoft's vision right here? They say that they have worked intensively with the Help-authoring community to provide what authors want, and I have no reason to disbelieve them. From speaking to other authors over the past few months though, I'm not sure that they've come up with answer.

• Do users want all their help (for Word, PhotoShop, Norton AntiVirus, Freeware text editor, ADSL modem, etc ...) to be in one single pane? Will this make it easier for them to find what they want?
• As an information developer, is it desirable to target content at MAML if you ever want to use the content for anything else? Is there a need for a proprietary format here?
• Are Microsoft really capable of mapping every possible document format in their schemas? Can developers and authors not be trusted to understand the structure of their information better than Microsoft?
• Are the new features (active content, and so on) compelling enough to encourage developers to switch to Vista Help?

The way I've phrased this is all quite negative, but the truth is that I don't know. I'm dubious about whether lumping all the help together – without allowing individual software development teams to decide if that is desirable or not – is going to do more good than harm. I'm unconvinced on the benefits of MAML, of the restricted schemas, and of the USP of Vista Help, but as nobody has seen it yet (and MS are keeping pretty schtum) it's really too early to comment.

The rigid structure that seems to underlie Vista Help does concern me though – there's a lot of "Microsoft decides", which experience tells me is likely to cause difficulty and frustration sooner rather than later.

I guess the biggest disappointment is that this was an opportunity to do something really great and push the whole sphere of user assistance onto another plane, and it doesn't seem to have been taken. In my view, user assistance should be moving ever more in the direction of providing guidance at the point of need, through dynamic embedded help, and I don't see how Vista Help fits into this picture.

I've heard people be negative about Vista Help, and I've heard them be guarded. I haven't heard anyone be enthusiastic yet. I'd love to know what people think, hope, and fear.

It's surprisingly hard to find information on Vista Help, but here are some links I know of – if you know of more, I'd like to hear about those too.

An introduction to 'Longhorn' Help, by Tony Self
Microsoft's introduction to Vista Help (still called Longhorn here)
Microsoft Assistance Platform blog
A post on the CherryLeaf blog, with a brief description of Vista Help, and a screenshot

Do you want to do something? Concentrating on users' goals

I've heard and seen a couple of things over the past few weeks about visual design. About visual design being more important to experience than usability.

The first thing was a fascinating talk I attended at a meeting of UPA North at Manchester University back in November. The talk was given by Alistair Sutcliffe, leader of the HCI group at the university. The talk explained how a number of studies had been done to try and understand how people's reactions to visual design (use of colour, design elements, interactivity, and so on) affect their perceptions of the interfaces.

The studies covered a number of different types of interface – airline websites, teaching sites, university sites. The goals differed from site to site – book a ticket, learn about the planets, choose a school for an internship or a PhD.

The overall conclusion from all this (or at least how I took it, Prof. Sutcliffe would no doubt put it more accurately than I do) is that visual design can be a crucial differentiator between sites. In fact, the more usable sites, (by measuring errors, success in achieving goals, time taken) were perceived as less usable by the participants if their visual design was not as striking or unusual, or if they were less interactive.

(Caveats: Prof. Sutcliffe made it clear that there was more work to do in this area, and that some of the results may have been affected by the young demographic of his test participants. I in no way wish to misrepresent him. While you can quote me, don't quote him from what I've said above - I'm sure if you contact him he'll be happy to set me straight!)

The second thing was an article from November 2004 that I've only just seen. The article is called "The End of Usability Culture", by Dirk Knemeyer. It argues that a focus on usability – in a Jacob Nielsen kind of way – has made the web boring, lacking in creativity, and monochrome. Dirk wants exciting new designers to (cough) push the envelope. The example he gives in his article is bank websites: from a distance, they all look exactly the same.

Now, I think Prof. Sutcliffe's research is really interesting, and it got me thinking: thinking about how good, strong visual design could make a real difference to people's experience of interfaces. I enjoyed Dirk Knemeyer's article too, and I agree that designers should be bold enough to do what they think is right, not just design to "1001 rules for a home page". But I think in both cases there's a fundamental distinction:

• Does the user want to get something done, or are they here for fun?

Coz if they're here for fun, let's give them challenging design, let's give them interactivity, let's give them ways of customising their space and linking with other users. Let's give them mechanisms to explore to random places, controls that they can play with and be delighted by, animations and metaphors.

If they're here to pay their electricity bill, make it boring and plain and standard. Let them do what they want to do quickly, so they can go somewhere else to have fun. Let them not get any errors, let buttons do what they expect them to do, let them not have noticed one thing about the design the whole time they were there.

I'd love to see the test on airline websites done again. I'd like to see the users set the task of really buying ticket, all the way through to payment and arranging ticket delivery. I'd like them to do this boring task once a week for a couple of months. Then I'd like them to be asked – if you had to book an airline ticket every week for the rest of your life, which site would you use? I'll bet a hundred two pounds that they'll have got over the visual design by then, and will take the reliable, error-free, 'usable' website every time.

I'm definitely not saying that we should try to make things that are visually, aesthetically, unpleasant, but I am saying that we should focus our efforts on helping people achieve their goals, whatever those goals might be.

Quite a long, and very interesting, essay by Don Norman on how attractive things work better (which, to be clear, I'm only partly in agreement with).