Free Online HCI Course from Stanford University

Stanford University are offering a free online course in Human Computer Interaction starting in January 2012. I’m half way through their Machine Learning course and have been very impressed with what I’ve seen so far, so I’ve got high hopes for the HCI course. I’ve already signed up and am excited to see what I’ll learn. Hope some of you can find the time to join me: http://www.hci-class.org/

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in General | 1 Comment

Cognitive Load

In a nutshell, Cognitive Load is the amount of “Brain Power” required to understand something. This could be perception, problem solving or juggling things in memory.

There’s a well known rule that we are only able to process 7 plus or minus 2 pieces of information at a time – it’s the magic number 7. We can improve the usability of our products by taking this in to account and reducing the cognitive load for our users.

There are 3 kinds of Cognitive Load:

Intrinsic Cognitive Load

The Intrinsic Cognitive Load is the inherent complexity of the task in hand. Drawing a square is a lot easier than drawing a portrait. There is little we can do about the intrinsic cognitive load, some things are simply harder than others. However, we can manage it by chunking the information in to smaller problems so that each can be dealt with in turn before re-integrating the information back in to the whole.

Extraneous cognitive load

Extraneous Cognitive Load is the result of the way that the interface or information is presented and structured. As designers this is where we have the greatest impact. For any given task, a well designed and clear interface will have a lower extraneous cognitive load than a badly designed one. Obviously, we should not add to the complexity of the underlying problem by producing complicated interfaces!

Intrinsic and Extraneous load are additive – they combine to form the load of the task. A simple problem presented badly can have the same total cognitive load as a complex problem presented well.

Germane Cognitive Load

This is the “good load” and we want to maximise it. It’s the spare capacity to deal with the underlying information (the intrinsic load) – the capacity available to perform the mental work that leads to understanding. If a task has a high intrinsic load but a low extraneous load, then the Germane load will be high as the user is able to focus their available resources on understanding the problem. If the same task has a higher extraneous load then the Germane load decreases because the user is having to expend resources on dealing with the extraneous elements.

How to lower cognitive load

  • Minimise the “noise” in your interface by remove unnecessary visual elements. These increase the cognitive load as they need to be processed in order to determine their relevance.
  • Chunking – reduce number of things that a user has to worry about at once by breaking the task down in to chunks. For example a “Wizard” style interface can help reduce the amount a user has to focus on at any one time.
  • Consider having an “Expert Mode” for the more advanced settings
  • Ensure the information relevant to the task in hand is available (so the user doesn’t have to remember it) people are much better at recognising the thing they want than they are at remembering it!
  • The time it takes to make a decision increases with the number of choices available (Hicks Law), so try to reduce the number of choices (e.g. by writing opinionated software)
Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | 13 Comments

Case Study: Empty State

Earlier this week I wrote about Empty State. I wanted to follow this up with a case study on how this might work on an example.

Fotolio

I’m going to base this example around an imaginary website. I’ve called it Fotolio, it’s a portfolio site for photographers to upload their photos. Imaginative names aside, I want to stress the below isn’t really how I’d design this kind of site, it’s a forced example to help illustrate the point. However, it is fairly representative of 100s of web applications out there:

So, Fotolio has 2 features:

  • You can create albums to organise your photos
  • You can upload photos to albums. Photos must live in an album

That’s all it does (well there’s some user profile stuff too – but it’s completely imaginary so it can do what ever you want!)

So, let’s look at a mock-up of how it would look fully populated:

There’s albums, a list of photos – once a user has got to this point they will have a good grasp of how to use the software. By this time it will be obvious that they go to the manage albums tab to create a new album; it will be obvious that they then go to the upload pictures tab, select the album then start uploading.

This is the state that the developer and other internal people will likely have the software. There is already content in there, they have context. If you can see other content in context you can link things all up in your head – it’s pretty powerful stuff. Without this you are left guessing. So, how might this app look to a new user in its empty state?:

Here we’ve just got empty lists, the system is outputting something meaningful e.g. “You have 0 Albums” so that’s a good start, but where do we go from here? Is it obvious what to do next? Let’s use the process I outlined on Monday. What does the user need to do to start using the software:

  1. Create an album – this involves:
    1. Switch to the Manage Albums Tab
    2. Click the New Album Button
    3. Complete the details and click save
  2. Start uploading photos – this involves:
    1. Switch to the upload pictures tab
    2. Select the album they want to upload against
    3. Upload their photos

