Over Christmas I finally had time to read The Four Steps to the Epiphany by Steve Blank. I had heard from a few people that it was the best book in the world for startups, but of course you take that sort of recommendation with a grain of salt. When I finally got round to ordering it, my first impression was not very impressed. The graphics are misaligned, the typography is ugly, there are plenty of typos, the cover picture is cheesy, the CafePress binding is flimsy. All in all, not a good start.

Well, don’t judge this book by its cover. Despite those apparent flaws, it is absolutely brilliant. And yes, if you have any sort of startup ambitions, you should go out and read it immediately.

In fact, maybe the book is deliberately ‘unprofessional’, because that would be consistent with a theme which runs through the entire book: focus relentlessly on what really matters and what really adds value. What really matters to me with Steve Blank’s book is purely its content (which is clearly articulated and deeply insightful); professional design or editing wouldn’t have changed this book’s value to me. Similarly, what really matters with a startup is to discover and learn what customers need, how the product fits into their lives, and how you are going to get it into their hands. ‘Professionally’ executing a strategy comes later. First you’ve got to learn and discover what the strategy is going to be.

This sounds trivially obvious, but it is not.

Let me digress for a minute. Something else I read recently is The Fable of the User-Centred Designer by David Travis (a short but beautifully written eBook — well worth reading but quite different from the Four Steps to the Epiphany). It made me realise how badly we had gone wrong with Go Test It. Steve Blank’s book further strengthened that feeling. Ok, we built a product which works alright. We did a few informal usability tests (looking over people’s shoulder while they use it for the first time) and we got some useful feedback from the beta tests. And clearly the result was promising enough that Red Gate wanted to acquire it.

Here is my confession: I cannot truthfully say that we really engaged customers in the process. I had some ideas about use cases and I did a few pencil sketches of the user interface before it was implemented. But did I actually go out to potential customers and test my ideas on them? Not a single bit! We thought about the ideas for a few minutes by ourselves, nodded our heads, and then just went ahead and hacked it together.

I have no excuse whatsoever for ignoring our customers like I did. Hell, we even had a poster from the Usability Professionals’ Association hanging in our office for a while, detailing the steps of a user-centred design process. (Some years ago I thought our company was going to be a usability consultancy — that was before we got into web development and ultimately into building Go Test It. Hahaha! By the way, that’s why this blog is called Yes/No/Cancel.) And nevertheless I totally ignored it. We were not doing anything like user-centred design, let alone Customer Development as proposed by Steve Blank, which is a lot further-reaching.

The only thing which saved us was that I was basically building a product to solve my own problem. I had worked on a big, JavaScript-intensive web app project, and had felt the pain of getting it to work in different versions of IE. So I had an idea of the kind of tool I had wanted to make that project less painful.

So: building something which scratches your own itch is better than building something which you don’t even need yourself. But it’s still a pretty bad starting point, because you are only one data point. How do you know that you’re not an outlier? In our case, I was even a pretty bad data point. I had only worked on two significant commercial web app projects — not exactly a great deal of experience. I had never worked in a proper web agency, or a larger software company, or an established e-commerce retailer, or in fact any company which looked remotely like the type of company we’re trying to sign up as customers.

What we should have done — and I understand this now — is to follow a Customer Development route from the start, alongside building our product. Before the coding started, I should have at least made my hypotheses explicit, tested them on my target market, and refined the product idea. Basically, I should have read The Four Steps to the Epiphany a year ago and then followed it.

In my defence, it’s difficult when you are a sole founder. In principle you could multitask between Customer Development and Product Development, but I think the two activities require very different mindsets, and the context switching overhead between the activities is huge. Therefore I suspect that a sole founder doing both will take much more than twice as long compared to two cofounders who specialise in Customer Development and Product Development respectively. Hence it’s extremely tempting for a technical founder like me to pretend that the Customer Development side doesn’t exist, and focus exclusively on the product.

Well, late insight is better than never. Amir is joining me on the Customer Development side of Go Test It, and we have a lot of catching-up to do. In 2010 there will be soul-searching and maybe some changes of plans, but I am really looking forward to it, because I am confident that we can figure out how to turn Go Test It from something ok into a product which you simply must have.

