Three laws of usability

1. Don’t make me think!
2. It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.
3. Get rid of half the words on each page, then get rid of half of what’s left.

Home page design

There’s some good advice about homepage design. Eliminate happy talk. All that text that says “Welcome to our site, blah blah” is just a waste of everybody’s time.

A home page must have:

• A tagline. This is a clear, informative, personable and lively 6-8 word value proposition, conveying differentiation and a clear benefit.
• A welcome blurb. This is a prominent, terse description of the site, using as much space as necessary, but no more.
• Start places: Search, Browse, Highlights.

The home page is the first thing a lot of users will see, so test it to ensure visitors “get” it!

Testing

Do usability testing one morning a month. Test three or four users, then debrief over lunch the same day. After lunch, the team will have decided what to fix. No reports, no meetings.

Focus ruthlessly on the 3-5 most important problems. Do the least you can do to fix each problem: tweak, don’t redesign. Also do trivial 15-minute single-person fixes.

That last tip was taken from an interesting (and short) slide show by Steve Krug called “What I’ve Learned in the 21st Century“. And it contains some bonus advice for all you frequent flyers.

Again, everyone involved in web design and development should read this. So here’s a call to action for you. Don’t think about it: buy this book.

• Confirm: Require the user to confirm the action before doing it
• Undo: Do the action immediately, but allow the user to undo it

The Confirm strategy offers the worst of both worlds. It slows down people who actually want to delete, and it fails to protect those who don’t. In contrast, the Undo strategy offers minimum impediment to purposeful users while making it easy to avoid losing work.

To be concrete, let’s talk about specific implementations. One Confirm approach is to display a modal alert box saying “Are you sure?” with Delete and Cancel buttons. Another approach simply turns the Delete button into a Confirm button, requiring a second click to carry out the deletion. The Undo approach typically carries out the deletion, but displays an Undo button or link somewhere (perhaps next to the Delete button), which undoes the action when clicked.

Now let’s compare the approaches. There are two cases: either somebody clicked the Delete button on purpose, or else by accident. If the person clicked the Delete button on purpose, the Confirm strategy forces the person to carry out another action to confirm the action. Clearly, this gets in the way. The Undo strategy, on the other hand, simply offers an extra option after the action has occurred. The person can simply ignore this option.

If the person clicked Delete by accident, then the Confirm approach will not delete yet; instead it displays a new button that will immediately carry out the action. But the user has just taken the positive action of clicking a button. His finger is still on the button and he’s in a clicking mood. If a new button appears, there’s every chance he will click it. Warning messages (“Are you sure you want to delete?”) may not help — people often don’t read them.

“I want to save this work.”
Delete *click*
Are you sure blah blah blah? *click*
…
“Oh no!”

The point here is that since the initial action was a mistake, there’s no point in getting the user to confirm with the same kind of action. If I click a button by accident, don’t show me another button, otherwise I’ll just click that by accident too. The Undo technique does not have this problem. With Undo, once I have made the mistake there’s nothing more I can do to make it worse; but if I realise my mistake then I can easily take action to correct it.

This is a useful application of the old quote “It’s easier to ask forgiveness than permission.” Don’t waste time upfront making sure that the user is on the right path. Maximum usability is achieved by smoothing the path while allowing the user to backtrack if necessary.

Here is a summary of some points that I found particularly helpful. This gives the flavour of the book and serves as a reminder for me at least. For all the background information, you’ll need to read the book itself.

Question types

Question in forms may require four types of answer:

• Slot-in – no-brainers like name or phone number
• Gathered – things the user will be have to look up, such as credit card number
• Third party – things the user has to go to a third party for, such as the address of somebody you’re sending a delivery to
• Created – things the user has to think up on the spot, such as a username or a free-text field

Questions may also have the following qualities:

• Anticipated – questions that the user expects, such as credit card number when buying online
• Intrusive – questions that users may not want to answer, such as phone number

Form design guidelines

Ask the “easy” questions first to lead users gently into a form. Easy questions are those that require minimal consideration — they are slot-in, anticipated and non-intrusive.

Make form field labels clear and descriptive. People read labels on forms, but they tend to ignore headings and other text.

Put labels to the left of input fields. If all questions are “easy” then you can right-align form labels. Otherwise left-align. Don’t put labels above fields – this makes it hard to scan labels and fields, and easy to accidentally skip fields.

Keep labels close to fields. Sometimes forms have the labels on the left and the input fields way over on the right. Don’t let your layouts be too liquid.

Lay out form elements with a grid. The grid lines are not visible, but they help to align form elements consistently. It’s disconcerting to see page elements almost lining up. They should either line up perfectly or not at all.

Don’t make your forms too dynamic. It’s disconcerting to have forms field appearing and disappearing all over the place.

