Blog Post

What Makes a Good Mobile Application Great

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

What separates the good from the bad in the mobile web space? More importantly, what makes a good mobile application truly great? There are lots of examples out there, but what can mobile developers learn from them? Here are some common sense guidelines:

Mimic the desktop UI

Facebook mobile Each web site or web application that we use in this Web 2.0 world has a feel that we’re used to; the mobile version of web sites should merely be an extension of that experience. Web developers should use the same fonts, color schemes and buttons wherever possible to make us feel at home. For an example, check out Mobile Facebook (here on the left), which uses the same blue hues and fonts as the Facebook I use everyday in Firefox. Facebook has also made it easy to click on a friend’s name and pull up their profile page with a mini-feed, contact information, and other Facebook features we know and love.

Good examples: Mobile Flickr, Mobile Google Reader and Pownce Mobile.

Strip it, strip it real good

Flickr MobileA great mobile web site is a stripped-down, more functional version of its original incarnation, and simplicity is king — all unnecessary graphics should be be excluded. In terms of screen flow, content should be presented first, with navigation placed at the bottom of each page. Having to scroll past navigation to get to the real meat of a web page is the bane of any mobile user’s existence.

Good examples: Mobile Twitter, Google and Mobile Wunderground.

It’s the hardware, stupid

Smart mobile application developers utilize the hardware to its full extent. One example is the Nokia platform, which is known for being completely transparent and vulnerable to developers and has subsequently yielded some great applications.

Good examples: JoikuSpot will use the built-in Wi-Fi to turn your WAP cell phone into a wireless access point; ShoZu will use the N95’s GPS to automatically geo-tag photos and upload them to Flickr; Nokia Sports Tracker will use the GPS module to give you a map and stats about your workouts.

Know thy platform

Mobile web applications should be written natively for each device. Java applications, including GMail for mobile and others, are quirky and routinely lock up, requiring the user to either exit or restart. Having to write apps for multiple platforms may be tedious, but will result in happy users.

Google was able to take Google Maps to an entirely new level of usability by adding “My Location,” which uses cell-phone towers to give an approximate location and has been called a “poor man’s GPS.” It’s only accurate to around 1,000 meters, but saves keystrokes when trying to find a local pizza place.

Unfortunately with most mobile platforms, especially here in the U.S., hardware is limited by cell-phone service providers that subsidize handsets. But Google’s Android and the Open Handset Alliance will help put in motion a new era of “openness,” and consumers will be the direct benefactors.

And of course, Apple’s SDK is coming out soon, which will undoubtedly spawn numerous touch-based applications.

My prediction: The iPhone will be the most hotly contested mobile application platform and the App Store will be full of highly functional and downright fun applications to add to your precious iPhone.

