Wednesday, November 5, 2014

What comes after applications

Over the past few years, there's been a lot of discussion over mobile apps: should there be apps or not? Obviously the question itself is an opinion divider. One side has faith in apps, while the opposition doesn't. This piece by Paul Adams from Intercom, was the latest manifestation I enjoyed. A good read for anyone interested about mobile computing.

This phenomenon is a result of people getting tired of eating the same app pill for every issue they have. The five year old marketing punchline "There's an app for that" really explains the dominant mentality. And with enough repetition, it was rooted deep into our minds. The emerged "app evolution" debate is just an indication, that people have finally become aware of the indoctrination. This post is my contribution to the topic.

Naturally, there's a gray area in between both extremes of the debate. To me, an application is just one of many ways to solve a user problem. When smartphones really kicked off the mobile app business, everyone wanted a piece of that pie. As a result, it became difficult to jump out from the app bandwagon. In addition to the "me too" factor, what makes an app so attractive option, is the degrees of freedom it offers to both the user and developer. However, it comes with a price tag.

Mobile operating systems have grown a lot since those days. They offer much wider range of tools to build engaging experiences. The common mistake is to think you need to implement everything yourself. Below, is my rough categorization of different methods a user problem can be solved; and how "less control" can in some cases increase the value compared to "more control". It's a matter of identifying the problem before finding a fitting solution for it.

  • A background process takes care of performing the task in behalf of the user. It makes the solution feel like magic because user didn't do anything. As this requires an intimate knowledge of the lower software layers and contextual awareness, it's not really trivial to do. Not to mention being forbidden in many systems.
  • A notification uses existing mechanisms in an operating system to promote a functionality or a piece of information based on its relevancy. This can result in genius solutions, since the needed functionality can be conveniently offered regardless of the context user is in. Even if there's not much interface work involved, a reliable context engine is hard to get right.
  • A system integration takes a frequently used functionality and makes it an integral part of the operating system. This makes interacting with such a features much faster compared to an application counterpart. The result is a smarter and more holistic experience. However, this either requires rooting or OS ownership to do, so it's not an option for many.
  • An application is the last step in the scale. Almost everything is possible here. It's very powerful and can be tailored to fit very specific tasks. Using an application as a solution easily adds more steps to achieving a desired result. Repeating these steps frequently to do something feels dumb. Due to the amount freedom it gives, and the amount of work is needed, the application experience is the most vulnerable to mistakes. Everyone can make an app, and it shows.

At the end of the day, it's about thoughtfully choosing and combining methods available to you. It's the next step in building mobile experiences. All these methods have their places in our daily throughput of tasks. So, even if apps are important, sticking with just them is a sure way to forfeit the experience game. Same goes for denying the application as a viable solution. Having a meaningful combination of variety is the key.

Because people are not binary by nature, so therefore solutions we use to respond to their needs must reflect that. There's no silver bullet, or a size that fits all. Using interaction variety in your user experience will make it more natural and approachable. Transitioning from app-focused model to user-focused model will give a reliable foothold in the market strongly profiled by features, hardware specifications and price competition. Finding other ways to create value is essential to differentiate and stay competitive.

The more you understand the platform you're designing for, the easier it is to deliver more natural and smarter experiences for its users.

Apps alone will definitely not be enough.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.


  1. Spot on!

    Sadly this has been the case for the last 6 years or so? At least that's my experience coming from the now old phones where only java midlets could be run with very little system integration over to Symbian where deeper system integration was possible by design. Developers (back then not so many 'solo artists' but more small companies) realized this quickly and expanded their efforts towards system integration. There were even apps that provided system integration deeply like a (near) full Samba integration or apps that used extensive use of the possible notification backends for example Lock Screen by

    To the Samba part, the plot thickens:

    SymSMB by Telexy

    -integration allowed
    -SymSMB: (actually 4.0 gets to be the last version) then Nokia takes it away under some claims
    -their whole business model collapses for a while:
    -reindroduce a washed down, app centric implementation with no deep integration anymore: and to NC Network Commander the full package
    -cease to exist try visiting now - it's owned by someone else.

    That was only one story though. But it backs a case where platform owners took back some of their control over their systems sadly - and it shows what that in turn does to the ones trying to innovate on those fronts.

    Coming from Symbian to Meego Harmattan and now SailfishOS, it has gotten a lot better again. For the latter, the small company that is Jolla cannot provide access to the lower integration yet, because these regions are either still unstable or require still a lot of hours to implement exposure to.

    I sadly lack experience with Android or iOS for that matter to be able to compare the situation there but I heard on a non jailbroken iOS device it's barely possible and on Android the situation is a little better if not okay.

    Let's see where this is heading. Hopefully the direction remains and we get to see iteration in all directions of the possible modes/levels of user interface and experience design. Let us hope that at least a few show that it is possible. Maybe the rest will jump train ;-)

    Thanks for your nice blog here. Been following it a while now. Keep it up!


    1. A very good example, thanks for taking your time to write it.

      To my understanding, what makes it hard for the 3rd party to integrate ux to lock screen and events view, is the current architecture of the home screen application. And since system stability is highly dependent of the home application stability, it's imperative to make it as resilient as possible. Unfortunately, the more people there are working with that project, the more distant goal that resiliency becomes.

      I'm hopeful that the home architecture will mature over time, and some parts will be decoupled from it. That would work toward a robust system and much richer developer experience, in exchange for slighty increased memory consumption.

      Thanks for your support and stopping by to drop me a comment :)

      Take care!