Usability Notes - by Chris Baker

How long will users stay on your web page?

The received wisdom is that users don't hang around long on a web page, so you'd better get it to load quickly and then capture their attention immediately.

Some recent research by Liu et al, and discussed in an article by Jakob Nielsen, offers some more insight (and a big statistical study to back these up).  As you'd expect, users make a quick decision - in maybe 10 secs or less - and then move on or stay. The longer they stay, the more likely they are to stay some more: the probability of them leaving drops pretty exponentially.

Statistically, the pattern follows The Weibull Hazard Function, a concept from reliability engineering. The pattern follows a "negative aging distribution". You would get the same results by asking "how likely is a given component in a machine to fail" when the quality of the components is highly variable (so that, the longer this particular component has been reliable, the more likely that it is one of the good ones off the line and will keep functioning). If the manufacturer had better QA in this hardware example, then the componets would begin to follow a "positive aging function" instead - they are all as well made as each other, and so the probability of failure simply rises over time due to wear and tear.

 

Usability methods: user testing versus expert review

UXmatters have a well-argued discussion of the pros and cons of checking your design by user testing, as opposed to having an expert do a review.  These methods achieve different things. For example, suppose you have a design including green navigation tabs, with a red colour being used to show highlighting. A usability reviewer should immediately point out to you that this design is not usable to anyone who is red-green colourblind, which is a point you might miss if you tested with real users, and none of them happened to be colourblind. On the other hand, expert reviewers can suffer from their own biases about how things ought to be done.  The ideal is to do both - review the design from a usability point of view yourself (bringing in an expert if needed) and then try it on real customers. Real customers are the only way to get the authentic -  and sometimes unexpected - voice of the customer. Among the things real users can do for you is to help you explore whether you've designed workflows in the way that the users (or most of them) expect.

Thanks to @IATV, whose tweet alerted me to this UXmatters article.

Search Engine Optimization when you use Flash

Google is able to index Flash pages...somewhat. But some special thought needs to go into getting search engines to understand what any flash content is about. Gravity Search Marketing have a good site "Your SEO Plan" . It has a lot of useful stuff, including advice about Flash. Here's an excerpt :

"Flash Best Practices for SEO

To help search engines see and properly list your website contents in their search results, we recommended the following best practices for Flash SEO:

• Use Flash only when necessary, and consider wrapping decorative flash elements in HTML navigation if possible. Pages should degrade gracefully for users who do not have javascript or Flash.
• Build separate HTML landing pages (with distinct URLs) for your separate Flash landing "pages." Each separate HTML page should deep link to the appropriate part of your Flash movie.
• Embed your Flash using SWFobject so that you can display alternate HTML content. Make sure that the text content in the alternate HTML is as identical as possible to the Flash content. Graphic elements can be described, just as you would describe a photo with a caption or an image ALT tag.
• If you generate your Flash content from an external XML file, use the same XML file to generate the alternate HTML content.

Essentially, for an all-Flash site, you should create "shadow" HTML pages, which display deep-linked Flash for humans, and mimic the Flash experience and content for search engines. These pages can serve as entry points from search engines."

[from Does Google Index Flash?]

Remote usability testing with Glance

One common barrier to conducting usability tests is that you may have to travel to see recruits, or ask them to travel to see you. I have recently been using a system called Glance to allow recruits to test from their own computer, and have found it very workable.

I did once do a project where I usability tested on teenagers. We did not have any special requirements other than that the recruits were about 16 years old, and so it was not much work to find recruits locally. These teenagers could be pretty flexible about their availability, and the incentives we could offer probably stacked up well compared with filling supermarket shelves, babysitting, delivering newspapers or other teenage ways of earning a bit of money.  

That's the only time I have found it easy to recruit usability testers. More typically I need to recruit teachers, doctors, academics or other professionals. All of the factors that made it easy with teenagers are thrown into reverse - it may be difficult to find anyone local; their diaries are full and cash or a present is more likely to be a token of thanks than serious earning from their point of view. A further factor in the testing I have recently done is that the system was not yet available on a web-server - recruits would have to have access within the firewall. Ideally we wanted to include some recruits from overseas. Difficult.

