Andy Heydon

Category: General

In Defense of Walkthroughs



Max Rudberg recently published a post decrying the use of walkthroughs — an introductory series of panels — in an app. He cites Clear, Rise and Solar as “novelty apps” that sacrifice standard interactions for a minimal UI, and as a result have to pay a price of an multi-step tutorial to teach the user how to use the app.

I disagree with Max’s basic premise, I think that walkthroughs/introductions/demos have an important role to play. Clear, Rise, Solar and others should be commended for pushing UI design forward and experimenting with gestures. We are still very early in the era of touch based interfaces and so investigation should be encouraged. But because these gestures are new then there will there has to an some element of education somewhere along the line.

We forget, but touch based smartphones were new at one point in time, and the “basic” gestures were unfamiliar to every-one. But the genius of the Apple ads is they show the iPhone in use with hands and fingers interacting with the device (compare that to the vast majority of the Android ads that stress specifications). The ads were, and still are, an effective walkthrough and tutorial for every app. Without those ads every-one would seriously have to contemplate showing a walkthrough.

Rise Walkthrough


One of the challenges is selling software, and apps in particular, these days is that there is no real sales process. We browse on-line stores and in a single tap have purchased a product we’ve barely spent any time researching and understanding, and we definitely have not had a guided tour of the app’s compelling features. I suspect very few people read an app’s description — I know that I rarely do, especially if the description is loaded with “voted best …” quotes. A couple of pretty pictures and we’re sold, what’s a buck or two if it doesn’t work out? So as a software developer, our only chance of inserting ourselves into the sales process is in that very first launch. It is only then that we can thank the user for selecting the app and describe a few of the compelling features they might otherwise miss.

Consider a gym club. Once you’ve filled in the paperwork, some-one will show you around the facility pointing out particular items and explaining protocols. Most clubs have “standard” capabilities and I’m sure we could all muddle our way through eventually, but the club doesn’t want to take that chance. They want to ensure that you have the best possible experience and that you will come back. I recognize your app purchase may be on impulse, that there was perhaps very little research, therefore I’m going to take a small amount of your time to set you up for success.

Solar Walkthrough


I’ve never understand this macho “I don’t need no stinking documentation/training/tutorial” approach, and then get annoyed when it doesn’t do what I want it to do. Many years ago at a previous company, we had a customer who was adamant about not paying for any training or receiving any kind of assistance. Needless to say that he jumped straight in, completely missing a critical component of the setup, and proceeded to bad mouth us for crappy software. That product did not have a walkthrough or something to guide the user to the critical components first, nor did it have a non-standard UI, so we had a user flounder around for a bit, eventually dumping us for a competitor.

Many users are timid, they won’t explore or touch items they don’t undertand, many times they don’t even see an element on the screen even if it conforms to every standard practice in the interaction guidelines. The purpose of a walkthrough should be to encourage the user, to give them the sense of what is possible, to introduce unique features, to say that I care about their success. If that extra minute is what I have to pay to keep a successful customer then I’ll take it.


Google Doesn’t Understand Customer Service

Were the Mayans right? I hadn’t received any new email in Gmail since 2:09 on the afternoon of 12/12/12. Was this the beginning of the end?

I normally have a steady drip of messages into my personal inbox throughout the day, even more so in this holiday period as companies that I have a legitimate relationship with, advise me of their latest offers and free shipping deals. But there it was, on the evening of the 12th — absolute silence. The fact that I as expecting some important messages increased my tension.

Only after some manual refreshing did Gmail inform me that it was having problems retrieving my email, prompting me to dig deeper and eventually eliciting the rather terse message:

SSL Security Error.
Server returned error “SSL error: self signed certificate”

My personal email is hosted by a server that sits in the UK and is managed by my brother. I just use Gmail as a convenient client so that I am not tied to a particular desktop, the spam filtering is first rate without any manual training, and the messages are stored safely on a server. The error message would imply that our server was configured incorrectly and, given that early afternoon in Portland is late evening in the UK, a time when a brother would be making changes to a server, would imply that something had been messed up. I know he doesn’t use Gmail as a client, so he may not be aware of the problems he has caused. But could I raise his attention with texts? No I could not!

Well, Kevan, I hereby apologize for besmirching your good name in my thoughts. You were entirely blameless in this escapade. Through some digging, it appears that Google decided to change their procedures and enforce a strict SSL policy. They would now only connect to a server if it has a valid, signed SSL certificate. Any mail server using a self-signed certificate, which are a common occurrence amongst personally managed mail servers such as ours, would be refused.

As an aside, the error message “Server returned error”, is poorly written because it is not clear as to whose server we are talking about. It is not an error that our mail server is returning a self-signed certificate — that is a legitimate thing to do. The problem is that Google is not allowing such an activity. This is not an SSL error, it is a policy of not accepting certain kinds of configurations. The error message is just lazy engineer speak that fails to convey the correct issue.

Now I don’t disagree with the policy change as it helps to protect from man-in-the-middle attacks, but I do condemn the implementation of the change, and it demonstrates that Google is an engineering company and doesn’t understand customer service.

