Usability of Ticket Vending Machines

Most of us know ticket vending machines that are used for public transport. While people who often buy a similar ticket usually have no trouble using them, it can become quite hard for functions that we rarely use or for people who only rarely use the ticket vending machines. Why is it so hard to program them well?

What we actually want to achieve is searching an item in a multidimensional space. There might be many parameters relevant to the actual ticket and we need to find it through the navigation mechanisms that are offered to us by the software. Sometimes it is straightforward. For local transport some people want to buy a ticket for zone 1B and then they even find this offered on the home screen. Other people have no idea what this zone 1B is and actually do not even care. They should know where they want to go and the system should then know if it is „Kurzstrecke“, „Zone 1A“, „Zone 3D“ or whatever. But the zones might be a useful shortcut for the experienced user, because it can be known that in this case many different travel destinations can be covered by the same ticket, which can be found in a second on the home screen. Making it fast for the experienced user is actually a very good idea, because it saves the time of the customer and of the machine. But the more natural approach of just entering the destination should be provided as well. Up to this point they have actually done it quite well in some vending machines that I have seen.

But then there are some issues that are hard to deal with. I just give some examples that I have experienced without claiming to be complete.

In some cases there is a different ticket universe for local destinations in some area around the location and destinations outside of this. For example the region of „Schleswig-Holstein“ in Germany has a „Schleswig-Holstein-Tarif“ which applies to certain more local trains. The first step when buying a ticket was selecting between „Schleswig-Holstein-Tarif“ and something else. Which is something the customer should not need to care. It is bad to require knowing to which destination and even worse to which trains „Schleswig-Holstein-Tarif“ has to be applied and to which not. In this case „Hamburg“, which is a different region and not part of „Schleswig-Holstein“ as a destination was still part of „Schleswig-Holstein-Tarif“, which can be found out by trial and error, by asking someone or by using google on the smart phone. Hopefully the train is not leaving in 5 minutes. But again, depending on the train, it is anyway not „Schleswig-Holstein-Tarif“. Yes, the ideas behind it are not too hard to understand and many people know them like many people know what „Zone 1B“ means. But some don’t and they are having a hard time. The right way would be to ask for the destination and then offer some train connections or some choices for useuful and accessible parameters for train connections to pick the right ticket.

The next issue is that it is usually possible to buy the ticket in advance for the next day, which is a good idea, because it eliminates the stress of having to buy the ticket or having to wait in a line while the train is due to leave. When I tried that, it was not possible with „Schleswig-Holstein-Tarif“, which was again something that took some time to find out. The information that this is not possible should at least be easily available or even better it actually should be possible to buy all tickets at least a few days in advance.

The pricing system should be logical. While it is annoying that flight ticket pricing can only be understand by discarding all logic, this does not work well at all for train tickets, because there are much more stations and thus much more different possible tickets to calculate. A funny example was once constructed with three towns. A, B and C are in a line. A and B are far apart and an important connection. C is very close to B. It was possible to buy a return ticket from B to A. But it was cheaper to buy a ticket from B to C via A, because this was considered as one path and a discount applied because of the longer distance, which did not apply for the path from B to A or from A to B and the return ticket was calculated like a combination of two one-way tickets. This was resolved by disallowing the ticket from B to C via A. A better solution would be to make the tariff system more logical. If it is hard to distinguish between a return ticket and a one-way via-something ticket, it would be better to unify the discount in such a way that the same kind of discount can be given depending on the total distance covered by the whole ticket.

When taking a bicycle on the train, a bicycle ticket needs to be bought. Since this is a more rare case, it is not found on the home screen and it has to be found through some navigation. I do not have an easy answer for this, but it should be done in such a way that it can actually be found by an inexperienced customer without too much difficulty. I had to use google on my smart phone for the last bicycle ticket that I bought, which is not how it should be.

Many railroad companies offer a ticket for frequent travelers which needs to be paid once a year and then provides a discount for most tickets. It is sometimes not clear, when this discount is available and when not. This information should be easily accessible during the ticket buying process.

I think that ticket vending machines are an interesting example of usability and a lot can be learned from them for other applications. And a lot of things have actually been done right, but that is not enough.

See also:

Share Button

WPA2 compromised

The WPA2 protocol has been compromised. The so called KRACK attack allows reading encrypted content.
It was always a good idea to use encrypted communication on top of WPA2 for sensitive data, like https, ssh or a VPN. This practice has been recommended in this blog before, which was again inspired by what Bruce Schneier wrote about it.

Anyway, we should certainly start of thinking of WLANs with WPA2 encryption as a useful transport mechanism, but not as a very secure mechanism to encrypt data. At least from now on we should use other encrypted protocols on top of WPA2 where appropriate or use cable networks for internal communication that we do not want to encrypt additionally.

Links:

Share Button

Microsoft stops Windows Mobile

It seems that Microsoft is ending the development of Windows Mobile. After having tried with some effort to get into the mobile operating system business, it seems that the market share is now less than 1%, with Android being >85% and iOS close to 15% according to IDC. Because the market is so large, it would be possible to run a profitable business even with a low market share, but this is probably hard for a big company and it seems more attractive to concentrate on other areas. It is good to have some good mobile apps available for the platform and that is an area where Android and iOS shine, while doing a third app for Windows phone is a bit unusual. A funny detail is that a retired guy, who was once the founder of Microsoft and who is still associated with that company by some people uses an Android phone for himself. But he is retired, so that is no longer too important.

The story is a bit weird, though… In 2010 Stephen Elop became the boss of Nokia. At this time Nokia had a market share of around 50% in mobile phones covering a wide range from tiny „non-smart“ phone to high end smart phones. They were mostly using Symbian as OS, but the transition to Maemo and MeeGo, like Android Linux variants, was on a good way and it would have been worth seeing where this might go. At this time it was already quite clear that MS Windows phone/Windows mobile was a failure. All efforts concerning Linux-based systems were stopped and Symbian was announced as being a dead end and the strategy was to move to MS-Windows phone only. Most likely this was done because Stephen Elop had more loyalty to Microsoft than to the company that he was running. To my knowledge this never became a case for the courts, but one might assume some criminal energy behind this. And some stupidity of the stock holders, who selected this person as CEO. Some time later the mobile phone branch of Nokia went down and was bought for very little money by Microsoft. After that acquisition it was further downsized and will probably go to zero soon, because Microsoft does not have interest to develop new hardware.

As it seems, there are mobile phones with the brand „Nokia“ again. HMD, a company in Finland designs them, pays to the company Nokia some money to use their brand. And of course they use Android.

It seems that the issue of having to write a mobile app twice because of Android and iOS has become a bit less pressing. Besided mobile web applications that can pretty much behave as rich clients through modern JavaScript frameworks, there are „fake apps“ that are actually pretty much browsers without a visible URL bar and programmed to only surf their home site. And even native apps are now increasingly being developed in Swift for iOS and Kotlin for Android, which seem to be quite similar, at least at a conceptional level.

Share Button