Tuesday, 24 July 2007

Train ticket machines — UK vs. Germany (Part 1)

Written by Martin Kleppmann on Tuesday, 24 July 2007, 18:10 GMT.
Filed under: electronic devices, software, usability.

I reveal a shocking comparison between ticket machines in British and German railway stations. The average traveller in Germany needs to press 4.5 times as many buttons as the British traveller to purchase a simple return ticket! Part 1 of my series on ticket machines.

One of the things which unite the British and the Germans: both love to complain about their respective trains and rail networks. In both countries, very few people have a positive opinion about trains, stations and everything that belongs to them. I think that some of these complaints are unjustified, and I do not want to support a general condemnation of what is basically a pretty good service.

Still, there are many differences between the British and the German rail systems. In Britain, there is a whole host of different companies involved, while in Germany rail transport is dominated by a single company, Deutsche Bahn AG. The fare structures in both countries are completely different; for example, in the UK, cheaper advance fares are only available on single journeys, while in Germany advance fares exist only for return journeys.

One aspect which I want to examine today is one particular way how customers get in contact with rail operators: through ticket machines. Ticket machines are getting more widespread in both countries, and in Germany you even have to pay a surcharge if you don’t want to use a ticket machine and would like to speak to a human being instead. At many small stations you don’t have any choice but to use a ticket machine. It is therefore crucial that ticket machines are accessible and usable by absolutely anybody: regular commuters and occasional travellers, children and senior citizens, locals and foreigners, geeks and technophobes. Quite a challenge!

Last weekend I was in Germany, which gave me an opportunity to compare the ticket machines there to the British ones. I took photographs of the screens, which I will present in detail in two separate articles. Today I will compare just summary views of the two contrasting system.

The comparison

Some of the points to consider: How long does it take an average user to buy a ticket? Can the machine quickly serve common requests, as well as cater for occasional unusual requests? How usable are the machines for visitors, who are not familiar with the fare structure and other national particularities?

In terms of speed and ease of use, the German machines performed shockingly badly compared to the British ones. On a British ticket machine, you need to press four buttons (four clicks) to buy a return ticket to a common destination. On a German ticket machine, buying a return ticket requires a minimum of sixteen clicks — four times as many — and that’s if you know the machines well and and find the “fast track” screen!

If you have a railcard in the UK, you need two additional clicks to tell the machine about it, increasing the process to six clicks. Not so with the German machines. There, an average BahnCard owner will make a whopping twenty-seven clicks or more to buy a return ticket. 350% more than the British equivalent!

Even the most seasoned and quick-fingered rail traveller will need at least a minute to buy such a ticket in Germany. And if you are not familiar with the system, it is not at all surprising if you get lost in the depths of the menus and need 10 minutes or more. In fact, while I was photographing the screens of a German ticket machine, I was approached by a group of Bulgarians who couldn’t work out how to buy a ticket from Stuttgart to Ulm, a very common route. And I had complete understanding for their difficulties!

The biggest difference between the two systems is that German ticket machines have an integrated timetable service, while British machines simply sell you a ticket to a destination, and leave you to your own devices to find out which train to board and where to change. I prefer the British solution, because the majority of people know their route well and don’t need to click their way through lots of timetable information. However, the German machines can be extremely useful if you’re stuck in the middle of nowhere and want to find the best route back to civilisation — they even tell you where to change and which platform to go to at each station. The British machines lack timetable information even if you specifically want it.

Two other problems with British machines are that you cannot use them in any language other than English, and that they assume you know about different types of fare. If somebody comes from abroad with only rudimentary English, they will have difficulties telling the difference between a Cheap Day Return, Saver Return, Open Return and First Open Return, let alone a whole zoo of different advance and operator-specific fares. It will not be easy for them to work out that some fares are only valid at certain times of day, or carry other restrictions. This could be made a lot clearer at the expense of a small number of additional clicks (while still staying far short of the German navigational nightmare).

In summary, I think that British ticket machines win this comparison by a wide margin. However, there are also a few aspects which they could learn from German machines.

A few additions: what about people with impaired vision? Can they get the option of having the ticket machine read out loud to them, and controlling it via a tactile keyboard?What about people who are too short to be able to see the screen? What about people with motor problems, who have difficulties hitting the right buttons? These questions are not straightforward to answer, but I hope that they have at least been given some consideration when designing ticket machines.

Friday, 20 July 2007

Usability aspects of gas cookers

Written by Martin Kleppmann on Friday, 20 July 2007, 14:15 GMT.
Filed under: power-off day, usability.

