Aarra Insight : Uncorked Studios : Native Applications vs Mobile Web
As part of a new feature from Aarra, our companies will offer their unique perspectives and opinions on emerging trends, technology and challenges that we in the industry are facing every month. For our June edition, Uncorked Studios gives their take on mobile strategy, designing for context and some advice on when to choose native application development versus mobile web. Read on for an in-depth analysis from Marcelino Alvarez (@mrlnmarce), founder and EP of Uncorked.
Designing for Context
At Uncorked Studios, we like to consider ourselves a contextual design company. This means that we focus our efforts on developing an experience that is contextually relevant to the use case in which it will be used. This notion is particularly prevalent in our mobile work, though it is extensible to a variety of project types, from sporting events to interactive installations to bus shelter ads.
Within the mobile design realm, there are a variety of usage contexts that influence the type of mobile execution that makes most sense. Historically (or as historic as the modern mobile era), this debate has centered around mobile web vs mobile apps. While both of those options still remain the primary options for mobile, there are a few new solutions that merit consideration.
When agencies and clients approach us with a concept, they are often not aware of the variety of ways in which we can deliver a mobile product. In this blog post, I’ll review some of those options and discuss a couple of instances in which we weren’t able to steer our clients to the correct platform.
User stories for an undeveloped cheese iPhone app. 2012
When Things Go Horribly Wrong
One of the worst things that can happen with mobile is when we try to force fit a concept into the wrong mobile solution. There are certain ideas that require a mobile app versus mobile web, and vice versa. There are plenty of concepts that could be achieved with a mobile website, but get shoved into an app because a creative or a client just has to have an app. It’s often a frustrating exercise to talk through these scenarios because it’s clear that a platform decision has been made prior to reaching out to a mobile development partner. By the time we’re brought in, it’s too late to steer the conversation to the correct solution. There are also plenty of times when prioritization is given to the least important (or least functional) feature.
Here are some mobile miscues that we have heard recently and/or frequently:
- We know it’s a mobile website, but can’t we just put a shell around it and launch it as an app? Our client really wants an app. It’s the same code, but with the shell of an app.
- We have this really awesome idea for a game, but our client doesn’t want to build an app, can we build a 3D driving game that works on a mobile website?
- We need to build an app that will only be used on 3 iPads. It’s a catalog for an internal sales tool. We’d love to consider iBooks, but we really want an app because that’s what we’ve already sold through to our client.
- We have this great mobile concept, it’s like Twitter and Instagram combined, can we do it in three weeks?
- Our client wants the game to be in the top 10 on the iTunes App Store and compete with Angry Birds, can we get it done in 2 months?
- Why can’t we put an ad that works inside Apple Facetime and automagically replaces your face with our logo?
- We want to build this for Blackberry because our client is on a Blackberry Curve. We know our users are on Android and iOS, but we need to think of our client.
- We don’t have any money because it’s an internal concept, but our agency is open to a revenue sharing agreement until you recoup your costs.
- We don’t have any money to build this, but it will have all the PR muscle of our agency behind it. Plus, Radiohead is involved. RADIOHEAD!
I Want an Icon
The reason we see these misguided questions about mobile isn’t because agencies and clients don’t understand the platform. I would argue that developing for mobile is no different than building a product for any other platform, be it a website, Facebook, a TV spot, or a print campaign. Like other media, mobile requires an understanding of how it will be experienced in its final form.
The reason we see these questions is because people aren’t trying to solve for mobile, they’re trying to appease someone, be it a brand client, a digital strategist, or an ECD. And when appeasement is the raison d’être, the final product is bound to fail, either strategically, creatively, functionally, or all three.
Rather than to push mobile for mobile’s sake, we need our clients to understand the reasons for getting into mobile and the variety of solutions that will enable them to enter that space. A mobile icon can be achieved in many ways, whether it be a website, a native app, a Newsstand publication, an iBook, or a prototype. Understanding the nuances of each will help in selecting the appropriate one for a strategic brief.
A mobile presence can take the form of quite a few icons. Know which is right for you.
Mobile Web
Let’s start with mobile web. A mobile website is a relevant and wide-reaching solution for a variety of mobile needs. A small business such as a bar or restaurant might find a simple mobile website is an adequate way to display hours of operation, a simple map, contact information, or even a photo gallery, Twitter feed, or Foursquare check-ins.
The Upside
Mobile websites are accessible from both a price and maintenance standpoint. They can be developed using HTML, CSS, and JQuery. They can be updated frequently and can be accessed via most modern web browsers on iOS, Android, Blackberry and Windows Phones. More complex mobile websites can be built atop of an existing CMS, contain simple animations, respond to touch gestures, and even begin to look like a native application. On the iPhone, a mobile website can be bookmarked with a native-looking icon and be launched from the home screen. 37 Signals’ Basecamp has a great mobile website that I launch from my home screen quite often.
Check out Basecamp from your mobile phone browser. It almost feels like a native app.
The Downside
The downside to mobile web is that different browsers render images and text differently. Placement of design items such as buttons, gradients, textures, and fixed footers might need relative placement versus absolute. While Android devices allow for basic file access from a mobile web (uploading a photo, video, etc), iOS devices cannot access the camera from a mobile website.
A mobile website is a sound solution if reaching multiple devices across various operating systems in a cost-efficient manner is a primary consideration. If function is more valuable than absolute pixel-perfection, mobile web might make sense. It’s a great place to start.
But I Want an App!
A mobile application allows for a more uniquely customizable solution for a mobile presence. On mobile web, content is rendered via the device’s mobile web browser and subject to the limitations of web browsers. Within an application, one is able to customize the visual appearance and flow of content in unique ways. Whether it’s building a grid-like scrolling mechanism with content blocks that animate independently or building a 3D gaming environment, a native app provides for more customization.
The Upside
With an app, we get access to the device hardware, both from a memory and processing standpoint. We are able to render animations more smoothly, do more things faster, and tap into camera controls, the accelerometer, and GPS.
The Downside
The downside to building a mobile app is that it usually requires more time than a mobile website. The code base for iOS is different than Android, so one is essentially building two apps. While they can be developed concurrently, any UX, code-architecture or design changes are made twice.
Our Approach
Typically, we advise building either the iOS or Android version first, then adapting to the other platform. Beyond the iOS and Android realm are device considerations – designing for tablets requires consideration for how those devices are used. While the tablet versions can share the same code base, its worth taking advantage of the extra screen real estate and processing power to enhance the user experience.
There are tools to build cross-platform apps using a single code-base. Frameworks such as Corona, PhoneGap. Titanium, or Adobe Air allow for the development in one environment with the ability to publish native apps quickly. In some scenarios, such tools might make sense. The disadvantage to using such frameworks is that they sit one layer removed from the native code base. So if either Apple or Google change the way applications need to be built, the developer of the framework needs to make those changes to their toolkit. It’s not entirely prohibitive to development, but it’s a consideration for maintenance.
Beyond the app
There are times when one might need an app-like experience that’s not really possible on mobile web, but there’s not enough budget or time to build an app.
iBooks Author
Recently, we’ve begun looking at iBooks Author as a way of bringing a rich content experience to the iPad. Whether it’s a product brochure, an interactive book, or an internal presentation tool, an iBook might make sense. For internal or limited distribution, iBooks can be sent via email or web link. For those seeking to publish, one can purchase 10 ISBN codes for a fairly reasonable price.
The Upside
And an iBook can be built by someone with solid desktop publishing skills, as the iBooks Author interface looks a heck of a lot like Keynote.Those seeking fancier iBooks options will be pleased to note that it’s possible to integrate basic HTML within a web view. An iBooks file will appear within the iBooks shelf on an iPad or an iPhone. We’ve found that the iPad 2 and third-generation iPad support them better than the original iPad.
The Downside
Downsides to iBooks include the obvious proprietary nature (it’s Apple or nothing), and the somewhat limited navigational hierarchy to what can be built. For some cases, these might not be limiting factors at all, in which case keep it in mind.
iBooks Author has a design interface similar to Apple Keynote. The output can be an interactive book with video, Twitter feeds and image galleries that is stored within the iBooks app on iPads and iPhones.
Newsstand
Those in the periodical publishing industry might benefit more from a magazine than a static iBook. Apple provides a set of tools to publish magazine content using the same code base as a native application. Newsstand products can be found via the App Store and are stored within the Newsstand app on Apple devices.
Newsstand is a great solution for those with periodical content. It’s easy to manage subscriptions, push notifications, or download content in the background. Users can purchase single issues, back issues, or auto-renew their subscription without having to enter their credentials each month.
Newsstand apps are a subset of native iOS applications that appear within the iTunes App Store along with other periodical content.
Application Prototype
One type of app that we’ve found is of considerable value to many of our start-up clients is the prototype. A prototype application can be distributed to a small pool of devices (less than 100) and doesn’t require Apple’s review process. A prototype includes a subset of the desired functionality of a complete product.
Whereas a full application may take anywhere from two to three months to design a develop, a prototype can be built in three to six weeks. It can be distributed to users via an over-the-air (OTA) tool such as Test Flight, which allows the developers and product owners to keep track of who has installed it and what issues, if any, they’ve encountered while using it.
While a prototype is a solid solution for start-ups, we have found it a valuable option for ad agencies seeking to prove a new technology or test out a non-traditional UX for an app. A prototype doesn’t have to include throwaway code – the codebase can be iterated upon for future versions along the pathway to a completed product.
TestFlight allows users to distribute ad hoc builds and keep track of usage. It’s great for prototype development (as well as regular application development).
Conclusion
Identifying the correct mobile solution begins with considering the context for how a product will be used. If it needs to be accessible by users across a variety of devices, mobile web might be the way to go. If its users will be hardcore gamers or desire custom design and UX, then native app might be more appropriate. If a website’s analytics show that 90% of mobile traffic comes from an iDevice, then start with something optimized for that platform. If your product is a published piece of content consumed by readers on the go, consider iBooks or Newsstand.
If you’re still unsure of where your concept fits, ask someone who has built mobile products before. Better yet, ask several mobile development shops. Some companies have a bias toward a particular platform, which is fine, but ask them why the prefer one to the other. Before a decision is made on platform or approach, discuss it with designers and developers of mobile products. They may provide a solution that has yet to be considered. Don’t just pick a technology for arbitrary reasons or because the creative technologist in the room found a link on Stack Overflow. Platform decisions should be rooted in the use cases, the audience, and the context in which it will be used. When selling through mobile concepts, try to be platform agnostic. Don’t just mock a concept in an iPhone when it’s possible that more of the client’s user base has an Android phone.
Once a platform and technology approach is defined, keep in mind that mobile is an iterative platform. Features will be iteratively built during development. After launch, users will provide feedback that will be valuable for future versions or extensions into other mobile areas. Build quickly for the right platform and for the correct reasons, launch early, and iterate often. That’s the best mobile advice we can give to our clients.
