So They Want a Mobile App

More and more clients want to go mobile and everyone has a great idea for an app, but going beyond the idea stage can quickly become a forest of confusing questions and foggy answers. The first step to making a great app a reality is deciding what type of application provides the best platform and reaches the right people. In this post, I’ll go over some basic terminology and the application types available to someone who is ready to go beyond the idea stage and start developing an app.

When talking about mobile apps a few different words and concepts may be tossed around that seem familiar but vague; one is the phrase User Experience or UX. UX is exactly what it sounds like, it’s a description of the user’s experience while using an application, and sometimes even after they’re done using it. This is a broad topic and there are a few different angles from which we can approach the concept.

Slalom Consulting—Michael Hagan

Michael Hagan is a designer and developer with Slalom Consulting’s Mobile Practice in New York. He is passionate about creating exciting interfaces and rich user environments for mobile devices.

One of the less technical angles is an application’s “Look and Feel”. Sometimes what seem to be minor details of look and feel have the most profound influence on how a user experiences an application. For example, most mobile applications are touch based and the time it takes an application to respond to a touch can be only milliseconds. But believe it or not, these fractions of a second can be a critical tipping point between a user experience that is perceived as natural and fluid, or awkward and disconnected. This quality is known as an application’s response.

Other more obvious qualities can affect look and feel and thus UX; colors, animations, image quality, legibility, load times, intuitive User Interface (UI) design and functionality. This last item describes how buttons and other items are displayed on the screen, and how easily a new user can understand their functionality. A good rule of thumb says a user should never struggle to understand how to use the application and the application should never seem as though it is struggling to complete a task. Building a good user experience begins with intuitive controls and the right response times.

Another angle of UX is Integration. Some applications integrate with existing systems like email accounts or web portals. These applications should integrate seamlessly, meaning minimal user setup and predictable functionality that is familiar and inline with the existing systems. Integration is usually made easier with the use of API’s (a.k.a. frameworks, libraries).

API is another key term that may seem familiar. An API stands for Application Programming Interface. It is a ready made chunk of code a developer can use as a tool or plugin to add features or functionality to the application they are building. Some API’s provide a path to existing functionality or information already on the device. For example when building an application that takes pictures, the developer will want to use an API that provides access to the device’s camera and photo library. Some apps, particularly games, use an API to read the device’s accelerometer to detect when the device is tilted or shaken. On most devices there are API’s to access user email accounts, videos, GPS, and many other bits of functionality and content a device is capable of storing. Since these API’s involve utilizing built-in features of the device they are known as Native API’s.  There are also third-party API’s available from online sources that can be integrated into an application. The photo sharing website Flickr has an API an application can use to ask Flickr’s servers for photos and captions from specific users or groups in the Flickr community. Facebook has an API to allow an application to plug into the site and draw out posts or pieces of media as well as submit content in the form of photos, comments or “likes”. The same applies to Twitter.

The terms above are used to describe some of the most important facts and figures about mobile application types. To date there are three types of mobile apps, five when you consider mobile-optimized websites and SMS messaging applications, which aren’t necessarily mobile apps but are still an option depending on requirements.

So lets start with some basic descriptions of our options and a few of the advantages and disadvantages each brings to the table:


A Native app is built for a specific type of device, i.e. Android, iPhone, Windows Phone. The code is written in the device’s “native language” and is stored on the device. The advantage is an application that runs smoothly and can take advantage of a device’s full range of features (API’s) and provide a rich user experience. The disadvantage being compatibility, the app will only work on one device type, unless it is re-written for other devices. However this does not mean starting from scratch every time, Slalom Consulting can re-use existing designs and port to another platform with 30% of the initial development effort.

Mobile Web

A Mobile Web app is essentially a website that is built to mimic a native mobile application as best it can (some are surprisingly convincing). The advantage of a mobile web app is that it is as universally accessible as the Internet. The disadvantages include poor response, reliance on connectivity, and limited access to API’s resulting in a watered down user experience.


A Hybrid app is usually a combination of a Mobile Web app and a Native app. An application is written in a web or non-native language and placed in native code that acts as a shell or wrapper. This way the application is allowed reside on the device even though inside it is not written in native code. The advantage here is a single application can be written and encased in different native wrappers to operate on multiple device types. The disadvantage is limited response resulting in the possibility for watered down user experience. Since the application is usually written for many devices, many compromises have to be made and it never really excels on any of them.


There are situations when the information and interface needed to meet the application requirements are so basic that an SMS application is more appropriate. In this case users only need to send and receive small amounts of text data with each other or with a server. These exchanges can be simple user-to-user communications or server-to-user communications that act as notifications or reminders. SMS messages can also be sent to a server as a request to download an app or a vote for your favorite American Idol performer.