A lot of things fall under i18n, such as correct handling of character sets (not everybody uses the Latin alphabet), time zones (not everybody uses PST or GMT), numbers (not everybody uses the dot as decimal separator), currencies (there is a world outside the US dollar), writing direction (not everybody writes from left to right) and of course translation into different languages. Traditionally, i18n has been an issue which software engineers have loved to ignore, because (a) it’s difficult, (b) it’s not cool, and (c) if you’re in North America, you can find enough customers in North America for the first few years, so there isn’t a strong business requirement to work internationally.

Now that we have the web, and people from many different languages and cultures interacting on the web, getting internationalisation right is absolutely essential. And it’s getting better — I think most developers now appreciate that you’ve got to use Unicode, that you’ve got to store dates and times with timezones, that you need to make text translatable. Ok, at least that’s something. But I think that soon we will get to a point where the traditional approach to translating applications breaks down.

Let me explain.

The way software engineers usually make their applications work in multiple languages is to mark every human-readable bit of text in the program in some particular way, to extract those bits of text, give them to a translation bureau, and get back an equivalent set of texts to substitute in-place. The result should hopefully be that the application appears entirely in a new language.

Even this simple form of translation isn’t working everywhere. For example, if you update your Twitter status in a German web browser, it says that you updated ”weniger als 5 Sekunden ago”. Here “ago” is an English word, but the rest is German; to a German-speaker, this reads like “vor less than 5 seconds” reads to an English-speaker. This is simply a case of some of those bits of text getting forgotten; not a big problem, and I’m sure they will fix it soon, but enough to make German-speakers uncomfortable using the application because it’s constantly offending against their sense of language.

However, things get harder once you start building sentences based on variables which may change. The Twitter message is a simple example of this: the time is a variable, and because it’s in the past (not in the future), we need to stick “ago” on the end, in English at least. The code which does this will look something like this:

1
2

time_in_words = distance_of_time_in_words(time_of_last_update, Time.now)
time_in_words = "#{time_in_words} ago" if (time_of_last_update < Time.now)

To translate this program, make sure that the function distance_of_time_in_words returns words in the right language (e.g. for German, “weniger als 5 Sekunden” — Twitter does this correctly), and replace "#{time_in_words} ago" with the right grammatical construction for the target language (e.g. for German, "vor #{time_in_words}" — this is the bit Twitter has missed out).

The way we use time_in_words as a variable we can insert words before or after it to make the right grammatical construction. Fairly flexible, but is this enough?

Over the past few days I have been developing a Facebook application. It’s not even internationalised, it’s just plain English, but nevertheless I have come across a problem of grammatical constructions. Take for example a message in the news feed, which might look different depending on who looks at it:

• Mike has given John a pat on the shoulder because he has done well. (seen by a bystander)
• Mike has given you a pat on the shoulder because you have done well. (seen by John)
• You have given John a pat on the shoulder because he has done well. (seen by Mike)

First of all, note that the subject (Mike) and object (John) can be either a name, or ‘you’. Facebook offers the facility to do this using the <fb:name> tag; as developers, we are even given the opportunity to say whether we want the “you” to start with a capital letter (depending on whether it occurs at the beginning or in the middle of the sentence). Next, we use a pronoun — “because he has done well”. This depends on the gender of John, but we know from his profile that he is male, so it has to be “he” not “she”. Facebook does this using the <fb:pronoun> tag.

So far, so good. Now note that the verb form changes between second and third person (have/has). There is no way in Facebook to do this (it was requested more than a year ago but still hasn’t happened). In case you ever wondered why the Facebook news feed is always in the simple past but never in present perfect — that’s because in English, the verb forms for second and third person are the same in simple past, which is not the case in other tenses! (In “You threw a banana at Bob” and “Alice threw a banana at you”, the verb is “threw” in both cases; in “You have thrown a banana at Bob” and “Alice has thrown a banana at you”, the verb forms “have thrown” and “has thrown” are not the same.)

The part “a pat on the shoulder” stays the same in all sentences, but that’s just because English happens to work that way — in other languages or cultures, it may have to be modified depending on e.g. the gender or even the age of the people involved. Or the verb (have/has given) may have to change depending on some parameter of the direct object (‘a pat on the shoulder’). There may be languages in which the name of a person changes if it is used as an indirect object. And so on.