In this first article of the “power-off” series, I shed light on how we interact with low-tech equipment — in this case, a kitchen stove. Considering that this device has only five knobs and no electronics, it exhibits some surprising usability problems!

It’s Friday today, and since everybody likes to slow down and take a step back from their work on Fridays, I will designate Friday to be the power-off day in the Yes/No/Cancel magazine. It’s the day to switch off the computer and look at things beyond it. As a computing professional, you occasionally forget about the real world around you!

(Ironically, I’m still using my computer to write this article and you are using yours to read it. So it’s hardly sticking to the spirit of “power-off”… but how about this: If you want to really go for the whole non-electronic experience, give me your address and I’ll post you the power-off article every Friday. Yes, on paper. How about that? Shocking, eh?)

Today’s topic is the gas cooker at my home in Cambridge. And no, that’s not such a lame topic as you may think. This is a device which I interact with pretty much every day, and it is therefore important that I feel comfortable using it.

View of a gas cooker

Here is a photo of it — click it for a larger picture. (I specially cleaned the cooker for this photo!) Very simple device: four hobs, one knob to control each of them, and a button to trigger an electric spark which ignites the gas. What could possibly be wrong with it?

My main problem with this cooker is that I never know which of the four knobs controls which of the hobs. Ok, the front two knobs are for the front two hobs and the rear two knobs are for the rear two hobs. But amongst these, which is which?

The only way of knowing is to look at the tiny diagram beside each knob. And the diagram is inconveniently placed such that it is hidden behind the knob if you are standing in front of the cooker! You therefore have to lean over in order to see the label. I generally cannot be bothered to do this, so I just try one of the two possibilities at random. And I generally get it wrong. And I get annoyed with the cooker. Call me lazy, call me a slow learner, the end effect is still that I’m annoyed. (Hey, I cook for myself from basic ingredients, I can’t be that lazy.)

The solution would be to arrange the knobs in such a fashion that it is immediately clear which one controls which of the hobs. The easiest way of doing that is to arrange them in a square, rather than in a straight line; however that might be impractical as the cooker would have to be wider. So this is my suggestion, an arrangement which is unambiguous but requires hardly any additional space:

Alternative knob arrangement for the cooker

(Comments on whether it is more aesthetically pleasing are welcome.)

Knob to control one of the hobsI’ve not finished yet. The next thing I want to mention is a bizarre feature which seems to be common to gas cookers. (I grew up with electric cookers, so this is a bit new to me.) Here is a picture of one of the knobs. The arrow points to the right, which is its “off” setting. To turn on the gas, you turn the knob anticlockwise. Two things I find bizarre:

  • In all other devices I can think of, turning the knob as far as possible anticlockwise turns it off (the “leftmost” position). Here you need to go as far as possible clockwise.
  • When you gradually turn the knob away from the “off” position, you suddenly get the maximum flow of gas; then as you turn it further, it gradually decreases again. The small flame is furthest away from the “off” position, not closest as you may expect.

I’d be grateful for any explanation of why gas cookers work this way. My hypothesis had been that it’s good to get a strong flow of gas first thing after turning on, so that the spark will cause it to ignite quickly. Only today when taking the photo did I notice the little spark symbol next to the little flame. This suggests that you’re actually supposed to turn the knob all the way round to the little flame for ignition — that completely messes up my theory. Any other ideas?

I must say though, the strange behaviour of the knob doesn’t irritate me, as I’ve got used to that. The arrangement of the knobs does though. And in two weeks I’ll be moving house, so I’m going to have to start all over again getting to know my cooker.

Thursday, 19 July 2007

Yes/No/Cancel causes Aspirin sales to soar

Written by Martin Kleppmann on Thursday, 19 July 2007, 16:00 GMT.
Filed under: software, usability.

Welcome to Yes/No/Cancel, the online usability magazine. This first article describes the origin of the name, and explains why it is bad to use buttons labelled Yes, No and Cancel in computer programs. I also discuss why user-friendliness in general is a very important topic.

This online magazine (or blog if you will) is about user-friendliness, and lack thereof. It criticises bad design and promotes good design. One might think that after usability research has been conducted for many years and many books have been written on the topic, finally people would have learnt to get it right. But no — my impression is that many products are as bad as ever, and the reason why I am writing this is to raise awareness of these problems.

But why should you care? As a user, you should care because you have a choice — you can stop using/buying the product that is not friendly to use. You can switch to a better one, saving you frustration and annoyance. As a manufacturer, you should care for much the same reason — you are in a competitive environment, and if you don’t carefully consider the needs of your customers, you will see them leaving very soon!