In any production system, if you are going to introduce a change that a) will disrupt the service, or b) force the customer to perform an action, or c) cause the customer to pay some money, then you need to proactively communicate that change. Google, with this SSL policy enforcement, hit that trifecta and absolutely should have told everyone of the change.

The solution to the problem is for us to purchase an SSL certificate from a reputable authority. No big deal, except that this takes time because our identity has to be verified, except that it costs money, and we have no access to email during the transition. I had to hurriedly configure a desktop email client that I could authorize to overlook a self-signed certificate, but this will be a temporary crutch until we can install a signed certificate, and is something that I shouldn’t have to do. From Google’s perspective that is tempting trouble because I might like the new system and give up on Gmail altogether. Clearly the policy change was not fully thought through.

It would have been trivial for Google to determine all the accounts that fetched email from a remote server and verified which of those servers had a self-signed certificate. It should have then sent those accounts an email with the details, reasons and implications of the upcoming change, along with a timeline for its implementation. In this particular case, because it requires the purchase of an SSL certificate, there should have been at least a week’s notice. You cannot just pull the plug on a service if the solution requires a significant time to implement. It shows a total lack of respect for your customers and their needs.

The Android Engagement Paradox

Horace Dediu over at Asymco has an interesting post today about IBM’s Digital Analytics Benchmark on US Black Friday sales, particularly the traffic generated by the mobile sector. With regards to tablets, the iPad is absolutely dominating it’s class, which is not a real surprise and not worth talking about. But when you consider phones, where US Android sales are up in absolute terms over the iPhone, the survey reports that it is the iPhone that is being used far more for online shopping. Horace goes on the review previous years and this trend is actually increasing — the proportion of iPhone usage to Android usage has increased from 2-to-1 in 2010 to 3-to-1 this year.

So the question is this, if the numbers of Android phones out there are increasing, why is their usage seemingly falling?

This engagement issue is an important one for app developers because we need to know where to concentrate our scarce development time and dollars. If a platform has limited coverage or a poor usage profile, then we don’t really want to put any effort into it. This study of online shopping is interesting because it involves a core function of web browsing, a major tenant of a smartphone. Dediu didn’t really offer any reasons for the disparity, other than to point out that because the installed base of each type of phone is so large then differences in demographics probably are not be a factor, but I can suggest a few reasons.

It would appear that Android users don’t realize that they have a web browser in their pocket. Maybe they purchased an Android phone when their contract was up and because smartphones are what the carriers push then that is what they buy. But in the process they are never sold on what a smartphone is and can do. They just want to call and text people, and seeing the latest weather forecast flash by on the screen is a piece of superficial smartness.

There are a lot of old devices out there, and with the very spotty history of operating systems upgrades there are a lot of Android devices running “very old” (in web years) versions. Those older versions had a very poor browser, making surfing the web an unpleasant experience; who wants to suffer through that in the heat of the battle on Black Friday? In contrast, Apple offers upgrades for a very large proportion of their devices (is there any-one still using a iPhone or iPhone 3G?) and users do upgrade, so they have the support for the latest web technology.

The iPhone UI is often criticized for being simple — a basic grid of icons spread across several side-scrollable pages, whereas Android has a more complex model of widgets, home pages and app drawers all arguing for our attention. There is just a lot more going on with the Android UI and I think people get overwhelmed by that complexity, so they learn a couple of things and give up on the rest. Complexity is one of the most difficult for we IT professionals to comprehend. We spend our lives using computing devices and have no fear of them, we use 4 key combinations to perform personalized actions, we remember rafts of options to bizarrely named command line operations, we intuitively soak up new user interfaces, but I’ve seen users stumped at pressing a button when there are only three choices on the screen. We regularly over-estimate what is complex and what is simple.

The seemingly shrinking engagement of Android users is troubling for app developers looking to target that market. People are not being tempted to use the browser, a function that is front and center of a smartphone’s existence. They are not motivated to shop, via phone, on Black Friday — the very peak of US shopping tradition. Google is intently interested in steering people to the browser and their cash engines of search and advertising. But if web surfing is failing to gain traction, if people are not using their smartphones as smartphones, then what chance does an independent app have of succeeding?

Hello world!

So why in the age of microblogging, am I creating a blog? Aren’t those so passé these days? Well maybe, but I believe there is still a lot of life left in the long form. One hundred and forty characters is great for a witty observation or quick retort, but to build a cogent argument and defend it, the larger medium is necessary.

So I going to use this blog to develop larger ideas, to do a little bit of self-promotion, and to give back to the development community. I have read countless articles in the quest of solving some problem, but I have never had the capability of returning the favor until now. It is unlikely that I’ll be blogging on some of the technology I used to use because I have now moved on to different pastures, but there will still plenty to talk about, and I have a few new tricks up my sleeve. The tech industry is nothing if not constantly changing. I think the military has the term “target rich environment”.

So thank-you for popping in, and I hope you return soon.