Yes/No/Cancel

I believe strongly that teams of software engineers should have good tools which help to manage the development process (as a minimum, bug tracking and version control of source code). We use Subversion and FogBugz, but there are lots of other good tools too. These tools get particularly useful when connected, so that it’s possible to see e.g. which changes were made to the code in order to fix a particular bug.

The usual way of connecting version control and issue tracking is that developers must enter a bug number every time they make a commit to the source code repository. And because most version control systems don’t foresee integration with a bug tracker, this is usually this is just a special string in the commit message (”BUG:12345″). A bit ugly, but works.

A neater way of doing this, for users of  Subclipse or TortoiseSVN, is to set a few magic properties in the base directory of your project. These graphical front-ends detect the presence of those properties and add a separate input box for the bug number to the commit dialog. The number entered there just gets translated into a line in the commit message, so it’s nothing magic, but it helps as a reminder to put in the bug number, and avoids having to remember the syntax for the bug reference (was it “Bug:12345″ or “Bug#12345″?).

Full details of this ‘bugtraq’ convention are described on the “svn commit ./me” blog.

Here’s what it looks like:

Screenshot of bug tracker, subversion and eclipse integration

This page has been offline for the last 24 hours because I messed up the server on which it was running (now I’ve moved it to another one). I officially hate system maintenance…

The server was running Ubuntu Feisty (7.04) which is now getting a bit old and gradually coming towards the end of its support lifetime. An upgrade would be necessary before too long anyway, so I decided to try updating it using the do-release-upgrade tool. My setup is pretty sane, using only standard packages, so I thought the tool would be able to handle the upgrade smoothly.

Unfortunately, no. At some point during the configuration of the new packages, dpkg started dying by segmentation fault, and from there on everything just went downhill. In the end I had a system with dozens of broken packages (and no way of fixing them with dpkg segfaulting), and quite a few daemons dying similarly. Probably some important shared library got replaced with an incompatible version — rubbish! Apache, MySQL and OpenVPN were dead, and I set them up on a new server; fortunately, Bind, Postfix and Dovecot somehow survived, so at least our emails are still getting through, and I could point the domain names to the new server’s IP address. Still, bloody annoying.

Why is server configuration and maintenance such a crap activity? What I really want is a sort of version control system for installed packages and configuration file changes. My wish list:

• The version control should save only modifications to config files (differences from the package maintainers’ versions) so that the same modifications can be merged into the configuration files for a new version of the packages. This also makes the setup more maintainable, because it is easier for one admin to see the configuration changes made by another admin. Elementary software engineering stuff really.
• I want to be able to generate a functionally identical system by taking a barebones install, applying the package installations and config file changes from version control, and copying in the contents of /home and /var/lib. Then I would never ever do an upgrade to a new release of the distribution; instead I would do a fresh install of the new release, configure it like the old one, test it thoroughly to make sure that it works, synchronise the contents, and switch them over in an instant. MUCH less stressful and error-prone.
• It should still be possible to edit the server’s config files like on any other, since all sorts of changes need to be made in day-to-day operation; such changes should be checked into the version control so that they are recorded and documented.

I have already built myself a tool for generating Amazon EC2 images — effectively a few Python and Shell scripts which take a barebones install and configure it completely for a particular application; I keep these scripts in version control so the build process is completely transparent and reproducible. However, if I make any modification to the image by hand, I need to remember to enter the same changes into the scripts, so that they still correctly reflect the build process. Really what I want is that manual step to go away.

I’m thinking that it oughtn’t be too hard to build such a system configuration management framework by putting /etc in a standard version control system, recording changes elsewhere in the filesystem, and making clever wrappers for a few standard maintenance tools such as apt-get (which just remembers somewhere which packages have been installed). Has nobody built something like that yet?

Choosing a web application framework. Aaaaargh, the pain.

Ok, so we’re actually in a pretty lucky situation right now: We have a new, substantial web development project, which we’re designing from scratch. It’s for a feature-rich, complex web application, it has got to scale well, and it has got to be maintainable. Those are the core requirements, and I thought they didn’t sound too demanding really. Between us in the team we have experience in most of today’s common programming languages, so that wasn’t an important point; what we wanted was the web framework which was objectively the best given our requirements.

Most frameworks, it seemed, were essentially suitable only for toy projects. There is a particularly ridiculous number of open-source web frameworks, and most of them don’t appear to be widely used in real-world situations. When I say real world, I don’t mean your average blog about kittens; I mean a site with at least 100 million page views per month or so. And I wanted the framework to be reasonably widely used, so that other people will have found the fatal bugs and already fixed them before we come along.

This left me with three options which seemed to me to be worth taking seriously:

1. Java Platform Enterprise Edition (JEE)
2. Ruby on Rails
3. Microsoft ASP.NET

Of course there are plenty more (Django came into consideration, for example) but judging by the contents of the computer section of my local book shop, those others must be pretty niche. Although ASP.NET looks like a reasonably well-designed platform I had to unfortunately exclude it straight away, because I don’t want the risk of being locked into a Microsoft platform (and I’m not yet sure how reliable Mono is).

So the showdown is between Java Enterprise and Ruby on Rails, and the contenders could hardly differ more in terms of their culture. In a nutshell, Ruby on Rails focuses on fast and agile development, while Java Enterprise focuses on flexibility and integration with enterprise IT. In Ruby on Rails, the common tasks are made very very simple, and if you stick within those common tasks, life as a developer is bliss; in Java Enterprise, even the simplest jobs require you to write ugly XML configuration or auto-generate boilerplate code. Ruby on Rails is what you’ll find on the servers of a cool young Web 2.0 start-up; Java Enterprise is found in the IT nerve-centres of investment banks. In a completely clichéd world view, Ruby on Rails hackers wear Jeans and T-Shirt, have a MacBook and a Linux server, and have a lot of fun; while Java Enterprise software engineers wear suits, have a Windows laptop and a Solaris server, and act very seriously. (I exaggerate.)

The instinctive tendency here is obviously to go with the fun, informal start-up types than with the boring corporate types. But wait, I was trying to make an objective decision, and the discussions about these platforms are already quasi-religious and emotional enough.

I have tried to come up with a list of criteria by which I want to judge these to frameworks. One by one, in no particular order:

• Developer productivity and learning curve for new developers. Ruby on Rails will get you started quicker, there’s not much doubt about that. In Java, I think the worst problem for a newcomer is actually the massive choice of different libraries to use and different ways to do the same thing — there doesn’t appear to be any combination of libraries which is particularly widely used; instead every tutorial, every manual and every book you find will use a different combination of technologies and libraries, which makes it particularly hard to learn the first steps. Because there isn’t just one obviously right way of doing something in Java EE, developers can spend a lot of time sorting out niggling little details, which slows them down and can be demotivating. I believe that if there was a full standard distribution for Java EE (e.g. Icefaces+JSF+Seam+EJB3+JPA+Hibernate+Glassfish, to name just one possible API stack out of thousands of different combinations), people would write a lot more good documentation for that particular stack, and it would become a lot easier for more developers to start using it effectively. With the right tools and good documentation, productivity could potentially be about the same for Rails and Java, but at the moment Java is shooting itself in the foot in this regard.
• Ease of recruiting good and motivated developers. I’ve not yet worked out how the two frameworks compare in this point. There are not many people who know Ruby, but those two do tend to be pretty passionate about it, so there’s an increased chance they will do a good job. Just about every computer science student learns Java these days (except at a few misguided institutions where they still teach C++), so there are plenty of Java developers around, although it’s not clear how many of them are actually really good.
• Standardisation of platform. This point is a combination of the last two points. If a lot of people use a platform, it is likely to be more stable, less buggy, better documented, better designed, faster, more supported in the long term, more interoperable with other systems, and so on. However, you can’t just judge by number of users — so many developers worldwide use plain PHP, the poor souls, and probably don’t even realise that although their LAMP platform is a quasi-standard, it’s complete rubbish for developing non-trivial applications.
• Manageability of a complex code base. This is the point where I personally really appreciate statically typed programming languages (call me old-fashioned). With Java in Eclipse, you can immediately search for the place where something is defined, you can refactor class and method names without too much fear (except when you use Java names in XML files), you get decent code completion, you know at compile-time which methods an object has (rather than calling something speculatively which may or may not be there), and so on. Dynamically typed scripting languages are great for prototyping and writing things quickly, but I find they start getting a bit scary and tricky to handle once you go past a few thousand lines of code.
• Testability and robustness — i.e. “if I change something here, how likely is it that I will break something at the other end of the application?”. Fortunately, both frameworks offer reasonable support for automated regression testing; Ruby on Rails probably a bit more so, because it relies primarily on automated tests (rather than a type system) to ensure things don’t fall apart horribly.
• Scalability, stability and reliability. This is a pretty important one, since any outage immediately gives a very bad impression to your users, and can potentially cost a lot of money. However, it’s hard to get hold of accurate reports on how well the frameworks behave in a harsh production environment, with a large number of concurrent users (hundreds of page views per second) and a large database. I’m inclined to attribute better stability to Java because it’s almost certainly used in corporates for more critical applications than Ruby is. Ruby on Rails, on the other hand, has had some pretty bad press concerning its scalability. The biggest RoR deployment at the moment is apparently Yellow Pages; rather embarrassingly for both them and for Rails, this site has actually been down for at least the last 12 hours as I write this post.
• Internationalisation and Unicode. There are translation features in both frameworks, and they are both ok, although none really strikes me as brilliant. The bigger issue is with Unicode support. I agree fully with Joel Spolsky’s opinions in this matter — there is no such thing as 8-bit plain text. And yet, I could hardly believe my eyes, Ruby treats strings just as an array of bytes, 8 bits per character, unspecified encoding. You can put UTF-8 in them, but then the standard string editing methods will rip them up and make them invalid. For heaven’s sake, guys, we live in the 21st century! Do you not want to sell your software worldwide or what? Ok, there are some UTF-8-safe methods, but you’ve got to remember to call them explicitly. At least Java encourages you to specify an encoding when you convert between byte streams and strings (although in my opinion it still isn’t radical enough — all conversion methods without an explicit charset parameter ought to be marked as deprecated, to make it really clear to the developer what they are doing).
• Toolchain support. Java has been around for a long time, and some pretty powerful tools to support it have evolved in that time (we are using the commercial MyEclipse and it’s doing a good job for us). Ruby on Rails is younger, but is actually quite well supported too due to its active developer community — Aptana is pretty neat, for example.
• Libraries for additional functionality. Since Java is so common, libraries for it are also very common — pretty much whatever you want to do, you can download a jar file to do it for you. With Ruby we’re not that far yet, but more and more libraries are being ported, so this is not likely to be a very limiting factor.
• Ease of integration with back end. We’ve got some algorithmic, number-crunching applications running in the background handling all the really clever technology. These are written in Java, and the web framework has got to be able to communicate with them. If the web tier is also in Java, that is easy; if it’s not, we have to write an explicit interface, but it’s not the end of the world either.
• Integrating with and impression on customers. Who’s your customer? If your application is targeted at general consumers who will use it over the web, they don’t care what framework you use as long as it works well. However, if the software is actually going to be licensed to an enterprise where the IT department have to integrate it with their own systems, then the technology matters. Not so much because of real difficulties (most integrations probably happen on the database level anyway, so the application server is pretty irrelevant) but because they are going to ask you what technology you use; if it’s different from what they use themselves, they will suspect that it’s going to be more effort to integrate, which might become their excuse not to buy from you.
• Long-term support. In 3–5 years’ time, what will have happened to the software? It may be that our application is still running, but will we still get security updates and bugfixes for the framework? Will somebody come along and completely re-write the API so that we in turn have to invest a lot in porting the application to the new API, or else risk running on an unsupported platform? This is crystal ball gazing of course, but to be honest: Java Enterprise is backed by Sun, and if there is one thing which big corporations tend to be good at, it’s keeping things the way they are. With Rails I fear more about the changeability of the framework over time. That said, the move from J2EE 1.4 to JEE 5 (two years ago today, incidentally) was pretty major, so maybe they are both equally changeable.

After all those points I’d like to finish off with a few things which I would rather not have:

• Too much flexibility in combining technologies. Abstract APIs create an illusion of portability — ok, so you think you can replace your PostgreSQL with Oracle by changing one line in an XML configuration file. Really? Not even subtle differences in query semantics? And how often are you going to make such a major change to the system like changing your database server? I don’t think it’s exactly such a common case that it has to be optimised for. It’s not bad to have those APIs, but they don’t add as much value as you might think at first. And as I mentioned above, having too much choice about the components from which you can assemble your system implies a lack of useful documentation and a slower learning curve for new developers.
• Boilerplate and duplicate code. You can create it with a code generation tool, with a bit of luck you can even keep it up-to-date with that tool, but it’s still extremely ugly and makes things harder to maintain. The main advantage of scripting languages in my mind is that things like database model objects are defined at runtime rather than compile-time, eliminating all that generated code. However, you then lose the static type system, so you can’t win on this one.

So where does that leave us? Do you have any further aspects or information which we should consider, or any specific experience with these technologies? Let us know by the comments below.

Over the Christmas holidays I was reading Joel on Software, the book summarising some of the most interesting material from Joel Spolsky’s blog. (The book is worth reading, although I did find it quite a shame that it was pretty much verbatim the blog contents pressed on paper for easier reading. It would have been nicer if the writing style had been changed from the slightly rambling, disconnected style of blogs to a more coherent style expected from a book. But the stuff Joel talks about is definitely worth reading for software engineers, in whatever form.)

The article which I found most interesting is his “Strategy Letter V” (page 281), which is also available on the web. It explains why, in his opinion, so many large companies are investing in open source software.

On the surface, open source seems a strange model for a business — why should a company spend a lot of time and money developing software, and then simply give it away? The claim that they have suddenly given up on capitalism isn’t exactly convincing. The claim that it’s cheaper from them to get free code contributions from teenagers than to write it themselves… not so sure about that one either.

Joel gives the first answer which I actually find convincing. He explains open source investment in economic terms, through so-called complements. For example, flights to Venice and accomodation in Venice are complements of each other: customers need both in order to get a holiday in Venice, but they are sold by completely different companies. And if flights to Venice get cheaper, more people want to go there, so there is higher demand on accomodation, so prices of hotel rooms in Venice go up. And vice versa. This economic effect of complements has been observed in many different markets.

So, if A and B are complements of each other, and the price of A goes down, then the price of B will go up. So, if you are a company selling B, and you are clever, you will try to push the price of A down as far as possible, even commodify it. That way, you can sell B for a higher price and you’ll be better off.

And now if you look around who is investing in open source software, you’ll notice that often the software released in this free manner is actually a complement of what that company is trying to sell. For instance:

• Google want to sell advertising on mobile web sites. Mobile web browsers and mobile operating systems are complements of mobile web sites, so Google make Android and release it freely in order to drive down the price of these complements.
• Our friends at Collabora are paid by Nokia to work on an open source platform for Nokia’s internet tablets. Nokia sell phone hardware, and the operating system is a complement of the hardware, so it makes sense for Nokia to commoditise it. Moreover, third-party applications are a complement of the hardware, so by opening the platform to the wide variety of freely available Linux software, Nokia increases the value of its hardware even more.

Once you think about it this way, it’s amazing how the economics begin to make sense!

Looking back at 2007, I can’t help but think that the iPhone was probably the most important and influential technology phenomenon of the year. It’s been talked about so much that I’m actually starting to get sick of it. But that doesn’t change the fact that it has had a significant impact, particularly on the way the mobile web works.

One of the most striking developments that ensued are the moves by several popular web sites to provide versions of their offering which are specifically tailored to people visiting their site from an iPhone. Amongst others, I found:

• Amazon.com
• Facebook
• Ta-Da Lists
• Meebo
• Netvibes

(Most of these sites show their iPhone look only to web browsers which identify themselves as Safari Mobile. To test them in a desktop web browser, see this article.)

iPhone specific development is fashionable, it seems. Some of those sites actually borrow and incorporate iPhone design elements (such as the style of lists and tabs, animation and icons), further blurring the distinction between web sites and applications. A List Apart, a widely respected resource for web developers, has even published a long article on how to develop iPhone-specific web sites (Part I, Part II). Apple themselves also offer in-depth information. iPhoneApplicationList.com maintains an extensive list of iPhone-optimised web applications.

Christopher Schmitt argues that making websites accessible for people with disabilities would expand a website’s reach far more than making an iPhone-specific site does. And Scott Gilbertson of WIRED thinks that the current situation is very similar to the old days when people were designing web sites specifically for Internet Explorer 4 (which was ahead of Netscape at the time). Jeff Croft suggests the opposite, saying that device-specific application development is going to happen anyway, and it doesn’t really matter whether it uses web technologies or not.

iPhone market share

What is the market share of iPhone internet browsing actually like? Hard to say, because it depends so much on what you measure. In terms of sold devices, the iPhone is performing strongly, but it is still a small proportion of the overall handset market. There are at least 100 million mobile devices with modern browsers (Opera Mobile, Nokia’s S60 browser, both of which are capable of displaying standard desktop web pages) compared to an estimated 2 million iPhones. Phones with WAP/XHTML browsers or adaptation browsers (such as Opera Mini) are a lot more numerous still. So in terms of the number of devices, writing iPhone-specific sites (as opposed to Opera-specific sites, for instance) really doesn’t make much sense.

Hitslink/Net Applications’ operating system statistics show that in December 2007, iPhone and iPod Touch users accounted for 0.14% of web page views, more than all other mobile platforms put together (Windows Mobile: 0.06%, S60: 0.02%). The Register reported this too. However, Ray Anderson, CEO of Bango, points out that these figures are misleading:

Hitslink produced this report by using data from their analytics customers. These people operate HTML/PC websites. They say: “You simply paste a small piece of HTML code on each page you wish to track statistics on”.

The 300 million or so mobile phone browser users (say 50 million S60) can’t or don’t browse HTML sites. They browse mobile friendly sites (WAP or XHTML or iMode) which will not have this HTML code in.

Considering that organizations like Bango, Admob, Peperonity, Vodafone report mobile browser traffic in the billions of pages per day, most of thse being S40 or S60 its clear that by ignoring non-HTML sites these stats are misleading and mistaken.

– Ray Anderson, in an email to Mobile Monday London mailing list, 5 Dec 2007

In other words, all that Hitslink’s statistics say is that iPhone users are more likely to visit more desktop web sites, but it doesn’t say anything at all about usage of sites which are specifically designed for mobile use. The conclusion I draw from this is that an iPhone user is much more likely to visit desktop sites than Windows Mobile or S60 users, and therefore non-iPhone users either mostly use sites designed for mobile, or don’t use the web much at all. This may have a variety of reasons — due to its large screen, desktop web sites are more usable on the iPhone than they are on devices with smaller screens; Safari Mobile has pretty neat zooming capabilities; and maybe iPhone users simply approach the device with a more web-oriented attitude, because after all it is more of an internet tablet than a phone.

If iPhone users actually prefer desktop-style websites, because they work quite nicely on the large screen, it really doesn’t make much sense to design a specific iPhone version of a site. On the other hand, if it’s that increased usability of the iPhone web experience which drives web usage per person to be many times higher than on S60 and Windows Mobile devices… then there’s a very strong case in favour of designing device-specific sites.

Is iPhone-specific design just a case of companies wanting to look cool by having an iPhone-optimised site and jumping on the bandwagon? Is this just a fashion which will go away again as quickly as it came? Or do such companies actually derive significant benefits from iPhone users? I’d be interested to hear your comments.

The mobile web is talked about a lot by people who have a vested interest in the mobile web becoming popular. The frequently-cited arguments in favour of web usage on mobile phones sound pretty convincing until you realise that most of those people talking so passionately about it have invested in the mobile web, and therefore may be stating their wishful thinking rather than an observed reality. (I am, unfortunately, no exception, being a mobile web developer myself.)

Mobile internet use has been hyped a lot — WAP has been around since the late nineties, and many people originally speculated on it being a huge success. Well, it never was in most parts of the world. It’s quite understandable that observers are now rather more cautious when it is announced that the mobile web is finally here, and that it is about to engulf the mainstream consumer.

In such an environment it is refreshing to hear the opinion of a neutral organisation who simply observes what is going on in the minds of consumers worldwide. Trendwatching.com produces well researched monthly briefings on the latest consumer trends worldwide. I have been following them for a while, wondering when the time would come that they would announce the mobile web as a major consumer trend. And now, in December 2007, the time has arrived. They announce in their predictions for 8 important consumer trends in 2008 (PDF):

“Five years ago, we introduced ONLINE OXYGEN as the engine behind all this excitement: control-craving consumers needing online access as much as they need oxygen. [...] If there’s one device that’s going to introduce another few hundred million people to the online world, it’s the phone. And yes, initiatives like Google’s Android and ‘their bidding on the 700MHz band’ and WiMax and so on are definitely going to speed things up. [...] don’t count on consumers’ insatiable demand to be online 24/7 to remain unmet forever.”

– Trendwatching.com, “Online Oxygen”

Although still a bit cautious in their wording, and emphasising that it won’t happen overnight, the trendwatchers have confirmed that the mobile web is not just a bubble. The signs are set for internet access anywhere, at any time, on almost any device, and it’s looking as though we won’t be able to imagine a world without it in a reasonably small number of years’ time.

But what is all that online access to be used for? E-commerce and social networking, say the trendwatchers. Social networking is a bit difficult to grasp, I think; it’s another one of those areas with a lot of hype and not necessarily much substance. E-commerce is a very important reality though, as yesterday’s article from Computing points out (UK online sales have risen by 29% since last year, reaching £130bn). And Trendwatching.com are convinced that this trend is going to continue:

“Sometimes, the Next Big Thing can be right under your nose. Consider the online riches to be reaped in 2008 from… ecommerce! Sure, it’s been around for years and years, but prepare for a forceful ’sequel’. After all, never before have so many consumers been willing to overcome security threats, still shockingly bad (or boring) design, and delivery screwups. In other words, 2008 could be a goldmine for smart e-tailers, who, if they get their act together, could make billions and billions of dollars, euros, pounds, yen, kroner, lira and rand that are impatiently waiting to be spent by web-savvy consumers around the world.

So in 2008, spend blood, sweat and tears on improving your ecommerce presence; the pay-off will be immediate, and far more substantial than investing in Web 2.0 me-toos!”

– Trendwatching.com, “Online Oxygen”

Consider that this market research organisation spends most of their time talking about brand psychology, status symbols, and the purchasing habits of particular sections of society. They are not technology-oriented in the least. And nevertheless they are announcing the coming of the ubiquitous internet, and its huge value for commerce. For me, this announcement marks the transition of the mobile web from hype to reality.

Of course, there are still a lot of problems to overcome — the top three are probably user experience, data traffic pricing, and handset market fragmentation. But if the consumer demand is there, these problems can all be sorted out. People are figuring out how to design engaging and usable mobile web sites and applications; flat rate data plans are becoming more common (in the UK at least); and fragmentation will mean that developing for the mobile web is a bit more expensive than it could be if everybody stuck to a standard, but it’s still an entirely surmountable issue.

With the economic force of e-commerce retailers pushing technology ahead, I am rather optimistic towards the mobile web.

Jimmy sent me some screenshots of Windows Vista which exemplify my complaints about unclear labelling of buttons — a usability problem which occurs so frequently that I’ve named this whole blog after it. He was running Windows Update, which was installing a bunch of software updates:

It turned out that he didn’t actually want to install those updates now, so he hit the “Stop installation” button. Up pops a dialog box:

Now what does this mean? Does continue mean “continue stopping the installation”, or does it mean “continue the installation”? If we press cancel, will this cancel the request to stop installing updates, or will it cancel the installation process itself? And what does the red X button in the corner do? (The temptation to press X in cases like this is huge: I consider it to mean “shut up, go away, I don’t want to think about what you are asking me”.)

But there is still hope: a “Details” button, which will surely reveal the answer and tell us what button to press. So we click “Details”:

Oh, that was really useful. You know, we love hexadecimal numbers. Thank you, Microsoft!

But Microsoft are not the only offenders in this regard. Barbara Ballard is having similar problems with OpenOffice.

For months there were rumors in the mobile industry that Google was going to launch a phone, until Google dispelled them with the announcement of the Android platform two weeks ago. What they are doing is basically to build an operating system for mobile devices (an alternative to Symbian and Windows Mobile), and to make it freely available. But why?

“So what is in it for Google? Why would it go to the expense of building and supporting a fully-fledged mobile OS and then give it away with very few restrictions on its usage? [...] Its [Google's] primary objective is simply to catalyse internet usage on mobile devices by ensuring as many as possible can support web services. Android is a means to an end. By doing some of the hard work on their behalf, Google is hoping it will encourage handset manufacturers and network operators to extend internet connectivity to more mobile users, more quickly.”

– Marek Pawlowski, PNM

Marek has got it spot on: discussions on the technical details of the platform really miss the point. It isn’t even particularly important whether Android will end up being installed on any significant percentage of devices. What is important is the signalling effect to the world: the mobile web is coming, the mobile web is a huge opportunity.

Most current mobile phones are not particularly strong on the mobile web front, whereas Android places its greatest emphasis on web-based services. That’s in Google’s interests, because it enables people to use Google’s web services while mobile, which continues to drive their advertising revenues. However, but it also benefits everybody else who wants to provide services on the mobile web.

Building a mobile OS is a very difficult and expensive job, but Google are willing to do it anyway, just to encourage the mobile web to develop a tiny bit faster. That shows just how important and huge the mobile web is going to be.

As a developer I am not particularly interested in Android. I’ve not even downloaded the SDK, because I don’t want to write applications — it’s just yet another platform besides the many ones already out there. What I am interested in is the web as a platform — Ajax, SVG and Flash enable most of the richness of traditional applications, but are much easier to develop, and more importantly, much easier to get out to users. No downloads, no installations and such nonsense — just immediate use.

So in a bizarre and twisted way, by adding another OS-level platform to the market (Android), Google are actually encouraging people to move away from both Android and the other mobile OSes, and to move towards the web as a platform. One could therefore argue that the purpose of Android is to make itself obsolete (hence the slightly provocative title of this post). But that doesn’t mean it’s bad — to the contrary, I am very supportive of Android for precisely the reasons explained above.

“Will Google end up capturing the lion’s share of the value in the mobile business by dominating mobile advertising?”

There is certainly a fair chance that Google will take a large chunk of the mobile advertising market. But let’s remember that although it has fuelled a lot of recent growth, advertising is not the only business model on the web! The business models which have worked fine for centuries — such as buying goods and selling them for a higher price — have not suddenly gone away. There is a lot more value in the mobile business if e-commerce is taken into consideration.

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.

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:

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

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:

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:

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:

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:

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:

• This website is not related to the web comic OK/Cancel although we’re talking similar subject matter.
• Windows Vista allows button relabelling (article and discussion by Raymond Chen).
• This article shows that Vista doesn’t actually use this relabelling, and contrasts different human interface guidelines.
• You might have noticed that the implicit relabelling example above is actually a case of Abort/Retry/Ignore. I first considered making that the name for this site, but fortunately Abort/Retry/Ignore is largely extinct by now (lucky you if you don’t know what I’m talking about). There is an excellent poem about Abort/Retry/Ignore though, inspired by E.A.Poe.