So, we expect the user to know that’s the steps. However, is that obvious? No not really – there is nothing to stop the user blindly going and straight to the upload pictures tab to be stopped in their tracks when there isn’t an album for them to select. Granted, this is hardly the end of the world, but you’ve just slowed them down. They’ve now got to back track and create an album. Grrr.

So what can we do to improve things?

A small improvement

You don’t have to make major changes to your application in order to have a big difference on its usability. All we want to do is give the user a hint to suggest what to do next. A simple quick fix could be the following:

Here we’ve added 2 buttons to the front page. The button for creating a new album is shown immediately below the empty list – this creates a visual grouping between the empty list and the means to add items to it. We’ve also introduced the dependency between the albums and the pictures – the upload pictures button is disabled and re-labelled to instruct them to create an album first.

This isn’t a major change, a few minutes work. But we are giving the user a crucial pointer as to what they need to do to next.

A bigger improvement

But let’s go further. This is our first impression – let’s make it a good one. Let’s hold the user’s hand, guide them through the process. We’ll do away with the empty list altogether and replace it with some instructions. They can’t upload photos until they’ve created an album so let’s remove all mention of it. We’ll even include a screencast showing them how to do it:

Great, the user is left in no uncertain terms as to what they need to do next. We can now go even further; we can progressively introduce the interface – the user now has an album so we’ll show that control; but they haven’t got any photos yet – at the position where their photos would be we can show them some further instructions:

The above approach progressively replaces instructions on how to create content with the actual content itself. The user sees one of two things 1) Their content or 2) Instructions on how to create it. This makes it easy for them to get up and running.

Granted this is a fairly trivial example, but it should be evident that as applications get more and more features it becomes harder and harder to join up the dots. You don’t need to go to the extent suggested above, but you should take steps to ensure that a user always knows what they need to do next.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | Tagged | Leave a comment

How to Write a Good Empty State

What is the empty state?

The Empty State is your software in its initial state before the user has entered any data or set anything up. It’s what your new users are exposed to the first time they use your application. It’s a crucial phase; this is before your users have experienced what your application can do for them; before they have fallen in love with it and realised they can’t live without it. It’s where you are at your most vulnerable of losing a user because your software is “too hard”.

However, despite this importance it is it is often neglected. Developers have their test data and the software works great! Salesmen have sample data and run their demonstrations using that – it all works just fine! Nobody ever deletes it and sees what happens. So a new customer installs the product and is faced with a blank slate! In many cases they have to fumble their way through guessing what steps are needed to start being productive.

How do you do it right?

So how do you do it right? How do you help your user through this crucial phase?

First of all you need to recreate the problem: Perform a new install of the software, delete your sample data, create a new account. Do whatever you need to do to get your application in to the same state as it is received by the user. Once you are looking at the same thing as a new user would you can take stock of the situation:

  • Is it obvious what a user needs to do next? Do you tell them that or are you assuming it’s obvious?
  • Where ever there is an empty list of things are you explicitly saying that it is empty or are you just outputting nothing? (“Nothing to display”, “0 Records Found” or any other equally generic statements count as nothing!)
  • Are there any errors because your software assumes “there will always be at least one of those”

Ok, so you’ve had a quick look around, now to address the problem. You would know what needs to be done next if you were asked to set the software up. For example, you might know to start by creating some more user accounts; that a user needs to add a project before they can add any task items etc. Assume your user doesn’t know this. Take a pen and paper and make a list of what you would do to start using the software. Put the list in order. Now, ask yourself, how does my user know that this is what they need to do?

Make your interface reflect your list. Hold your user’s hand:

  • If a feature is unused or empty. Add text to explain what the feature does and how to set it up or create the first record
  • Provide a link to jump to the settings/creation page for that feature
  • Would a demonstration video be even better?
  • Are there a series of steps that the user must go through in order? Why not create a set-up Wizard dialogue to guide them through the process?
  • Sometimes an example works the best. Why not give the user the ability to pre-populate the application with sample data? WordPress does this to help you set up a Blog – it can be useful when you’re a new user. You could go further and provide sample data for different kinds of user/market so that they are presented with relevant data.

Make sure you never leave your users unsure as to what their next steps should be.

I want to take this further, so I’ll be writing a bonus 2nd post this week on a simple case study to illustrate the above. Make sure to check back here on Wednesday for the follow up post.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | Tagged , | 4 Comments

5 Bare Minimum Usability Checks Before Releasing an App

Child's wooden peg and hammer toyAfter reading 14 bare minimum security checks before releasing a rails app over at RailsInside, I got thinking and wondered what are the bare minimum usability checks for an app before releasing it? Here’s my list:

Check your copy writing

Nothing is more confusing than unclear/ambiguous labels or messages. I’ve seen this happen in live applications – you end up crossing your fingers and clicking a button whilst hoping for the best! Read what you’ve written. All of it. Are there any double negatives in your labels/prompts? Are you inadvertently stepping on some industry specific terminology? This is particularly a problem in the finance industry where a simple descriptive word actually has a very specific meaning – problems resulting from this can be a nightmare to figure out!

Test it

Automated tests are a must, but make sure you actually have a run through the app yourself. Remember that your automated tests only check that it works the way it is meant to – not that it makes any sense! Put yourself in your users position – is it obvious how things work?

Delete all your test data

Your customer wont have all your test data or preconfigured settings like you have on your development box. Delete all your data or install a fresh copy. Go through the same experience your customers will. Is it obvious what they need to do to get started? Does it even work without this data?

Get someone else to use your software

Have you ever had difficulty explaining something that seems perfectly clear or even obvious to you? The same happens with user interfaces – what can seem like a clear interface to you can be totally confusing to someone else – you “know” what you mean… your user might not. Always get a second opinion. Sit someone in front of your application and see if they can perform basic tasks (without any hints!).

Constraints

As a minimum your app should always stop a user from entering invalid data. If a field expects a number – don’t allow letters. This basic step stops users entering unexpected data. You might think it’s obvious what is expected – but it isn’t – lets take a silly example: Say your app is showing a questionnaire that asks a user “How many sweets have you eaten this week?”. Your software probably expects the user to enter a number so that this can be added up later. But what if they said “a bag” or “two bars”? Both are valid answers to the question, but will probably result in an error when your software tries to convert the words to numbers. Help your users to do what you are expecting.

This isn’t a list of every check you should do to test the usability of your app – it is just the bare minimum. There were a number of other checks that I thought were important, but I couldn’t convince myself they were the *bare* minimum. I’d love to hear your thoughts and suggestions if you think there’s anything missing!

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Usability Bites | 1 Comment

A little quiet around here

Hi,

It’s been a little quiet around here for quite a while… Here’s why:

In May my wife gave birth to our first baby – Tabitha.

Anyone with children will know – they come as quite a shock to the system! Between the day job, decorating and working on some personal projects, my Blog has taken a bit of a back seat!

Thanks for being patient – normal service will resume (maybe in a reduced capacity) soon.

Thanks,
Ashley

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Misc | Leave a comment

Fitts’ Law

Fitts’ Law is a mathematical model that predicts how long it will take to “point” at a target. It was first proposed by Paul Fitts in 1954. It takes into account where you are currently pointing relative to the target; How far away the target is and how big the target is. It has been widely applied; but the most common application is as a measure of how long it takes for a user to move their mouse cursor to click on a target item such as a link or button.

Movements to a target occur in 2 distinct parts: firstly a big movement to get approximately in the right place, followed by a series of fine tuning motions to lock on. You can see these in action – watch your finger as you point at a small object at the far side of the room you are sat in now e.g. a light switch. Chances are you’ll move your arm in a big movement, probably overshoot, then make a series of smaller movements until you are pointing directly at it. Now try it with a bigger object – maybe you have a big TV hanging on the wall. Here you will make the same big arm movement, but because the target is so big you don’t have to make as many (or any) fine tuning motions – so it’s easier to acquire the target.

Lets look at some examples. In all of the below graphics the red box is the target; the dashed line represents the travel from the starting point to the target and the area marked over the target represents the dimension in which the user can decelerate and acquire the target:

Here we have a big target on the far side of the screen, because it’s big it shouldn’t be a problem to click on quickly:
Big target far away

The big target area means that the fine tuning motions aren’t necessary before the cursor comes to rest over the target.

In this next example we have a much smaller target on the far side of the screen so it’s going to be harder:
Small Target Far Away

Because we have to move the cursor a long way and it’s a small target it’s going to take a series of fine tuning movements before the pointer is correctly aimed at the target.

However, if the small target is close by – it is less of a problem to hit because the initial movement to get there is smaller – reducing the risk of needing to correct an overshot.
Small Target Close to pointer

It is important to bear in mind that for irregular shaped targets, size is relative to the plane of movement. In the following example, if you are moving to the target horizontally the button is quite big, however, when approaching from above or below the target presents a much smaller area.
Irregular Shaped Target