Validate user input gently. Say “Please enter the date” rather than “Error: invalid date format”. Display a list of errors at the top of the page, each linked to the actual field (this makes it easy for screen reader users etc.)

When the user has completed the form, display an acknowledgement or thank you message to end on a high note.

Forms that Work is a companion volume to Ginny Redish’s Letting Go of the Words. Read them both, put their ideas into practice, and your users will thank you for it. (Actually they probably won’t. But perhaps they should.)

I learned a lot from the sections on writing for international users, specifically for users who aren’t proficient at reading English. Short, active sentences without complicated words. It has helped me respond usefully to comments on this website, which has readers from all over the world.

Of course, you can’t possibly summarise an entire book with a list of bullet points, but here are the ideas in the book that struck me as being especially useful.

• Write information, not documents.
• Don’t make people think. (Thanks, Steve Krug.)
• Remember that some people will print out pages.
• Cut! Cut! Cut! And cut again! It’s been said for a long time by many writers that people don’t read on the web. The less you write, the more likely you’ll be read.
• Keep active space in your content. Active space is white space that separates content, as opposed to the passive space in page margins and so on.

I have only one quibble with this book. There are a lot of little talking head cartoons, meant to represent web users saying things like, “How do I check my order on your site?” To me, these are so badly drawn that they are intensely annoying: the brunette woman’s lips make her look as if she has a moustache; the man with the cap looks like a bearded woman; the bald man looks like a bald woman with a moustache.

But enough nitpicking. There’s a heap of useful information in this book. Definitely worth keeping and referring to again and again.

If an error is possible. someone will make it. The designer must assume that all possible errors will occur and design so as to minimize the chance of the error in the first place, or its effects once it gets made. Errors should be easy to detect, they should have minimal consequences, and, if possible. their effects should be reversible.

He elaborates later in the book:

Design for Error
Assume that any error that can be made will be made. Plan for it. Think of each action by the user as an attempt to step in the right direction; an error is simply an action that is incompletely or improperly specified. Think of the action as part of a natural, constructive dialog between user and system. Try to support, not fight, the user’s responses. Allow the user to recover from errors, to know what was done and what happened, and to reverse any unwanted outcome. Make it easy to reverese operations; make it hard to do irreversible actions. Design explorable systems. Exploit forcing functions.

Norman’s website has a lot of good reading too. His page In Praise of Good Design describes a nice goal to aim for in your web applications:

Eliminate error messages from your system. Always turn an error into an opportunity to help.

I really like the idea of treating an error as part of a natural dialog, a result of the user exploring the system. This makes it much easier to write helpful error messages. But more than this, I think this attitude will help you design more usable applications.

I don’t think that viewing your visitors as monkeys is a good idea. But still there are some interesting points and mini-case studies in this book. Every point is two pages: one page for a screenshot, and one page (often more like half a page) for a bit of text. In many cases the text could have fitted on the same page as the screenshot, even more so if edited a bit.

Perhaps the best thing about the book is one piece of advice he gives several times: different variations on “Don’t take my word for it. Test it.”

And you might be wondering about the name of the book. Well, you’re supposed to imagine that the monkey is wearing a big red fez. Why? Does that help? It it relevant? Not really. It makes me wonder whether he came up with the title first and then had to stretch to tack a book onto it. Fortunately, the book is actually worth reading. But only once.

Individual fields

Form label alignment

• For reduced completion times & familiar data input: top aligned
• When vertical screen space is a constraint: right aligned
• For unfamiliar, or advanced data entry: left aligned

Field lengths

• When possible, use field length as an affordance
• Otherwise consider a consistent length that provides enough room for inputs

Validation

• Employ flexible data entry
• Use inline validation for inputs that have potentially high error rates
• Use suggested inputs to disambiguate
• Communicate limits
• Avoid changing inputs provided by users

Help & Tips

• Minimise the amount of help & tips required to fill out a form
• Help that is visible and adjacent to a data request is most useful
• When lots of unfamiliar data is being requested, consider using a dynamic help system

Field groups

Layout

• Use the minimum amount of visual elements necessary to communicate useful relationships
• Consider tabbing expectations when laying out forms

Selection Dependent Inputs

• Maintain clear relationship between initial selection options
• Clearly associate additional inputs with their trigger

Actions

• Avoid secondary actions if possible
• Otherwise, ensure a clear visual distinction between primary & secondary actions
• Align primary actions with input fields for a clear path to completion

Form

Progress

• Illuminate a clear path to completion
• Map progressive disclosure to prioritized user needs
• Provide indication of tasks in progress
• Disable “submit” button after user clicks it to avoid duplicate submissions

Success

• Clearly communicate a data submission has been successful
• Provide feedback of data submitted

Errors

• Clearly communicate an error has occurred: top placement, visual contrast
• Provide actionable remedies to correct errors
• Associate responsible fields with primary error message
• “Double” the visual language where errors have occurred