You can get up to a certain point by duplicating text, e.g. providing a separate snippet of text for each possible combination of values which may occur; then translators can deal with each individually, and ensure that it is correct. But very quickly you get into a situation where the number of combinations is so large that this approach just doesn’t scale.

The bottom line is that in general you can’t build a grammatically correct sentence by just sticking words together, even if you make the word order variable. In languages with declension and other grammatical changes to words, or languages where the word order changes depending on some variable, or languages with separable verbs… well, I don’t know what happens then. It’s an unsolved problem.

(There is another subtle point here, which is that cultural differences may mean that even if you translate something in a grammatically correct way, it may have the wrong connotations in the reader’s culture; for instance, consider a culture in which patting on the shoulder is considered offensive. But in such cases, it could be replaced with another gesture which has the desired meaning. I will just concentrate on the grammatical level for now.)

The only step I’ve seen so far towards making internationalisable grammar is the ‘pluralize‘ function which you find in some frameworks such as Rails. It takes a number (such as 0, 1, 2, 29 or 518514) and a singular noun (such as ‘camel’) and returns the text in the appropriate singular or plural form (e.g. “29 camels”) — and it works in a wide selection of languages (e.g. in German, pluralize(29, ‘Kamel’) = ’29 Kamele’).

To illustrate the problem, here is one of the source files from Bid for Wine. It is a very minor feature — it just creates a short paragraph of text explaining the purpose of a particular form which a buyer needs to fill in. However, there can be a lot of different things in that form, depending on the type of auction. This generated text gets sent out by email (to both the seller and the buyer) and is also displayed on the website, and few people will ever notice how much effort has gone into building that paragraph of text.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

case grammatical_person
    when 2
        you_or_they = 'you'
        your_or_their = 'your'
        you_or_them = 'you'
        yourself_or_themselves = 'yourself'
    when 3
        you_or_they = 'they'
        your_or_their = 'their'
        you_or_them = 'them'
        yourself_or_themselves = 'themselves'
end
 
things_to_do = []
 
things_to_do < < "specify whether #{you_or_they} would like to keep #{your_or_their} " + \
    "wine in bond" if auction.lot.in_bond
if auction.is_consignment_auction?
    things_to_do << "choose if #{you_or_they} would like to have the wine shipped to " + \
        "#{you_or_them} or rather pick it up from the warehouse"
elsif auction.lot.can_be_collected && auction.lot.can_be_shipped
    things_to_do << "choose if #{you_or_they} would like to have the wine shipped to " + \
        "#{you_or_them} or rather collect it #{yourself_or_themselves}"
elsif auction.lot.can_be_collected
    things_to_do << "confirm collection of the wine"
else
    things_to_do << "specify where #{you_or_they} would like the wine to be delivered"
end
 
things_to_do << "provide a billing address"
 
if things_to_do.length >= 2
    last_thing = things_to_do.pop
    last_but_one = things_to_do.pop
    things_to_do.push "#{last_but_one}, and #{last_thing}" # Oxford comma
end
 
"On this form #{you_or_they} can #{things_to_do.join(', ')}."

And you thought English was simple? You can even even see the remains of grammatical cases (you_or_they vs. you_or_them). If this needs to be translated one day, we will need to duplicate the logic and mess about with the way variables are inserted into the snippets of text to make the grammar work. It will be horrible to maintain. But that's the best we can do with the state of the art. Shouldn't there be a better way?

I don’t want to describe it there. Just watch it (it’s a short movie), it’s really worth it. And think about that next time you are designing a web site.

I looked at it like someone from a different planet. I hadn’t touched a phone book in years! Why on earth would somebody still want one?

My friends all have mobile phones, not landlines; and I have their numbers stored in my phone anyway, so I don’t need to look them up. For business contacts I have their business cards, which I store in a contact management database, which is also easily searchable. And if for some reason I don’t have somebody’s number, I would look it up in an online phone book which contains all people in the whole of the UK, not just Cambridge.

When I have children, they will probably fail to grasp why anybody could have possibly wanted a big heavy book with their neighbours’ phone numbers. And I will feel like someone from the middle ages because I still remember using them (back in the day when it took 2 minutes to connect to the internet by modem, so it was actually faster to use the paper phonebook). And hey, I’m 24 — how are my parents’ generation going to feel?