In addition to the size of an object, we can make a target easier to acquire by placing it at the edges or corner of the screen. This is because they are “infinitely targetable”; that is – you have an ‘invisible barrier’ to work against. You make the initial big movement then you don’t need to make the smaller fine tuning motions as any excess overshoot is ignored.

This is used by both of the major OS vendors to good effect:

Mac OS X has the Dock at the bottom of the screen; this is infinitely targetable as you can’t point your cursor at a point lower than the dock so it’s always clickable:

Mac OS Desktop

On Windows, the Start menu is in the bottom left corner of the screen – the corner is infinitely targetable as if you make a big mouse gesture towards that corner you will always end up over the start menu button.

Start Menu

One of the big differences between Mac OS X and Windows is the location of program menus. Mac OS X has the menu across the top of the screen whereas Windows has them attached to individual application windows. Fitts’ Law shows that in many cases the Mac approach is superior: On the Mac you throw your pointer to the top of the screen and you automatically end up over the menu. On Windows you have to go through the full sequence of making a big movement, then smaller correcting movements before you end up over the menu. There is no region of infinite targetabiltiy.

However, the Mac’s approach is starting to see limitations. Whilst it is infinitely targetable, Fitts’ Law includes a measure of your current location. As large monitors and multiple monitor set ups become more and more common, the Mac user is having to travel a significant distance to reach the menu at the top of the screen, potentially outweighing the time saved by reducing the need for finer movements.

Fitts’ Law Applied

One of the biggest disappointments for web developers is that we can’t easily take advantage of the edges and corners of the browser window. So we have no infinitely targetable areas we can use to our advantage. So what can we do:

  • Make your links bigger by increasing the targetable area. Use padding around links so that the user has a little forgiveness around the text they are trying to click
  • When you have several clickable items or links together either make the items larger or space them out a little. Page navigation links on search results is very often done badly. For example, this results page has far too much too close together: Links too close together Whereas Amazon do a much better job, nicely separating the individual links: Amazon search results
  • Make the button a user is most likely (or most wanted) to click bigger. E.g. Make your OK button bigger: OK Cancel
  • Group actions together – if related interactions are near to each other this not only increases their relatedness in the eyes of the user but also reduces the mouse movements necessary to move between them

Finally, don’t be afraid of experimenting! 37 Signals have a really interesting use of Fitts’ Law on their “Signup” button for Sortfolio – as you hover over the button it grows and shows more information – so as you begin to make the fine tuning movements to precisely acquire the button, the need for them is reduced by the target button growing! Fantastic stuff!

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | Tagged , , | 3 Comments

Link: Train Toilet Usability

Dan Sumption in his comment on my post Why We Test included a link to a post he wrote back in 2002 about train toilet usability. I’ve been wanting to write a post about the insanity of these “automated toilet experiences” for a while, but haven’t been on a train in order to relive the horror. Dan’s post captures the frustration perfectly – well worth a read: Train Toilet Usability

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Links | Tagged , | Leave a comment

The Invincible QWERTY

My old friend and Usability Friction reader Omar Ikram sent me a link to 3 Ways the iPad Could Kill Qwerty. It’s an interesting read. But I can’t help thinking the author has got the wrong end of the stick. I think whist we are using our fingers to type, QWERTY is here to stay.

The link above proposes 3 competing technologies that could unseat the QWERTY keyboard as the interface mechanism of choice, especially on the iPad. I’d like to respond to each of them before making my point.

Swype

This one isn’t really replacing qwerty as such – rather providing an alternative mechanism to typing individual keys. This is an interesting technology, but I think it has a number of flaws:

  • On the iPad this would be a really poor technology. On a small screen – great – it reduces the need to hit a tiny individual target key. But on the iPad – a device with a keyboard almost the same size as on a MacBook (and much bigger than many netbooks) you’d have to slide your finger way too far for this to be pleasant to use. Even one-handed I suspect I would rather type normally
  • Another problem is that unless you know where to slide your finger to (i.e. you know the qwerty keyboard well) you will struggle. If you watch the video in the above link the user’s hand is obscuring a good amount of the keyboard. Users who aren’t that familiar with qwerty wont be able to make those smooth meaningful gestures that can be quickly interpreted by the software.
  • It is also quite confusing to a non-familiar user. The UI presents keyboard style buttons. But you never “press” these buttons, you slide across them – this creates a an uncomfortable conflict between the visual representation and the desired interaction.

So in a nutshell Swype doesn’t remove qwerty anyway – just gives a new and interesting way to interact with it. But I’d like to see this develop further – maybe in time it will take off. Mobile phones are a hotbed of interface innovation so who knows – if it can gain traction here and the problems I have identified above can be mitigated then maybe it will become widely used.