T (01) 234 5678 – F (01) 234 5678 – E bob@boztangle.com

It looks quite nice and clean, especially in a vertical format on a screen as the single letters all line up in nice columns. And it’s pretty obvious what the letters stand for if they stick to the obvious words: telephone, fax, mobile, email. But too often people try to be clever and end up creating confusion. Here are some examples.

P (09) 876 5432

P is meant to stand for “phone”. This is a real howler; it reminds me of the Simpsons episode that mentioned a horror movie called “P is for Psycho”. P is obviously not a natural abbreviation of “phone” or “psycho” because these words don’t sound as if they begin with P. And “phone” is already an abbreviation. For telephone. Which begins with T.

D (02) 468 1357

D stands for “direct”. In this case, there’s probably a T that gives the number of the company reception desk. But wait a minute. This is Bob’s business card, so when I see a T, I expect it to be Bob’s phone number. His direct phone number. The number of the reception desk is a secondary number, and we must face the fact that there’s no clear single-letter abbreviation for this.

C (021) 468 1357

C stands, of course, for “cellphone”. That’s “of course” only if you live in the USA or some other country where mobile phones are called cellphones. I think that M for mobile is more universal than C for cell, as well as being more descriptive. I’ll bet that most people who call their phone a cellphone don’t know why it’s called this.

DDI (02) 468 1357

This stands for Direct Dial In. You also sometimes see DID for Direct Inward Dial. This is pretty common in New Zealand — it’s a quaint reminder of a simpler time, when most companies had only a few incoming phone numbers and having a direct line was a big deal; of course this concept required its own special abbreviation. Nowadays I think we can just stick with T for telephone.

So here’s a handy guide to the single-letter abbreviations you can safely use for your English-language contact details.

T Telephone — the person’s phone number. This is the direct number if there is one, otherwise the general reception number.

M Mobile — the person’s mobile phone number.

F Fax — the person’s fax number. (Some people like to write “FAX” instead of “fax” for some reason, but I’m sure you’re not one of these people.)

E Email — the person’s email address.

W Web — typically the general company website. Of course you should leave off the http:// from the website. But then you knew that already.

Anything else is going to need more than just a single letter. For consistency in these cases, just spell everything out rather than have funky single-letter abbreviations for some details but not others.

Some of these contact details don’t really need any indicator at all: bob@boztangle.com is obviously an email address. Mobile phone numbers are often distinguishable by the number of digits, but this only works for people who are familiar with that country’s numbering plan. (Even then it doesn’t always work: Hong Kong has no area codes and uses eight digits for all phone numbers, fixed and mobile. Then again, in my experience nobody used fixed line phones in Hong Kong anyway.) Given that, if there’s only a fixed line or a mobile or both, and also maybe an email and a website, you can just give them unadorned:

(09) 234 5678 – ( 021) 234 5678 – bob@boztangle.com – www.boztangle.com

Now that’s clean and elegant. But more importantly, it’s clear. Adding “P” would just confuse the matter.

Unless otherwise indicated, all comments apply to Lotus Notes client version 6.5, though a lot of the comments apply to version 7.0 as well. Webmail comments apply to version 7.0.

Preferences: Looking for Preferences? There is a Preferences submenu under the File menu. It contains six menu items for different kinds of preferences (but none of them are to do with files). But there’s also another preferences command, in the Actions menu under the Tools submenu (note: not an action). So for example if you want to add a digital signature to all your sent mail, you set this in File/Preferences/User Preferences/Mail; but if you want to add a text signature, you go to Actions/Tools/Preferences/Mail/Signature. This is ridiculous.

New Folder: I wanted to create a new folder to file some emails. In the panel on the left hand of the window, there’s the standard Inbox, Drafts, Sent and so on, as well as a Folders icon that can be expanded to show all your folders. You’d think that the command to create a new folder would be obvious. You’d be wrong.

Right-click the Folders icon. Huh? I get a context menu with options like Italic and Underline, amongst others. (I select Italic just for fun. Nothing happens.) But no New Folder option.

Right-click the panel itself. Huh? I get a context menu with options like Document properties and even Forward. (Just for fun I select Forward — a new email appears containing a picture of the lefthand panel. It’s hard to overstate the uselessness of this.) But no New Folder option.

File/New from the menu bar. This gives me a few options: Memo, Calendar Entry, Contact, To Do, and URL. (URL?! I try selecting that. It turns out that it actually just lets me type in a URL rather than create a new one. And then it opens up the URL in Internet Explorer. Even though Firefox is my default browser.) But no New Folder option.