29 Responses to “What Makes a Good Mobile Application Great”

  1. Very nice article Jason. I came across this blog whilst doing some background research into what makes for a good app. This post was very useful in helping me out with my research and I thank you for that. I went on to elaborate some of your points made post I published on my blog App Advisor, hope you can have a quick look and maybe in due course drop me a small comment. The post can be found @ this shortened URL Nathan

  2. Wow I learned alot just from listening to you folks.

    I’m currently working with a group of mobile operators to figure out what & how to expose an existing web application for their subscribers. The process has made me challenge my previous beliefs about streamlining the existing asset for mobile consumption. The bean counters love that approach.

    My thoughts are to start thinking about mobile apps from the user’s point of view. I’d venture that we need to be clear about
    – who is the target customer first? male/female?
    – what phones do they carry? Do they heavily text or browse?
    – do they spend on data plans?
    – are price plans affordable and what’s the penetration rate & adoption rate?
    – how do they perceive the mobile? Must-have Appliance or a Communication tool?
    – what types of info-services are valued by the user?

    For us, the users love the convenience of being able to retrieve all their travel info & services at a single click.

    The North American market offers a relatively homogeneous market and makes it simpler to deploy mobile apps. But in Asia & Middle East, the range in user sophistication, ability to afford, and user mindset; for each market differs greatly between each and within each. So it’s highly challenging & EXPENSIVE to develop all the various options to play in the region.

    In short, I think infoservice relevance & accessibility are key. How we design and deploy would seem to depend somewhat on the OS?

    Still learning………

  3. Great article, however, I would disagree in putting navigation links only at the bottom of the page layout. A simple collection of text-link navigations should be included at the top, as well, especially if the page has ALOT of content. There’s few things more frustrating than realizing you need to be somewhere else and having to scroll down with a d-pad to find the navigation links.

    Everything else is spot on, great article.

  4. Jason,

    Good topic – some good points.

    Just to share some perspective, Earthcomber just won the Mobile Rules! 2008, and Nokia judged a J2ME version in that competition. We use the wrfl table and logs to see what hits the site daily, and to direct people to downloads or moibile web, usually both with one recommended depending on the device/network.
    Even though we have app builds for a huge variety, the mobile web version provides by far the largest daily percentage of our traffic.
    Depending on the device, we have an ultra stripped-down green stripe mobile web version, or an iPhone-styled one that does in fact mimic the iPhone deck. On that version – which by the way is the default style you get going to Earthcomber through “Local” on Palm’s mobile deck – actually employs more graphics, yet is better recieved by mobile users. Why? Text is minimal load time, but minimalist icons help glancing, make assessing the small screen’s results easier than reading a lot of text, even if it is just nav.

    It’s really not a battle between web sites or text versions of web sites.

    Mobile consumer-facing apps should NOT equate to a miniturization of the desktop web. The experience is NOT simply taking the Internet out for a walk. Mobile apps should do things that are useful to the circumstances of being mobile. For us, that is telling you all about what’s relevent to you in your physical surroundings. And I’m not advocating for bleeding edge devices. Rather, requiring people using tiny keypads to do a ton of text entry, deal with drop-down menus, etc., is ignoring the limitations of even the latest devices. To check the time, you glance at a watch. You don’t turn knobs and adjust tiny settings – just when it’s new.

    With mobile waps or mobile apps, it’s best when it’s happening AMAP on the 5 way nav button.

    Judge for yourselves. Here are three looks:
    1. plain, stripped-down: (If you’re using a desktop/notebook, use )
    2. Palm version (WM & PalmOS): same as above, but then edit the tail of the url, replacing “auto” with “palm”
    (If you’re using a desktop/notebook, use (If you’re using a desktop/notebook, use )
    3. iPhone style: same as above, but replace “auto” at end of the URL with “iphone” (LOWER CASE!) (to fake it on big browsers, here’s a click )

    Go to the home button, change to your location (use Internet Connection if you’re on a lan or wifi) then see how much info you can get sliding through the categories and just clicking.

    Do small graphic queues help you interpret and decide things faster?

    Not perfect, but our approach is to treat it as a gadget UI – not a websurfing experience.

    Design for mobile as its own thing, I believe, is the most crucial factor for opening up the data side in the US and free us all from spoon-fed carrier-dictated apps.

    — Jim

  5. Sorry guys – you missed the most important part….

    “track your users and understand what/how they are interacting with your mobile content/application”

    We are on the cusp of one of the greatest ages in ‘handy informational content’ as soon as we can get over the ‘minor issues’ like usability and bandwidth (and throw in a little bit of processing power increases as well).

    I’ve said for a long time, if someone visits your mobile site and you dont have any analytics and dont know anything about them or what they did during their visit…..does it count (as a homage to the saying “if a tree falls in the forest and no one is around to hear”).

    If you run a mobile web site check out Amethon’s Mobile Analytics you might be surprised by how much you can actually find out about your visitors these days.

    BTW Think about this – if you cant tell me the top 3 screen resolutions visiting your site, can you consider yourself serious about delivering mobile content?

    Dean Collins

  6. Hi Jason,

    I totally agree with your first point – with minimal screen real estate, mobile sites really need to strip down on features and maximise functionality in creative ways.

    I recently launched a mobile site which attempts to do this, called, which is why I got excited when I read your article.


  7. A product management discipline that I have found effective in defining application UI, usability and workflow is the jobs, outcomes and constraints model.

    This model simply espouses that your target user “hires” a given piece of software to perform a specific set of jobs relative to well-defined outcome goals and known constraints/limitations (that the platform or the user faces).

    On some level, mobile (at least until iPhone SDK powered native apps begin rolling out) is defined by constraints (device processing, local storage, screen size, keyboard, data costs, carrier restrictions, etc.) so jobs and outcomes have to be factored accordingly.

    I know that everyone is picking on your assertion about mimic’ing the desktop UI but the point is that a mobile application is not a shrunken down PC.

    Hence, the best approach (unless you are Google and have an unlimited budget or Facebook and have 40M users) is to start with the jobs that can readily satisfy specific outcome goals relative to real world constraints and go from there.

    If interested in noodling further on this one, here is a post that I wrote that anticipates mobility 2.0 apps (from a decided iPhone/iPod touch centric perspective):



  8. “What Makes a Good Mobile Application Great”

    Question: What makes a good review of mobile services Great?

    Answer: Understanding that 95% of the market does not carry smart phones or unlimited data plans… so start your evaluation from the mass market, not from the bleeding edge.

  9. You’re right about many of the comments up there regarding simplicity but I also think you left out the need for compatibility with phone usages. Some applications take up a lot of CPUs. Newer aps are coming out though like Cellspin ( that are embracing all of your good points on here and going beyond applications that are already out there.

  10. @Jason :

    Understood. My statement on “Designing for mobile =! miniaturization of the existing Web.” is for the (Web) developers and (Web) designers out there – think uniquely mobile.

  11. We’ve been thinking about this a lot too. After going through our whole list we felt the following summed almost all of it up.

    “A Mobile App needs to be immediately and consistently gratifying.”

    If a user has to work at it, it will not be useful.

    As a side note, American Airlines launched a mobile version of their website which was simple, fast and great.

  12. I disagree simply “Mimic the desktop UI” or “merely be an extension of that experience” is good for the mobile world. Good enough maybe, but nothing great.

    Think uniquely mobile.

    The example I like to use all the time is the Travel Web site. I might use the full Travel site to plan my trip, book my flight. It’s insane to think I will do the same tasks on my phone.

    What’s more likely, is, I want to use the same travel site on my phone but to view my itinerary, or places to eat at my destination.

    Designing for mobile =! miniaturization of the existing Web.

  13. Jason,

    You make some good points, however I think your assessment is iPhone centric which has numerous problems in and of itself. First of all, it isn’t a good idea to try and mimic the UI. A good mobile application should provide a great user experience that delivers the same value to the user as the pc experience. Secondly, your assessment ignores mobile applications that are “native experiences”, meaning the pc experience is secondary to the primary experience which is mobile.

    Next, a great mobile application MUST be wide reaching by design and engineering. This means that it is nearly impossible to develop a mobile application that works on many handsets regardless of operating system that takes into account fonts, color schemes, buttons, etc. Most cell phones are not universal in their support of design elements that you typically experience on a pc. Again, your assessment here is iPhone specific.

    Your suggestion to strip graphics is spot on as image management (and multimedia in general) is challenging given the lack of standards on the various operating systems and devices.

    With regards to developing native applications, your suggestion is fine if the goal is to maximize development costs and minimize operating margins. Your recommendation isn’t financially feasible. In order to achieve cost efficiencies in development, a developer must deliver scalable applications (scalable across devices and operating systems), or else risk driving up costs once again.

    In short, any developer that is seeking to profitably achieve scale in the mobile marketplace must target the largest device segments. These are:

    1. internet
    2. j2ME
    3. symbian
    4. brew
    5. linux
    6. windows
    7. safari

    Now granted, the iPhone is hot in the US, but during the same time that the iPhone has been on the market, Nokia has sold more N series phones (about 7x) and HTC has sold more windows mobile phones (about 3x).

    I think what makes a good mobile application great is one that has good market take up. We haven’t seen any as of yet, though internet usage is high amongst iPhone users in the US, it is certainly reasonable to expect adoption of mobile applications on other devices when consumers begin using data services in the US more readily.