So recently, I tried a screen-sharing software called Glance in order to conduct tests. Setting up an account is easy and quick, and although there is software to install on the computer test machine, this is quick to do and does not require admin rights. When a Glance session is started, you get a 4-digit code. Add that as a parameter to an URL that you are given, and you have what your recruit needs to type into their browser to see your test machine. The recruit does not have to install anything (Glance uses an ActiveX control on he recruit's computer by preference, but if unable to do that, Glance uses a Java applet: more info at Glance's technology page). From a menu on the test machine, you can switch between letting the recruit control the screen (e.g. with mouse clicks and typing) and them watching while you do it.

The actual test consisted of the recruit working through a list of tasks, using the remote screen and talking to us over the telephone. It went pretty well. There is some latency - a small delay between the remote user moving the mouse, the cursor moving on the test machine and the recruit seeing this movement on their remote machine.  We were testing a  site that was operated by clicks on links and buttons, some pull-down menus and some typing. Our recruits found the latency noticeable but bearable. It did not seem to interfere with the tests, and nor did it seem too onerous when we tried remote access ourselves during a rehearsal ahead of the first test. My guess is that it might have been very difficult to run tests of a media-rich site, or one with lots of animations and fiddly mouse-over menus.

Glance puts a red or yellow border around the screen on the test machine to show that it might be viewable remotely - obvioulsy it is important to make sure the Glance session has been finished before using the test machine to write up notes, do email, or do anything else that your recruits don't want to see!

All in all, the sensation was like holding a conference call rather than a face-to-face meeting: a face-to-face may still be a richer experience, but businesses have long accepted the trade-off of holding conference calls instead in order to  get the work done faster. We thought it was probably an advantage that recruits could sit at their own computer. Also, all the interaction had of course to be by phone, I thought that possibly this helped the recruits to keep on "thinking aloud". (It is familiar to see recruits lapse into silence and need to be prompted to tell the tester what they are trying to do).

More on Wireframes

Since composing my last post on wireframes I came across a couple of articles on the subject which reinforce the point of needing to keep wireframes simple - in terms of what they are for as well as how they look.

Sarah Harrison states the problem nicely:

"Standard wireframe documents look so much like a web page layout, we ask viewers to use immense amounts of imagination to divorce that which the wireframe is trying to communicate from what its visual representation is  communicating....he main problem with wireframes is when they try to do too much, serving multiple purposes at the same time. The key, in my opinion, is to decide what the essential purpose is for your wireframe documents. Different purposes might require a different format."

Sarah Harrison: Wireframes: Struggles and Solutions, Part 1

Dan Brown (who goes on to suggest one possible solution) has had this problem:

"The conflict arose after clients had seen the wireframes. The layout, even explicitly caveated, would set their expectations, and they did not appreciate screen designs that strayed too far from them, no matter how carefully crafted. Clients also struggled to talk about information priorities, taxonomies, and functionality. Placing these concepts in a layout made them more accessible, but our conversations were too tactical, and their feedback had more to do with design than with structure."

Dan Brown: Where the wireframes are Special Deliverable #3

To me, these interesting articles reinforce the need to think ahead about the process within which the wireframing sits  That should help to keep the wireframes as a quick, disposable tool to help with the next task in hand - I don't think the one wireframe can cover all the aspects of logic, layout, emphasis and so on without losing the quick-and-cheap benefits that wireframes ought to have.

Where's WCAG going?

Back in 1999, the Web Content Accessibility Guidelines 1.0 were published. These contain much useful advice for building web pages in such a way that they can probably be used by people with disabilities. Nineteen-ninety-nine is now long ago in web terms, and a new version has been a long time in coming. There has been a lot of consultation and opinions expressed, and if my own experience is a guide, it can be difficult to keep up with what is going on.

