What our customers say
I'm impressed with Key Minder... I've been looking for something exactly like this
Usability on the web
In the early days of the web, browsing pages was relatively simple. Links were obvious because they were underlined. Links you had already visited were displayed in red (a pretty poor pun on "read"). Graphic buttons, rollover buttons, Flash-generated drop-down menus and dynamic HTML were but twinkles in their designer's eye. Even then, though, the usability rules of the web were not that straightforward. In this article we will be discussing some of the design decisions that the architects of the web made and the impact those decisions have had on the usability of the modern world-wide web.
What can I click? And what happens when I do?
As long as the computer mouse has been around, the issue of what you do with it has been problematic. For file system navigation, the generally-accepted behaviour became a single click to select a folder or file and a double click to invoke the action for the object (opening the folder or file). Of course, there was also the question of how many buttons the mouse should have (one on a Mac, two on early PCs, three under X-Windows on Unix boxes, and many variations on each of these) and what they do. Despite a proliferation of uses of extra buttons, the basic behaviour of a single click to invoke a command button or to select an object, with a double-click to open an object, became more or less standard.
That fairly comfortable accommodation held for many years, during the development of the Windows and Mac operating systems for PCs and the various Unix windowing systems. It all changed with the appearance of the first web browsers and the introduction of the link. A link on a web page may be presented as a piece of highlighted text, or a button like traditional desktop program buttons, or a picture. And this is where the usability problem comes in. In traditional programs - say, for example, the Windows Explorer - things that look like buttons need to be clicked just once to produce the action they are designed for, whereas non-button items such as folder and file icons need to be double-clicked. A single click on a non-button item just selects it (the reason for this is that the item has both properties and a function, so it needs at least two modes of interaction with the user - one to select it in case the user is interested in inspecting the properties, and the other to open it). So where does that leave the HTML link? Is it like a button - something that you click once to enact it? Or is it more like a container object such as a folder, opening the way to another page? Or is it more like a file object, which contains data that is revealed when an associated program is opened with the file object as a parameter?
The truth is that a link on a web page has elements of all of these behaviours, and others besides. A link is actually a much more complicated structure than it appears to be, as it is really the initiator of a message that is to be sent to a web server. That message may load another page, or a graphic, or it may download or upload a file, or it may start off a separate program.
Unfortunately for the user, the HTML link is a bit of a blunt instrument - there is only one link, though it may be dressed up as a button or a picture. As a result the user doesn't really know how to interact with a link, which is why you often see novice web users double-clicking on links. Nowadays, the use of Cascading Style Sheets or CSS, while bringing major improvements to web design, also allows the designer to remove any decoration from link text if they really don't want any! Yes - you can actually completely hide any visual indication of a link, so that your user has to mouse around looking for the cursor to change to a "pointing finger" to find the links on a page. I know - why would you want to do that? Well, on some art sites it is deemed to be important to control presentation of type, and the use of the standard underline for a link is undoubtedly a little ugly. On the same theme, having some text in a different colour, either permanently or as a result of a previous visit, may detract from the site owner's vision. Of course, this may then be pushing at the boundaries of what a web site should be trying to do - making a web page work as though it were something else - an art-house magazine for example.
So what should the web designer do?
I tend to go back to the foundation stones of usability:
- Design against your site's purpose and your user's needs. Be clear about why your site exists and what you are trying to say on it. Understand your intended audience. Design your site around their needs and ensure that your navigation mechanisms are attuned to them.
- Be consistent. If you decide that text links will be shown in dark blue and visited links in green, then make sure that you always do it this way. If you use graphic buttons, design them the same way.
- Don't make assumptions about your user's knowledge of your system. You are the world expert on your site's design, its navigation, its layout. Your user will not know these things when she visits your site. She may approach the site with a very different mental model from the one you have used, and so you need to make the design, layout, navigation and so on absolutely unambiguous.
- Don't surprise your user. A common problem on modern sites is what happens when a user makes a selection from a drop-down list box. On simple HTML sites changing a selection on such a drop-down list box doesn't in itself cause a change on the page (apart from the selection itself, obviously!). The user needs to click on a button to submit a form in order to invoke any change. However, in a growing number of sites JavaScript or DHTML is used to detect a change in selection and do something in response. The latter behaviour is more like what you would see in traditional desktop software. However it may not be what the user is expecting if he is more used to HTML sites than desktop software, in which case he gets a surprise when a new page loads. Another common problem is clicking a link only to find that you are downloading a large file to your disk. In this latter case there is really no excuse - why not put a note after the link saying something like "Downloads the zip file - 2.5 MB"? The main thing is that your user should know what to expect when they do something on your pages.
- Do usability testing on your site. Very few designers or developers do this. Running a few sessions where you just let people use your site, unprompted but observed, can add enormous value to your site. As the designer (the world expert on your site, remember) you may be so close to its design, so in tune with its vision, that you have missed the obvious flaws. Putting a naive user down in front of your site gives you insight into the experience of a new user (= customer, if you get it right) loading it up for the first time.
What does the Back button do?
The Back button was an early example of a misleading navigation mechanism. A simple mental model of this button would be to take the user back along the series of pages she had been looking at - retracing the history. However, the real function of the button was quite different. Look at the example here: the user starts at the home page, then goes into section A and looks at a couple of pages, then backs up to the home page using the Back button and goes into section B.
Having looked at a couple of pages in this section (the red arrows show all movement up to now: Home-A1-A2-A3-A2-A1-Home-B1-B2-B3), she hits the Back button again. Rather than retracing the steps the user has taken (the green arrows: B2-B1-Home-A1-A2-A3-A2-A1-Home), the Back button simply backs up to the home page (the blue arrows: B2-B1-Home). In fact the Back button only takes you back as far as the last place you got to using the back button. Since our user had used the Back button before to get to the home page the other pages she had visited before that were forgotten.
This behaviour has continued unchanged in all versions of browsers since, and still leads to confusion in the user. By the way, this is poor usability not because it is inconsistent - it is perfectly consistent once the user understands the rules by which it works - but because it is not what the user is expecting. When a piece of software works in an unpredicted fashion it introduces a barrier to usability, because the user has to adapt her mental model in order to work according to its rules.
Tellura usability services
At Tellura we believe that investing time and effort up front in usability will pay dividends later on in terms of user satisfaction. And satisfied users tell their friends, so you get more customers.
We have over a decade of experience of usability, ranging from design of documents for publication through desktop PC and Macintosh software through to modern web-based applications. Here's how we can help your project:
- Advice and consultancy on design of usable computer systems
- Training of developers in usability techniques
- Usability analysis and testing
Other web usability resources
Through this short list, of books and web resources, I'm not making any claims of comprehensive coverage. These are just the resources that I have found useful over the years in helping me to design effective information services. If there are obvious well-known books or sites missing, it may be because I have used them and didn't find them helpful. Or, more likely, I've just missed them! Feel free to let me know about further resources that you know about.
- The Design of Everyday Things by Don Norman (Pubished by Doubleday, 1990: ISBN 0-385-26774-8: Amazon entry). Don Norman's classic work was the catalyst for my interest in usability. From the first page of the book I recognised a kindred spirit: "I have talked with many people who can't use all the features of their washing machiens or cameras, who can't figure out how to work a sewing machine or a video cassette recorder, who habitually turn on the wrong stove burner". "That's me with computers!", I thought. Although I was already working as a computer professional, I continually had a problem with badly designed programs that were hard to learn and hard to use. Sadly, there was a kind of macho sensibility amongst computer professionals (still is, to some extent) that saw such difficulties as a natural differentiator between them and the masses, and that going through the pain was a kind of rite of passage for anyone aspiring to be one of them. Hogwash, I thought - it shouldn't have to be like this. But until I read this book I hadn't crystallised in my own mind what was wrong, and more importantly what needed to be done to improve things. Although there is very little computing in this book I believe it is essential reading for anyone who wants to understand how to build tools and services for people to use.
- Tog on Interface by Bruce Tognazzini (Published by Addison-Wesley, 1996: ISBN 0-201-60842-1: Amazon entry). "Tog" is one of the leading authorities on the human-user interface design of the Macintosh. This book is a collection of articles over several years in which he describes, with humour and insight, issues of computer software design that helped drive the development of the Mac OS and software standards. Designers now may look at this book and be amused at what were the contentious arguments of that time, but it is worth reflecting that these arguments have influenced not only the development of the Mac but also that of other computer systems. It is hard to overstate the impact that Apple design has had on the usability of all modern computing environments. If you want to get an idea of Tog's writing style, check out his Ask Tog web site. Trenchant views, strongly argued, and probably right most of the time!
- Don't make me think (a common sense approach to web usability) by Steve Krug (Published by New Riders, 2000: ISBN 0-7897-2310-7: Amazon entry). Steve Krug's book gives a plain English foundation to the discipline of usability, covering all of the essentials that a web professional needs to be aware of with no attempt to blind the reader with science or grandstand his own expertise. Very readable and well-designed - as you might hope.
- Web Pages That Suck by Vincent Flanders and Michael Willis (Published by Sybex, 1996: ISBN 0-7821-2187-X: Amazon entry). Teaching good design by lambasting bad design: that is the thesis here, and it works quite well. To be honest it would have been nice if there were more examples of teaching good design by showcasing good design - it would have leavened the mixture more. But that is not to say that this is not a good book. Reading this taught me the first thing to consider when designing a site: "Why are we building this site?". Amazingly, even today this is a question that some organisations never ask themselves - and in failing to ask the question, either build a site where none is needed or (almost as bad) build an inappropriate site for the audience they are trying to reach or the message they are trying to impart. In summary, this is a really enjoyable read mitigated only slightly by the overall approach of dishing out too many brickbats relative to too few bouquets. There is a companion web site that is well worth looking at.