Safari To Go: how not to build an iPad app

I really like Safari Books Online. As one colleague put it, it’s “the gift of unlimited knowledge“. For those who aren’t familiar, Safari is an online subscription-based book service. You pay a monthly fee to get access to a boat load of technology, business, finance, and other books. These books are only available in electronic form and you need a browser to read them. The selection, at least for a software geek, is superb. I found basically every book I wanted to read, and in some cases got access to draft versions still in development. How awesome is that?

On November 4th 2010, Safari released an iPad app called Safari To Go to much fanfare. 4 days later, in response to an avalanche of bad reviews, Safari announced that they’ll be concentrating on fixing reported issues before introducing new features. Finally, 20 days after the release, they decided to pull the plug on the app.

What happened?

In my opinion, two things doomed this app:

1. Not understanding the needs of your customer

I don’t know what Safari considered to be the most important feature of their iPad app, but I know what I would consider most important: it had to provide a reading experience worthy of an iPad. More specifically, it had to be significantly better than using the browser since that option was already available though their mobile site.

Unlike a PC which has no better alternatives to reading in the browser, iPad has a small army of amazing apps beautifully optimized for reading (iBooks, Instapaper, Flipboard, Kindle, The Feed, Pulse, etc) and the bar for a new reading iPad app is set quite high. Any app that doesn’t measure up will be met with user outrage even if those same users are perfectly content reading in the browser on their PCs. Frame of reference can be a tricky thing that way.

Sadly, Safari To Go’s reading experience was awkward to the point of being painful. You couldn’t zoom in without pixelating, couldn’t change text size, flipping pages was unreliable, etc. On top of that, the process of saving the book for offline reading was almost comically unintuitive and buggy. Actually, based on some comments in the online forums, I suspect that the offline reading feature was added later. If true, this is remarkable. I really can’t understand how Safari went about prioritizing the product backlog for this app.

Speaking of offline reading, arguably the worst aspect of Safari To Go was how it actually let you read books offline. Even if you have downloaded the book to your iPad, the app would still try to access the internet (and slow down the reading process along the way) unless your iPad was in airplane mode! Yes, if your wireless is turned on, you will have to endure the pain of 2-3 second refreshes for each page even if the book is stored locally!
You shouldn’t be only looking at the cost of one’s essence and blood, which will weakens one’s spirit and memory; it will have a bad effect on sexual life in future. order generic cialis visit my pharmacy Furthermore, the active ingredient of Dandelion boosts immunity by increasing the blood supply to the penile region. order tadalafil online In the modern commercial world where the term ‘Googling’ has replaced levitra 20 mg ‘searching the Internet’ the search engines are familiar with most methods used to ‘trick’ people into visiting sites. An important part of link building is to create prescription cialis on line sure that you are healthier.
The most amazing thing about this “feature” is why they decided to implement it in such an odd way. According to Safari, they did this because they didn’t finish implementing bookmarks and notes features within the app. That’s right. They consciously decided to create a ridiculous user experience because they didn’t finish implementing two features most users couldn’t care less about. Amazing.

2. Bad technical choices

Soon after the app was released, it emerged that Safari didn’t implement it as a native app. Instead of building a proper Objective-C app that’s able to fully leverage iPad APIs, they used a cross-platform web framework called PhoneGap. The reason, of course, is so they could support other mobile platforms in the future.

Now, Safari is certainly not the first company to be faced with a difficult choice of dedicating resources to build platform specific apps. And on some level it’s hard to blame them for trying to minimize development costs. On the other hand, Apple sold over 7 million iPads in 2010. It’s everywhere and spreading. Yes, there are Android and Windows tablets gathering steam, but those platforms aren’t there yet.

It’s not like Safari has to guess which platform will succeed, at least in the short to medium run. At some point, a given platform becomes compelling enough to warrant dedicated resources and in the world of tablets iPad is that platform. Not doing a native app for it was a bad technical choice driven by questionable business decisions.

Final Thought

There was one other interesting aspect to this whole episode. Safari has a very large number of very technical subscribers (not surprising given the types of books they offer). As it turns out, these users have a heightened appreciation for quality software and a distinct lack of shyness in publicly expressing their dissatisfaction. In other words, when your target demo is geeks with iPads, don’t even think about releasing half-baked crap. The negative publicity is just not worth it.

You may also like:

• Devs Say the Darndest Things
• Designers vs. Bootstrap
• Management Anti-Patterns on Product Teams
• Are Single Page Apps Bad?
• Podio: Custom Business Processes Done Right

• design
• development
• fail
• iPad
• usability

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!