So I was pleased to find recently transcript and webcast of a talk by Shawn Henry from WCAG: Web Accessibility Guidelines Update, June 2007.  She covers  what WCAG have been doing and where they have got to (to a possible final draft of WCAG2.0 this spring and then back to working draft status when they got a lot of feedback) and a helpful overview of how WCAG2 will differ philosophically from WCAG1. Stuff I found difficult to glean from the current WCAG 2.0 working Draft

Shawn's talk was part of the excellent YUI Theater (Y stands for Yahoo!: it is part of the Yahoo! Developer Network.). Lots of good stuff there.

Bubbl.us

Bubbl.us is a useful online tool that lets you quickly draw many kinds of charts for brainstorming and other purposes.

A project manager colleague of mine was recently speculating that the best project management tool of all was a flip chart and some sticky notes - the sticky notes (eg. Post-It notes) are labelled and stuck onto the paper, moved around and argued over and there may or may not be various arrows and lines to connect them. It is a quick way of doing various kinds of diagram that are useful for brainstorming - e.g. what is in or out of scope, how a website ought to be organised, what main tasks are in a project, what the steps are in a process, or many other options. The disadvantage comes in trying to read people's scrawled notes later (" 'don't sell plastic clothes' - huh?" ). And, although one quickly learns to photocopy the flip chart at the first opportunity, there is something uniquely dismaying about the sticky notes blowing away like autumn leaves if you carry the chart through a draft, or when unroll it back at the office. Scrabbling around after the strayed notes, you are left wondering which important part of the project is at risk of being forgotten.

"Bubbl.us " offers a neat online alternative - you can type onto bubbles that you can link up in various ways and move about as you wish. If you have created an account (currently free, requires that you give an email address) you can save your resulting drawings, and share then with colleagues who also have accounts. Printing out is currently a bit basic, but workable (you can print ot paper, and  could always print out as a PDF to have a permanent electronic version).

I find I like it a lot:   beyond a certain point you might wish to be using Visio or SmartDraw to produce a more finished looking chart (e.g. with a choice of shapes and colours), but either of these charting tools are not nice to use in quick-fire circumstances where you need to get ideas down fast, and are sufficiently expensive that you will readily find colleagues who don't have them.

The usual caveats of using a free online service apply: firstly, you have of course published your drawing somewhere, and although access to it is by username and password, there may not be much redress if someone sees it who shouldn't. And secondly, there may be little recourse if the site, and your precious diagram are unavailble one day. So you may not want to put your top secret plans there, or documetns that you care about keeping. However, most of the diagrams I find myself drawing are so cryptic and temporary that these risks are acceptable.

[Note added 20 March]: If you want to make more complex charts, but want a free/cheap web-based tool rather than investing in Visio or SmartDraw, you may be interested in my review of Gliffy

Information scent, content inventories and card sorting

Unless your website is very small and simple, it is not practical or sensible to offer visitors a direct link to everything they may want to see. Instead, you need to offer them navigation that contains the right selection of broad categories, the idea being that visitors can choose the right category and move via a sequence of progressively more appropriate pages until they have tracked down the thing that they want.

To get visitors to go through several steps to get to the content they want, you are going to have to keep them re-assured that they are going the right way, and that there is a good chance of seeing the content they want soon. Hence the analogy of "information scent". The analogy is with animals using scent to find the right direction in which to go to find, say, a fruit to eat, or a flower to pollinate. (Or for that matter a prey species to catch, but I prefer the fruit/flower analogy since fruits and flowers, like websites, wish to attract visitors for a  mutually  beneficial exchange. Contrastingly, few prey want to be eaten, I expect.)  Provided that the scent is strong and getting stronger, the visitor may be willing to carry on a much longer trail than that  somewhat arbitrary 3 click-rule (Conversely, 3 clicks might be far too many if one of them is in a counter-intuitive direction).

Two good introductory articles about information scent are this Alertbox article about information foraging  and   this one, including some example of whiffy websites, from the KM column .  The learned paper that started it all was The Effect of Information Scent on Searching Information Visualizations of Large Tree Structures (Peter Pirolli, Stuart K. Card, and Mija M. Van Der Wege).  Alertbox also has a column about the consequences of getting it wrong - customers giving up when the scent leads to a dead end.