Thick Buttons

The author is ill informed here. Thick Buttons is just a poor copy of a technology the iPad already has! Thick Buttons implementation is continually resizing the buttons on the screen based on a key’s probability of being struck next. This makes them jump around and be a moving target whilst you are trying to type! I can’t imagine this being anything other than maddening! The iPad’s OS has a superior implementation – the hit zone for the buttons resizes rather than the buttons themselves.

This video was released by Apple around the time when the iPhone was released – have a look at around the 2:40 mark for a demonstration of Apple’s implementation:

Phonetic Typing

Hmm. I can’t really see that approach taking off with the average user! Even the original author discounts this one! Probably more likely to remain as an academic exercise!

My take

How much time do you have invested in the qwerty keyboard? Years? Decades? For the vast majority of us it’s the only keyboard we’ve ever known (not withstanding pecking at a number pad on our mobiles back in the pre-iPhone days!) The DVORAK keyboard, despite being shown to increase typing speed, has gained little traction. To those of us who have been typing for so long, our fingers just “know” where to go. It’s almost muscle memory. We don’t think about typing we just do it. With practice we can even type reasonably fast on tiny phone qwerty keyboards.

So what might ultimately replace qwerty? Speech recognition? It’s the holy grail of data input. But even if the speech recognition was perfect – compensating for regional dialects, accents and slang. Even then, would you want to be in a office full of people talking in to their computer? The noise would be unworkable and how would you write personal emails?!

Could subvocal recognition (if it can develop far enough) overcome this drawback? Quite possibly, but I certainly type differently to how I speak. Would I want my written word more closely match my spoken word? No, not really. The written word doesn’t have the tone and inflections used in speech, so we use different words to achieve the same ends.

We know there are better ways of inputting data. We know the DVORAK exists. But how many of us want to learn it? How many of us have time start again? We introduce children to the qwerty keyboard when they are so young. By the time they are old enough to do anything about it they might have over 15 years of practice! Despite its flaws, can many people say their text entry is slow enough to warrant the learning curve? Even then, would you consider a different input mechanism or just look at ways to speed up your typing?
Then if you did learn another input mechanism – how would you cope when using someone else’s computer? There’s a lot of qwerty keyboards out there!

Inertia is a powerful thing. When something has been around for over 100 years it’s built up a lot of inertia. So, it will take something several orders of magnitude faster, trivially simple to use and quick to master before anything stands a chance of unseating qwerty. But I doubt it will be in my lifetime.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Usability Bites | Tagged | Leave a comment

The 80/20 Rule

The 80/20 rule, also known as Pareto’s Principle, states that 80% of an observable effect is caused by 20% of the variables at play. The first recognition of this rule was by Vilfredo Pareto, who in 1906, recognised that 80% of Italy’s wealth was owned by 20% of Italy’s population.

The same 80/20 split can be seen in many places; management, economics, software/interface design, quality control systems and many more places. Whilst the rule is called the 80/20 Rule – the actual percentages are not all that important: 90/10, 70/30, 80/20 are all valid variations. Indeed – it is perfectly valid to say 70/10 as there is no requirement that the two sides add up to 100 – the important thing is the principle that a large number of outputs are determined by a relatively small number of inputs.

So using the 80/20 rule we can say:

  • 80% of users only use 20% of features
  • 80% of bugs are caused by 20% of the code
  • 80% of development time is spent on 20% of the code

This rule of thumb is useful when focusing our time and efforts on improving our products. We first need to find out what our most important 20% is. The easiest approach to this is to simply ask customers what their favourite features are or maybe observe them using the product. Developers of web applications could use tracking software such as Google Analytics to provide detailed information on which pages customers are accessing the most. Alternatively, simple logging could be added to a desktop or web application.

Armed with this information we will know which 20% of features provide 80% of the value of our products. We can then spend time polishing these features rather than diverting efforts on to rarely used features. This approach will lead to the greatest improvements and make the biggest contributions to customer satisfaction. If we make a change that benefits 80% of our customers then that’s a big win and is going to generate a lot of good feelings. Much more so than adding a similar scoped feature to an area that falls under the less used category.

This isn’t to say we should completely neglect the less frequently used features – that proportion is likely to be very important when it is needed – but when we are faced with limited time and resources, focussing our efforts on the most used 20% will gain a disproportionately large benefit to our product and users. It is rarely considered a bad thing by users when we make improvements to the benefit of our most used and popular features!

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | Tagged | Leave a comment