But then, take a step back. Why are they still distributing paper phone books for free? Because there are still many, many people who do not have internet access. Many millions in the UK — and outside the industrialised world it’s the vast majority of people. That online oxygen which I take so completely for granted, it’s not actually as omnipresent as I would like to think.

The internet has completely changed the world, I can hardly repeat it often enough — it is the same kind of massive shake-up as the industrial revolution or the invention of the printing press. But we who are involved in making that technology must not forget about those people who lack internet access. There is a divide between those who are part of the communication and democratisation which the internet is bringing, and those who are “digitally excluded”. We must not forget them, and we must do our best to get everybody online, anywhere on the planet, by making technology accessible, usable, and affordable.

Someone put a lot of money, time and effort into printing that phone book. Although it probably didn’t require a tree to be felled, it has still consumed a lot of recycled paper. I would have felt bad to put it in the recycling immediately, even though I know that we are never going to use it. So I stripped off the plastic wrapper and placed the book carefully in the drawer under the living room table. Last year’s phone book was there too, just as unused. At least now, the two phone books can keep each other company.

Despite these changes, plenty of usability challenges remain. For example, my friend told me that he didn’t realise when using the machine when he had reached the payment screen: he could have just inserted his card, but instead found himself looking around for the “next” button to press. There was just some small and non-obvious bit of text on screen explaining that you were now ready to pay.

In fact the usability problems of German train ticket machines are still so pronounced that the national rail company (DB) is now offering courses to teach people how to use them. (See the scanned newspaper article, taken from Aalener Nachrichten/Schwäbische Zeitung, Tuesday 18th December 2007. Sorry that it’s more than a month old, I’ve not had much time to blog recently.)

This article is somehow slightly scary and hilarious at the same time, in the way how the train staff systematically blame the users for their inability to use the system, rather than seeking the blame with the system itself. Hilarious because it’s so stereotypical, and scary because such a big organisation can get away with it without people putting up a fuss and explaining that this is just not acceptable.

Some highlights from the article:

Moschner [the course instructor] says that the new ticket machines have a more visible display and also accept cash besides credit and debit cards. “Are they just as cumbersome as the old ones?” an over-70-year-old lady enquires. The course instructor remains calm: “They are not cumbersome.”

Hmm. Complete denial of the existence of problems. Two more quotes indicate that there is a fundamental misunderstanding of user behaviour going on:

“Read what it says there. It is important.”

“The ticket machine really does tell you what it wants, you just have to look.”

Why should I be trying to find out what the ticket machine wants? It should be trying to find out what I want! Also, I shouldn’t have to read every word on the screen. That’s simply not what people do. People don’t even read whether doors are labelled ‘PUSH’ or ‘PULL’ before trying one or the other. People just press random buttons in the hope of getting somewhere quickly, and the system should be designed to cope with this sort of behaviour. Anything else is just unrealistic and designed for robots rather than humans.

Fortunately this course is a positive initiative, probably with a thought along the lines of “well, if we can’t get the design right, at least we can teach people how to use the broken design”. I guess that’s a valid approach to the problem. And hey, 8 people turned up to that course, maybe that’s 8 fewer people who get frustrated with the machines. Sounds a bit like a drop in an ocean to me though.

Amusing though the exercise is, it proves once again how hard it can be to practise what you preach. The Bad Usability Calendar website, although apparently designed by usability experts, doesn’t actually work. I was going to enter their prize draw for an Amazon voucher, for which a required step is to provide your address. This address appears to be used to look up your longitude and latitude, so that they can plot a little pin on a map. I tried four or five variations of my UK address, but unfortunately none of them was accepted by the site. It failed with a badly written error message which gave me no clear indication as to how I would have to construct the address so that it would be accepted. Well, I would have even been perfectly happy to find Cambridge on the map myself and stick a virtual pin into it, but no, that wasn’t a foreseen option. Moreover, the option for uploading a photo didn’t appear to work either — and there wasn’t any error message at all, just no picture. So unfortunately I was excluded from the prize draw.

At least I’m glad to see that nobody else from the UK has managed to place a pin yet. You know, bad usability always makes you feel stupid (even if it’s clearly somebody else’s fault, not your own), so it’s a bit of a consolation that nobody else has figured out how to make the site accept a UK address. Now I am wondering whether something like that could be incorporated into other products. Some means by which users can see that they are not the only ones who are grappling with a dysfunctional product, maybe by social network or something like that. Not that it makes the product any better; it just makes its users feel slightly better.