How then to get your navigation right? A recent article from boxes and arrows "Content Analysis Heuristics by Fred Leise" has some good ideas for dividing the content of your existing or  planned website into  suitable divisions. Another popular approach is to do a card sorting exercise. To do this, you recruit some people who seem as likely as not to be typical of your users. You have prepared a pile of cards, each of which you have labeled with the name of a bit of content that needs to go on your website somewhere. Your volunteers are to sort the cards to show how they think the information ought to be organized, and you discuss with them why they sorted the cards in the way they did. The outcome you want from this is to see the different ways in which visitors would expect the site to be organized. Because you want to see a good slice of the variety of thought processes out there, you need to test on a biggish group of people if you can - Jakob Nielsen recommends card sorting on 15 users.

Some good general references about card sorting include this guide from steptwo, and this one from boxes and arrows.

It doesn't literally have to be cards, of course - once I was planning a website for a recruitment business. We had the problem of how to organize the jobs so that visitors would find the right categories. I planned to cut out a load of classified ads from the business' printed publication and have volunteers sort those. Unfortunately the project was canceled, so I never did actually go ahead with this.

Free usability advice

"Free usability advice" is an unusual offer from this blog by Expero Inc. They publish a weekly question someone has sent them, with their suggested answer. I liked their pragmatic approach to the "3-click rule" (i.e. the idea that every page on a site should be reachable in 3 clicks). They suggest that 3 clicks is a bit meaningless (and impractical if you have a big site); what matters is, can users get where they want to go?

"Making pages accessible within 3 clicks has no inherent value as a metric to the users of a site or to your business goals. What might matter, though, is efficiency (how quickly users can complete their tasks) or how easily users can find what they need. Do users have to call tech support or use other resources that cost the company money to find the information they need?

In a wonderful paper called Designing for the Scent of Information, User Interface Engineering notes that what users do expect is that every click makes them more confident they’re on the right trail to get to the information they need. As long as users are confident they’re heading in the right direction, then they are not likely to abandon the site if it takes a click or two more to get where they’re going."

(from The 3-click rule)

Sounds sensible to me.

Checklists

Usability and Accessibility are areas where there are many checklists - for example , this nice usability checklist from the "Not Usable" website.

These checklists certainly can be helpful in avoiding basic mistakes. They remind me of the style guides that most print publishers have. For those who have not worked in print publishing a style guide is a set of rules for a publication; does it use British or American English (honor, color; or honour, colour?); how does it abbreviate (U.S.A or  USA?); how does it spell words that have several proper spellings (Czar or Tzar; -ise or -ize? ). How does it hyphenate (website or web site or web-site? ) and so on. The style guide often also sets rules about grammar and text structure, overall tone and, er, style. For example, see The Economist newspaper's style guide or the  Guardian newspaper's style guide.  What happens (in every publisher I have known) is that language can only be formulated so far - the style guide needs constant updating, and even so, editors are expected to make their own judgment sometimes when the style guide runs into conflict with natural English. This was nicely put by George Orwell in his "six elementary rules" ("Politics and the English Language", 1946):

"Break any of these rules sooner than say anything outright barbarous."

Similarly, I think checklists are best used as a basis to get things right rather than a dogmatic authority. In most sets of guidelines, there are probably few decent reasons not to follow  the guidelines  - e.g. "check that all the links work". ("I forgot" not being a good reason!). In SOME other places, it might be OK to override the guideline for another reason to do with the circumstances of your own site. In these cases, the guidelines are useful to make you think "do I have a really good case for over-riding this guideline?" - you CAN of course always user test this to see if you made the right decision.

Of course, it is not always that simple - some sites are required to conform to all of a set of guidelines, perhaps because of policies of the organization, or to be eligible for an award you want.  And then you may have to discard some nice design ideas so as to follow the policy (it should not prevent you having a good design, though maybe not the one you wanted at first).