Create from the menu bar. Surely. But no: I can create a new Memo, Reply, To Do, etc. There’s a Special submenu that lets me send a message to the database manager. There’s also an Other… option. Surely here! But no, Other… actually just gives me a list of the same options in the rest of the Create menu. Brilliant — the Other option actually does not give me any other options at all! It’s utterly worthless and confusing and I really can’t be bothered trying to come up with words to express how monumentally stupid the whole thing is. And I still can’t create a new folder, even from the Create menu.

And now finally I discover the several ways to create a folder. I select the Inbox icon to show the Inbox view. There is a button bar above the actual Inbox view. It’s not a toolbar — there are already two toolbars below the menu bar. This button bar is just a row of buttons, except that some of them are really dropdown menus that look like buttons. Anyway, there is a Folder button (actually a menu) that has a Create Folder… option. I didn’t notice it before because it wasn’t there — I had the Trash displayed, and the Folder button/menu does not appear when the Trash is displayed.

With the Inbox showing, there’s also a Folder/Create Folder… item in the Actions menu. But I also notice that if I click the Inbox icon, the menu bar shows File, Edit, View, Create, Actions and Help. But if I click the word “Inbox” beside the icon, the View, Create and Actions menus disappear after a second. If I click it again, those three menus appear for a second and then disappear again. Oh dear.

Also, it turns out that I could right-click the Inbox icon — a New Folder… item is in the context menu. Note that the new folder does not appear in the Inbox. In fact it has nothing to do with the Inbox.

So finally I have created a new folder, which appears under the Folders icon. It appears that I can now right-click on my new folder to get a context menu that will let me create another folder. And now that there’s a folder under the Folders icon, right-clicking the Folders icon gives me a different context menu! It’s the left-hand panel context menu (with the nonsensical Forward option) rather that the old Folders icon context menu (with the nonsensical Italic option).

All this just for a folder. In the time it took me to do this I could have simply run the Lotus Notes uninstaller and ended up much happier.

Scrolling: I got a meeting invitation that contained several screenfuls of text, but there was no scrollbar. In fact I didn’t even discover the text until I printed it out and was surprised that it was 5 printed pages. Scrolling with arrow keys or scroll wheel didn’t work. I also couldn’t select any text. I tried going into edit mode, and that seemed to make things better, though the scroll wheel still didn’t work unless I actually selected some text. (!?)

Daylight Saving: This is from a Certain Company’s intranet from 31 March 2008. This is not a joke:

The end date of Daylight Saving Time in New Zealand has been extended for 1 week this year. We now revert back on Sunday 6th of April.

When browsing your calendar for the week starting Monday 31st of March, your meetings may appear to be 1 hour late, so please OPEN the calendar entries to view the correct start time.

Ugly: The Notes client has its mysteriously-changing “keychain” picture. The Web client has a big red stop sign on its login page. The stop sign has a fat, fleshy hand on it, just to hammer home the point that you have to stop. It looks like a scary error icon. Why is it even there at all? The only sensible interpretation I can think of is that it’s saying “Stop, the application you are about to log in to is hideously bloated and ugly.”

Meeting invitations: There’s no obvious way to accept a meeting invitation without sending a response. Even worse, select Respond with Comments; an email form appears. Change your mind and close the email form. You get an “are you sure?” dialog box, and since it’s Notes, you get several choices: Send as is, send without comments, or continue editing. That’s right, there is no way to cancel. You are forced to send the response. You can’t even quit from Notes now — if you try you will get the dialog box offering the same three choices. The only way to quit Notes without sending the response is to use the Windows Task Manager to kill the process. This is magnificently, fantastically stupid and is just another reason why the people who designed Notes should hang their heads in shame.

It turns out that even killing Notes won’t kill the meeting response form. When I started up Notes again, the form was there. Apparently that form will now be a permanent fixture of my Notes usage forever, until I finally give in and send it. Even though I don’t want to send it. Shame! Shame!

I noticed that a couple of days later, the form had finally gone. I can’t even remember if I restarted my PC or something like that, or if I finally gave up and sent the confounded thing. I have no more comment.

Webmail drafts: When you’re writing an email using the webmail interface, the Save button saves the email as a draft and then closes the window. So if you’re writing a long email and you want to save periodically, you have to keep pressing the button and then going back to the main window, opening the Drafts folder, opening your message and scrolling down to the bottom to continue. What a waste of time.

Spurious error: In webmail, if I create a new message and start editing it and then return to the main window and select a mail folder, a message pops up saying that they are sorry (which is nice) but “we were unable to process your request at this time.” (I don’t know who “we” refers to — the entire Lotus Notes development team, presumably). So I click OK to dismiss the dialog box and guess what? Everything works fine.

Well, I could go on. In fact I already have. It’s important to pick holes in Notes like this because otherwise we might get used to its warts. If we relax our standards for the software we use, it might flow on to affect the software we write. For this and for so many other reasons, Lotus Notes is rubbish.