Edit (29 January 2008): Meanwhile the issue has been sorted out and we have been placed on the map manually. The address search also seems to be working now, and we’ve even been joined by another UK pin in London. Netlife handled the matter very quickly and nicely — thanks!

1. site load time
2. site navigation
3. user friendliness

While I’m not quite sure what they mean with “user friendliness” — it’s a kind of compound term for all sorts of factors which contribute towards the user experience — the other two, load time and navigation, are very clear areas which need to be addressed if the mobile web wants to move forward.

Site load time is a tricky problem to address, because slowness is mainly due to packet round-trip times on mobile data services. I see Ajax and Flash to be the most promising approaches to beat the network latency — i.e. transferring more data up front in order to make the site more responsive once it’s loaded. Site navigation is mainly a question of information architects figuring out how to present information most effectively on a mobile, and there are already some very good examples of good mobile navigation design on the net.

If you’re interested, you can download the white paper (PDF, 124 kB). Here’s the abstract:

The use of internet and web services on mobile devices is expected to revolutionise our attitude to information and communication in the near future. However, in order to attract mainstream adoption, the mobile web must overcome some fundamental user experience problems. In this white paper we approach the user experience from a technical point of view, explaining reasons for deficiencies of the current approaches, and introduce some technical means for improving the user experience.

“It is interesting why so few of us use one of the breakthroughs of recent years: the ability to search the web from wherever we are with a mobile phone. This ought to be hugely empowering, enabling us to answer any question from wherever we happen to be instead of having to wait until we are within reach of a computer.”

…as also the main reasons for its slow start:

“There are a number of reasons why this hasn’t happened and why it may be about to change. It is partly because the operators have been shamefully greedy in trying to raid our pockets by charging for all the data we download [...] the user experience is still not good enough. Mobiles were designed to make telephone calls. Now things are changing.”

– Victor Keegan, “The mobile web is finally getting started”

I recently came across some great examples demonstrating why for complex web sites, there is no alternative to designing a specifically mobile version. This is not so much for technical reasons, as rather that mobile users may have totally different requirements. It’s not so important to be able to access every single bit of content; instead those things which mobile users do require need to be instantly accessible. After all, think why a user may want to use the mobile web rather than the desktop web: it’s very much tied to now, an instantaneous requirement. In the words of Sarah Lipman, from an interesting paper on mobile search paradigms:

“‘Mobile Search’ = I want it NOW. I can’t wait, I won’t wait.

When a user gets the sense that ‘I’m not going to find what I want right now’ he stops looking, because that is almost always the path of least resistance. At the same time, he will also have a small sense of failure. [...] If search cannot deliver on the promise of ‘I want it NOW’, it won’t be utilized.”

– Sarah Lipman, “Search patterns in nature: Informing computer search interfaces”

For mobile users it is even more important than for normal web users that the designer has figured out exactly what the most frequently needed aspects of his site are, and made those aspects immediately and very easily accessible. This means that a mobile page can contain far fewer navigational elements (links) than a page intended for desktop viewing. Going from desktop to mobile therefore involves prioritising links in a page — some of them are going to have to go (moved into a sub-page, or removed entirely). This is not something which software can do automatically — a human editor or information architect has to sit down and decide.

Two examples to clarify:

• Nigel Choi and Luca Passani have produced an impressive example contrasting the mobile-specifically designed version of the Wall Street Journal with its desktop version when automatically adapted for mobile use. (The purpose of the article is actually to criticise Vodafone UK’s approach to content adaptation, but it serves very well as a general example of the limitations of automatic adaptation versus manual redesign.) The mobile-designed version even goes as far as offering all content without requiring login (as opposed to the desktop version, a lot of which is subscription-only access), because WSJ recognise that people don’t like typing in user names and passwords on a phone keypad! Go to the article.
• The BBC News website comes in at least four different versions: a desktop version, a PDA version, a XHTML phone version and a WAP version. Simply comparing the structure of the news front page in each version gives a very insightful comparison. When I last checked, the front page of the desktop version contained 201 links; the PDA version contained 56 links; and the phone/WAP version contained 24 links. Same site, but different prioritisation of content. That’s the way it should be.

Blue Flavor has also produced a presentation on the basics of good mobile web design.

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.