March 8th, 2011 by John Reeve
The Intervals Mobile UI launched 7 months ago. In that time we’ve been collecting feedback from our customers and using it quite a bit ourselves. We’ve also been busy architecting the next few features, which will include more client, project and milestone management.
When we first started sketching out ideas for the mobile UI, we had to decide if we were going to develop it as a native app for iPhone, Android, and other mobile phones, or if we were going to develop it in HTML and make it available on any phone with a capable web browser. We went back and forth a lot before finally settling on developing the mobile UI in HTML. The reasoning behind our decision parallels that of 37signals, and many other web designers and developers targeting a growing number of mobile devices entering the market.
Why not design and develop a native app?
I’ll admit our first inclination was to develop a native app for at least the iOS and Android operating systems. Running Intervals on your mobile phone as a native app just sounded cool. The practicality of developing such an app, however, proved to be an impenetrable barrier.
Problem #1: Learning a new technology
Problem #2: The app ecosystem
Say we finally did develop a native app for the iPhone or Android. It could take anywhere from a few weeks to a few months to get the app approved. And then we’d be entirely dependent on the app ecosystem, and subject to whatever demands they decide to make. Why be subject to the restrictions of the app ecosystem when we’d be giving our app away for free?
Problem #3: Supporting multiple devices
There may be only one iPhone on the market, but there are more Android devices than I can count. Launching an app for Android would mean fielding bug requests specific to various devices. These bugs would be impossible to replicate and fix without having the same device.
Problem #4: Discontinuous integration
We employ a method of development called continuous integration, which allows us to rapidly design, develop and deploy new features in our app. Because we are in a constant state of development we can quickly respond to customer requests and bug submissions. A native app would completely disrupt this process.
Embracing the mobile web browser
Once the barriers to going native became more evident, we joyfully embraced web technologies and began brainstorming how we could incorporate the latest web design and development trends into our mobile UI. The reasons in favor of going this route began popping up faster than a Chuck E. Cheese Whac-a-Mole fervor.
Use what we know
Adding a mobile UI to our existing web-based application
In addition to an existing web-based application, we had a fresh new API useful for getting at the raw data. What better way to test and promote our API than to build our own mobile app to use it? The Intervals API made it extremely easy for the mobile UI to use AJAX, making the mobile experience a fluid one that required fewer page loads. The result would be a snappy interface due to faster rendering times, and less time waiting for a blank white screen to display something useful. The web browsers on most mobile devices are powerful enough to deliver the rich user experience we wanted.
Works on multiple devices out of the box
The best part about developing the mobile UI? We were able to target just a few web browsers common to most mobile devices. There would be kinks to work out for the iPhone and Android, but we didn’t need to get our hands on too many different devices to debug the mobile UI. Between emulators and friends with different phones, we would be able to launch a compelling mobile experience with fewer bugs.
HTML5 came out at just the right time
Full control over release cycle
As a web design and development agency that practices agile development and continuous integration, we need to be able to deploy updates to our mobile UI as often as we do our primary online project management application. We can fix bugs and update the mobile UI as soon as we find a bug. And we can respond customers requests sooner by avoiding large releases, focusing instead on smaller, iterative releases. For an online app like Intervals, which continues to evolve with each release, we need a medium that allows for spontaneity. The web is that medium.
Did we make the right choice?
Yes, we did. And seeing web veteran 37signals announce their decision to launch the Basecamp mobile UI in the same way further confirms we made the right choice for our mobile app and our customers. I’m not saying all mobile apps should be developed in this manner, I’m saying it’s important to weigh your web design and development options carefully. Don’t use a technology just because it’s the latest and hippest thing being blasted on the interwebs. Evaluate your options and choose the right technology for the job. Otherwise, you’ll waste a lot of time building something that may require more work to update and maintain than it’s worth. Meanwhile, HTML5 is just going to become a more ubiquitous standard as new mobile devices continue to hit the market.