Another option that should certainly not be overlooked is to build a mobile-optimized website. Most websites do not translate well when viewed on a mobile device. On a mobile device the screen size is small, load times can be longer, and certain types of media may not render correctly, or in some cases render at all. A mobile-optimized website usually utilizes HTML, JavaScript, and CSS in a dynamic way to reconfigure a site interface so it’s easier to see and select, without having to zoom in and out or scroll too much. Though it is not technically a mobile app, a mobile-optimized website can still provide a pleasant mobile experience. Many existing websites can be modified for mobile relatively quickly and for far less money than it would take to build a mobile application.

It’s important to remember that advantages and disadvantages are relative to your application’s purposes. For instance, if your target market is a group of users with only one type of device, then the disadvantage of a native app’s limited compatibility falls off. If you want to build an application that will operate on many device types and does not involve any complex interactions with the device hardware or native systems then the hybrid disadvantage of watered down experience may not be an issue. Similarly, if you want a basic app that does not need to be downloaded and can simply be accessed by anyone with an Internet connection, a mobile web app will serve you very well.

As with all projects, it’s important to realize requirements early on. Defining a vision, user behavior, user expectations, information architecture and back end frameworks is key.

Sometimes more of the hard thinking has to do with server-side systems. You may find yourself asking questions like: How are we going to get all this content onto the device? How are we going to integrate with our mail server? Do I need this to run on a cloud? What kind of content management system will be needed? Do we need to go beyond SQL databases? Each of the application types is capable of utilizing these back-end services and in some cases it’s the hard work in back end development that makes a mobile app shine no matter what type it is. In other cases backend development isn’t needed at all. Some apps like measurement conversion tools are happy to run on the device without ever making any connections to servers or feeds. And with smartphones having more storage space, and faster processors, this is a reality.

Maintenance is also a major concern. Once an application is built and released, the work is far from done. Since mobile technology is always advancing it is not uncommon for certain code standards to become out-of-date or “deprecated”, to the point where it is no longer supported by the device or platform. This means that a developer will have to update the app source code and resubmit a new version of the app to keep pace with technology. Here is where the benefit of programing an app in Hybrid or Mobile web comes in, they can be made to reach many devices using one set of source code. That means updating just one code source and re-releasing the new version to multiple devices. For a native app to operate on many devices many different sets of source code would have to be written and updated individually by multiple developers, increasing costs and complications. This is one reason why people targeting multiple device types tend to avoid the native route.

So how do we decide what type or types of application(s) to build? Most of the information we need to decide will come from use cases and requirements. This means creating hypothetical scenarios for hypothetical users and stepping through the process that would be required to complete a task using the application. The urge to start white boarding should be natural here; it’s also a very good idea to have a technical/IT person at the table. Below is a very short list of questions and answers and what those answers say about the type of app you should be leaning toward:

Q: device target—
A: single device type/multiple device types
=: (single = native app)
(multiple = hybrid or mobile web)

user environment—
high connectivity/low connectivity
(low connectivity = native or hybrid)
(high connectivity = all)

basic tasks involve—
native API’s/3rd party API’s/standard processing
(native API’s = native)
(3rd party API’s = all)
(standard processing = all)

data storage—
on device storage/online storage
(on device storage = native or hybrid)
(online storage = all)

Once we have an idea of which app type we’re leaning toward, we can use the Venn diagram to gain a better understanding of the features and limitations of this app type and where we may want to rethink or confirm our decisions.

Michael Hagan—So They Want a Mobile App

In the end making the right decisions in the mobile forest means being up to date on the ever evolving creature that is mobile technology, and not being afraid to ask a colleague about it, Google it, download it or attend a MeetUp about it.  And Slalom’s mobile experts are always available for a conversation.  Arming yourself with the terminology and understanding the differences between the solutions will provide the best platform for more detailed research. Because each proposal has different facets and circumstances there is no fool proof diagram for choosing the right application type. Understanding your user, fleshing out use cases, gathering requirements and doing research is the best process to realizing the best platform that reaches the right people.

About michaelhagan
I work as a designer and developer in Slalom Consulting's Mobile practice.

4 Responses to So They Want a Mobile App

  1. Vlad says:

    Apps are what is needed to make your smartphone smart and unique.Im fond of app creating and find it really helpful to use site like Snappii where i can build apps in minutes.

  2. Hello says:

    Its like you read my mind! You seem to know a lot about this, like you wrote the book in it or something. I think that you can do with a few pics to drive the message home a bit, but other than that, this is fantastic blog. A fantastic read. I will certainly be back.

  3. Christian P says:

    What are your thoughts on responsive web design or adaptive design? Why would a client choose an App instead of opting for responsive web design or a pure mobile site.

    I get asked this question a lot and don’t quite know how to respond to it.
    Thanks for the article – Good food for though.

  4. wordpresstutorialsvideo says:

    Regarding Apps: I get asked this question a lot.

    Why should I get an App instead of going for a responsive website or an adaptive website?
    I don’t quite know how to answer this.

    How would you answer that question Michael?

    Thanks for the article… food for thought.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: