NB: This is a viewpoint from Anshuman Bapna, CEO and co-founder of mygola, a trip planning portal.
As a founder who has always thought web-first, building an app for mygola was always going to require a mindset change. When we wanted to figure out what the user experience on mobile and tablet devices should be, we did a lot of soul-searching.
As a travel planning startup, we’ve always thought that travel and mobile should be long-lost twins. And while one may like to think of big online travel companies as stodgy, the dominant players actually have some really sharp, aggressive executives at the top – Kaufer@Tripadvisor, Boyd@Priceline, Hafner@Kayak etc.
So when the mobile wave hit, their apps were pretty good very quickly. But if you ignore bookings, there’s hardly a single compelling travel planning experience on mobile right now.
To understand where we should head, we asked ourselves these questions along the way.
Desktop? Tablet? or Mobile?
Our conundrum was that despite all the hoopla about mobile, data showed that people continue to do the vast majority of their travel planning on a laptop.
We did know that mobile was good for activity in short bursts. And that people routinely expect to be able to see/sync their plans across devices.
But what mobile experience does that translate into? Or was it more natural to expect people to use mobile when they were at the destination, instead of when doing pre-trip planning? We weren’t completely sure.
On the other hand, we always thought that travel planning should be a lean-back, sit-with-your-partner-on-the-sofa, browse-a-magazine kind of an experience. That screamed tablets, not mobile phones.
So to begin with, we decided to ignore mobile.
Tablet-friendly website or an app?
We decided to focus on building a robust and attractive website that felt like a web app for tablets. That meant obvious things like making all actions touch-sensitive, but also less obvious ones like ensuring every important action could be reached by the thumb and every clickable object allowed “fat fingers”.
It increased our web development time marginally but paid off quickly. Tablet users to our site started spending 20% more time than desktop ones.
We have had good success with organic traffic and this let us use traditional means to get tablet traffic instead of playing the Russian roulette that the app stores often felt like to the uninitiated. We knew web development quite well and it helped to iterate much faster.
A native app or PhoneGap
Few weeks later, mygola website experience had begun to stabilise. Then, it was time to consider an app. Funnily enough, we thought of it as a growth hack first and foremost. We heard through the grapevine that traffic acquisition was potentially cheap on tablet devices.
Below quote is from an answer in Quora:
“Its easier to drive traffic from the web to mobile web and cheaper to buy ads/users on the web. You can prove out your mobile use case here, build up an audience, and when you do introduce a native app drive tons of existing users to it all at once, propelling it up the charts and exposing it to new users. Since most apps get a trickle of new users and get lost in the app stores, this is huge.”
At the very least, it was a massive distribution channel that we had to get to grips with. At this stage we were presented with a head-scratcher: Should we go native and build an app from the ground up? Or should we package our tablet-friendly site as an app?
Advantages of going the native way
- A native app gives access to interesting device capabilities. While we weren’t planning to use any of them right away (things like hardware acceleration, gyro, etc), three of them did seem quite enticing for us. Namely, notifications, offline access and in-app purchases.
- It just seemed the bar for user experience was too high for anything but native apps to meet them. We heard this from a well-regarded investor ,
“I am not sure of using an app as a wrapper for a mobile web page (or as a bookmark/short cut). While the tech certainly supports it – I have seen some very nifty apps using HTML5 – the user’s expectation of an app UX is very different from a mobile web UX. It will take some extraordinary UX gymnastics to make a web page also work as an app”.
On the other hand, the guys over at Pivotal Labs said:
“I would have to disagree with the answerers who suggest that you can create a better UX with native apps than with HTML period. Check out The Bold Italic app for the iPad, which we (Pivotal Labs) built as a thin native wrapper around an HTML app. Ask yourself whether you’d have known this wasn’t native.”
Disadvantages of native approach
- We still didn’t understand what the “natural” behaviour on tablets was. Building an app first and then doing experiments to discover seemed like an expensive way of discovery.
- OS fragmentation. When iOS was 90%+ of the addressable market this decision was much easier. Projections for 2011 put Android and iOS in the 30% each range, with 30%+ other. This makes picking a native platform painful and leaves you very open to competitors taking market share. HTML is everywhere. Something like PhoneGap would allow us to launch for Android within a few days of the iPad.
A polished UI is a big deal in the app world, even if the functionality is very simple. Threads on Quora make it sound like more than 50% of the work is in polishing the UI.
We didn’t think that sounded like a rapid release-iterate cycle, and this ultimately turned out to be what tipped the scale.
PhoneGap or Titanium?
We needed some things beyond just packaging the website as an app. This included things like:
- The ability to open URLs within the app by spawning a child browser
- Keeping the user session alive is challenging in web view, so we had to build a hybrid approach where login/signup happens on the app but subsequent experience is in web view.
- Changes to Google Analytics that allowed us to distinguish our iPad app users from our iPad website users
In the end, PhoneGap just had more active forums and a more responsive community than Titanium, and we went with them.
It’s time to launch the app
On a friend’s recommendation, we used Appannie and Appcod to do competitive analysis of similar apps on the app store. There was some useful information on how to choose title and keywords for the app, but overall, it felt like we were back in the Wild West days of SEO black hat machinations!
Before we submitted the app for review, we wanted random users to download the app and try it out. We have used UserTesting in the past but the challenge was to give access to their testers to an unpublished app.
We tried using TestFlight and Hockeyapp but got stymied by UserTesting’s need to have an “enterprise” plan, and provisioning of profiles felt just too complicated.
So we bit the bullet and submitted the app without it. The app was approved within two weeks and we immediately paid five testers on UserTesting to download the app and give us a video review. We got three perfect 10s, one 8/10 and one 3/10 (speed was the main issue).
Being in the top downloads list for your category is the ultimate goal of any marketing plan, and we did the usual stuff – notify our existing user base, friends and family, our fans on Facebook, followers on Twitter etc.
We had a ready list of app reviewers we would reach out to. Of the 20 reviewers we reached out to, four responded, with each of them asking for a payment to review the app (SEO black hat anyone?).
We decided we didn’t want to do that. We might consider using Inmobi or Tapjoy to advertise the app though.
So, what’s next?
It’s been two days since we went live, and we have had less than 100 installs so far. Honestly, that’s truly pathetic 
But it’s a start, and we’re rapidly learning a lot.
NB: This is a viewpoint from Anshuman Bapna, CEO and co-founder of mygola, a trip planning portal.
