Usability problems – “Don’t ask me again”

Note: This is post is one in a series of usability posts. To read my explanation about what usability is click here.

Shown here is one of the dialog boxes that Microsoft Outlook presented me with today. I have setup AutoArchive on my machine so that my mail items older than 3 months get copied into an archive file where I can still get them if I need to but they won’t clog up my inbox.

The problem I have with this is with the checkbox that sits there with the legend “Don’t prompt me about this again”. This bothers me because I don’t think it’s at all clear what that means.

Does it mean :-

• Based on whichever button I click on next (Yes or No), do that every time in future without asking me. 
• Don’t ask me again but just do it anyway regardless of whether I click Yes or No. 
• Don’t ask me again and don’t auto archive anything again. 

I have found myself in exactly the same position with “Read Receipts”. Outlook will pop up a dialog box saying “Don’t ask me again” but it doesn’t say which option will be the default action.

Personally I don’t like read receipts because I might want to read the email late at night and if a read receipt was sent then I know the person knows I saw it and then I feel an obligation to reply.

That said, these days, seeing an email and reading it are two entirely different things so “Read Receipt” should perhaps been “Viewed Receipt” to be more accurate but that’s an entirely different article!

I saw the read receipt dialog box lots and lots of times and always clicked "No" without checking the "Don't ask me again" option because I was concerned that if it didn't ask me again it might automatically send a receipt to anyone that requested it. I had to Google to find out how to set the default and stop the question properly before it went away.

Microsoft has many millions of users of Outlook yet I find myself having to Google to figure out what this little dialog box actually means and what will happen if I tick the option. If I'm having this problem - how many millions of other users are having the same problem? A brief round of questions to a limited panel of users would reveal to Microsoft that this option isn’t clear and is horribly ambiguous and needs changing. 

My point in this surprisingly short rant is that software developers need to be extremely careful about ambiguous terms in their systems. If something can’t be clearly and concisely understood by your users then you might need to rethink it.

People don't like change!

This is something I encounter quite a lot in my professional life but lately I've found it in my personal life too.

In my work life I see a new feature being introduced in software and people immediately hate it. This isn't just in software I'm involved with. A classic example is Facebook. Almost as soon as Facebook announces a new feature there is a message going around about how you can protest or keep the old way of doing it.

The problem for me is that there generally isn't anything wrong with the improvement that's been implemented - it's purely that people don't like change and prefer things "as they were". I tend to find that a few weeks later, people are used to the feature, have stopped complaining about it and probably now quite like it.

It's for this reason that I think it's really important that people involved with software development don't automatically react to the public outcry of disgust about a new feature or an improvement to the user interface.

Most of the time, the changes have been debated at length and every aspect of the changes scrutinised to ensure that the change is for the better. It isn't possible for a casual user without access to all of the feedback from the different users of the system to perform this sort of analysis.

In my personal life, I have just moved house to a small village. A few days after we moved it there was a meeting of the Parish Council. We were invited to the meeting by a neighbour and we thought it would be a good way to meet the other neighbours.

When we got to the meeting we discovered that the main issue and the reason that the Parish Council was having its first meeting in more than a year was that there is a proposed wind farm within a few miles of the village.

The farmer who's land the wind farm would be on was at the meeting and seemed very well informed about the whole plan and had been to see other wind farms to understand the full implications of the proposed project.

Anyone who has travelled a lot around Europe in the past few years will have seen wind farms absolutely everywhere. Personally, I really like them. I think the turbines are graceful and interesting and the fact that they are generating clean energy is a bonus.

Unfortunately, the local residents are totally opposed to the idea. This is despite the fact that there is a large wooded area between the houses and the proposed wind farm so they won't be able to see it at all. On top of that, there is a constant background noise from a nearby main road so they won't be able to hear anything. That doesn't stop them wanting to prevent the scheme.

Sadly, these days, nobody wants coal fired or nuclear power stations but it seems they don't want wind power either - well, they probably do as long as it's not near their house!