Maybe you ask how this website got its name. Yes/No/Cancel, that sounds like computers. Yes, and a lot of the content here (but definitely not all) is going to be about computer software. Today, many pieces of software are amongst the most complex pieces of engineering which the human mind has devised. It is therefore not too surprising that some software packages are extremely difficult to use. But software is also used by many people every day who don’t want to know about this complexity. Is difficulty of use really necessary? There are some examples of extremely complex systems which are absolutely straightforward to interact with (Google search for example — it’s the work of a big team of the world’s best software engineers over several years, and still it’s just a simple search box).

Making complicated systems easy to use is actually quite a difficult problem. Part of the problem is that the engineers designing the system are often used to a certain way of doing things, but this way is not always best adapted to a particular situation or audience. The designers and developers of a system must therefore constantly be questioning their habits, so that they can find better ways of solving problems if better ways exist.

One particular bad habit of programmers annoys me so much that I decided to name this website after it. Johannes suggested the name: Yes/No/Cancel. The choice you are so often presented with in many computer applications, and so often you have to stop and think, because it’s not immediately clear what each of the choices is actually going to do. Which one of the buttons will cause all your work to be lost if you press it? Which one will save it? And what does Cancel mean anyway? Aaargh, it causes headaches.

Let me explain this with a few examples. A situation in which you frequently encounter a Yes/No/Cancel dialog box is when you are trying to close a document without having saved it. Like this:

Do you want to save the changes? Yes/No/Cancel

Nice of it to ask, you say — you had completely forgotten to save. Ok. Now compare it to this one:

Do you really want to quit without saving? Yes/No/Cancel

Can you believe it? It’s asking the opposite question! Now even if you usually know by habit which button to press, suddenly you have to stop and think. And this box is even worse, because it’s not clear what the difference is between No and Cancel.

Fundamentally the problem here is that we are actually asking two questions at the same time:

  1. Do you want to save the document?
  2. Do you want to quit the application?

The answer to each question might be yes or no, which gives us four different possible actions:

  1. save changes and quit (the “Yes” button in the first example)
  2. discard changes and quit (the “No” button in the first example)
  3. do nothing — do not save and do not quit (the “Cancel” button in the first example)
  4. save changes but do not quit

The fourth option is generally perceived to be silly, so there is no button for that purpose and we get a choice of three. In the first example picture, these three correspond to Yes, No and Cancel respectively. What about the second example? Clicking Yes will “discard changes and quit”. Maybe clicking No will save changes and quit, or maybe it will do nothing. Who knows what cancel will do, let alone the mystery of the red X in the corner.

Already with simple examples like this, you can begin to see that it’s a bad idea to label buttons as Yes, No and Cancel. The meaning of these words depends very much on the question. In fact, if you have no previous computing experience, you will probably have no idea what to answer. As a user, you just want to know which button is going to cause your work of the last 2 hours to be lost — and neither of these examples makes it immediately clear which the “dangerous” button is.

Apple have tried to avoid this problem by not labelling the buttons Yes/No/Cancel, but more descriptively:

Do you want to save changes to this document before closing? Don’t Save/Cancel/Save

Using a verb (in this case “save”) is recommended in Apple’s Human Interface Guidelines. Also note that the “dangerous” button (which discards changes and quits) is set apart from the two “safe” buttons. This is clearly much better already, but the program is still trying to answer two questions at the same time, which you may consider to be an unnecessary complication.

I won’t dwell on any Microsoft vs. Apple discussion though, because what I am saying applies not just to these two companies, but also to every other organisation or person who writes software. And there are some terrible occurrences of Yes/No/Cancel in the world for which neither Microsoft nor Apple carries any blame.

One terrible thing which you see sometimes is an implicit relabelling of the buttons. Here the programmer clearly couldn’t be bothered to make his own buttons, and instead placed the burden on the user:

The connection failed. Click Yes to try again, No to ignore the error, or Cancel to quit the application.

You really need to switch on your brain to decide which button to press. And by phrasing the question badly, it can get even worse:

It is not recommended that you continue without overwriting this file…

At this point, I very much hope that you will have run out of the room screaming. And maybe returned to read the rest of this article. (With a headache.)

You might think that the last example was very contrived, but the point I wanted to make was about negative questions. Why ask whether not to do something (the negative) if you can simply ask whether to do something (the positive)? I find this occurring particularly frequently with respect to checkboxes:

Disable nuclear missiles?

It is counterintuitive to put a tick in a box for something you don’t want. Just don’t ask negative questions. But that’s a story for another day.

A few final remarks:

« Previous Page