I really think that it's a shame that more people aren't open to change. Change is inevitable in virtually every area of life one way or another and resisting it will probably just make those people much less happy than they could otherwise be. I just guess it's a good job we're not all the same!

Usability problems: thetrainline.com

Note: This is post is one in a series of usability posts. To read my explanation about what usability is click here.

Thetrainline.com website allows you to search for train times for the UK rail network. On the surface of it, the site is quite well designed and simple to use. There is one major issue that really annoys me. It won’t allow me to search for train times “in the past”.

At this point I can imagine some puzzled faces as people read this and think “why would you want to search for a train in the past”. Well, there are a few times when that would be useful. However, the problem is compounded by the fact that the website only allows searching in 15 minute time intervals.

Let’s suppose it’s 16:31 and I’m 2 minutes away from the train station on my way home. I don't know what time the next train is and want to search to find out. At 16:31 I can only search from 16:45 onwards because 16:30 is “in the past”. That means that there may be a train at 16:39 (8 minutes from now) but I’m not allowed to see that!

Given that most of us carry a web enabled device in our pocket now, it can sometimes easier to look at train times on your mobile. This is especially true when you are at a big train station like London Victoria.

The other problem this presents is that when I’m using a tablet device (like an iPad) to search for trains, I often will leave the search results page open on the tablet. This means I can easily see when and where I have to change trains and what time the next train departs. Unfortunately, iPads sometimes aren’t very clever either so when you turn an iPad on after a period of inactivity it often doesn’t just show you the copy of the page that was already on screen – it goes to get a new copy. At this point, website will tell me that I can’t perform that search as it’s in the past!

If I want to search for a train journey in the past – would it hurt to let me? I think the website should warn me that this journey is in the past but let me see it anyway. That would seem to be a sensible solution!

Ironically, a good while after I started using this website I discovered that I can search for a time in the future and then use the “Earlier” link on the results page to go back and look at trains that are considerably in the past. This proves that the site is capable of delivering this information – it’s just the front page that prevents me which is stupid!

There is a lesson that needs to be learned from this story. Developers shouldn’t put “road-blocks” in software unless they are absolutely necessary. If someone can get around a particular road-block easily or there is no real downside to letting someone perform that function then the developers should seriously question why they’re trying to prevent it being done.

There are frequently times when it is necessary to limit what websites or software can do but these times need to be carefully considered and only be put in with good reason.

What is usability and why should I care?

In life we are totally surrounded by things designed by humans. Anything from a door handle to the most sophisticated software or website has to be designed. There are good and bad designers which means there are plenty of good and bad designs. Probably more annoyingly, there are also lots of designs that don’t really fit into either the good or bad categories but rather, sit somewhere in the middle!

Usability is the art of good designed so that the end product is easily usable. If you’ve found yourself in a hotel room trying to figure out how to turn the shower on; or pushing the wrong side of a door because it’s not obvious how to open it – you have been a victim of a bad design that has a lack of usability.

As a techie I often find myself looking at things and thinking “that’s stupid” because there are bits that just don’t seem to make sense. Most often it’s simple things that annoy me because they should be easy to fix!

I realise that as a software developer, I’m setting myself up for a fall here. Someone will read this post and then beat me with it over some bit of software that I’ve created but that’s ok – at least it may start a debate.

Of course, not everyone thinks in the same way and so differences of opinion always cause disagreements about how things should work. There are sometimes functionality conflicts which mean that something has to be the way it is because of other elements in the system. Additionally, there will always be budget, resource, legacy code and other constraints that limit what is possible. However, the things I’m going to focus on in coming posts are mainly because too often simple things aren’t good enough.

Designers of anything (especially software) should always be trying their hardest to anticipate the issues users will face and think about what makes sense for someone using the system. This is often hard for a software developer because we use the software constantly during development and so may forget what the system looks like to someone seeing it for the first few times.

This blog post is intended as a primer which I will refer to each time I post a message about a usability issue that I’ve discovered.