I’ve written previously that the history of mobile has been a long, painful process of copying desktop computers and then sheepishly realizing that it just doesn’t quite work right. This is actually the way of all progress, not just in technology. Art and music follow a similar pattern of copy, extend, and finally, discovery of a new form. It takes a while to shed old paradigms. 

Mobile apps are clearly successful and in some cases, very profitable. For me to say they MUST die appears to fly in the face of overwhelming evidence. But all things come and go, especially so in fast paced world of technology. When a paradigm shift occurs it’s rarely because the old model is hated or even useless, it just can’t take advantage of new opportunities. The old guard clings to their ways, angrily shouting that everything is perfectly fine, you’re exaggerating!

Too much trouble
The problem with apps, and by this I mean native apps that must be downloaded to your phone, is that they are just becoming too much trouble to organize and maintain. It’s just not realistic to have an app for every store you go to, every product you own and every website you visit. This creates an ever increasing set that must be curated, organized and culled. It’s a common task we all perform, removing old and unused apps every few months, effectively garbage collecting our phones. Very organized folks relish the opportunity to tidy their burgeoning app menagerie but most can’t bother and their home pages scroll into a receding haze of choices.

By itself, this issue clearly doesn’t doom apps, but it does show an ever increasing problem. What would happen if we wanted to have twice as many apps, or 50 times as many? Can we keep this up?

This is reminiscent of the early days of the web when Yahoo had a fixed hierarchy of websites that became more and more difficult to keep up as the web exploded. Google’s approach completely avoided this problem by removing any organization and using only search. This allowed you to have access to literally millions of pages easily and quickly. Google broke the established paradigm.

The UX golden rule: Value > Pain
There is a subtle force at work here. When discussing any product, technology, or idea, it’s easy to focus only on its value, what problem it is trying to solve for the user. This is a good start, and has historically been the only consideration. Recently however, people have started to realize that it also has to be well designed; it can’t be painful to use.

These two primary aspects of any product, it’s value and it’s pain are usually treated as independent variables. Of course you want a high value product and just as importantly the pain of use must be low as well. What people don’t appreciate is that these two are intricately linked. What’s most important is their relationship: as long as value is greater than pain, you’ll be ok.

For example, early SMS systems were crazy hard to use but the value, avoiding expensive minute charges, was so high the value transcended that pain. Of course, improvements in the SMS experience vastly increased usage and pulled in even more users. Just because value > pain doesn’t mean that you’re done, it just means that it’s good enough to ship.

But this same equation explains another, even more important, user behavior. As pain goes down, people will use a product more often for less valuable tasks. Value is still > pain but now it takes much less value to trigger usage. The classic example here would be doing a google search. Google has publicly said that if they just reduce the load speed of the Google.com home page by TENTHS of a second, usage noticeably improves. The Google.com home page doesn’t change in any user perceivable way, it’s just a tiny bit faster, yet people use it more. This is important as only reducing pain, not improving the value of a product in any way, can significantly affect usage.

So let’s bring this back to using native apps. If you were to walk into a store and they proudly proclaimed on the door that they had an app, would you immediately install it? What value/pain calculation would you perform in your head before going through the trouble? If you were a big fan of that brand, then the perceived value is likely high and you’d likely go through the pain of the installation; value > pain. However, if you’d never heard of the store, you likely wouldn’t be bothered, value < pain so you’re not willing to take the risk. My point is that if somehow the app magically appeared on your phone as you walked in the door would you be more likely to try it? Of course you would because there was no pain, it went to zero. You’ll try the app because you’ve got nothing to lose. We’ve got to figure out a way to make trying apps painless.

For native apps, pain is >> 0…
Making the user responsible for app management is effectively inflicting a steadily increasing amount of pain upon them. This puts a increasing pressure on apps and they are going to be used less and less often. It’s not an absolute issue, but rather a negative example of Google’s home page usage. By making things slowly more complex and cumbersome, usage will start to fall bit by bit, hardly measurable at first but likely to increase over time.

I can still understand if you are unmoved. You may be thinking, “Really, how many apps do you need? The problem can’t get THAT much worse can it?” Anyone in the technology space has to always keep in mind that nothing is stable. What seems completely reasonable today becomes a prison in a very short period of time. I’m sure most of you remember that the original PC DOS team expected that no one could possibly use more than 640K of RAM…

And it can get worse…
What is likely to drastically change our currently tiny world of apps is the plummeting cost of computing and connectivity. This will significantly increase the type and number of devices that we will encounter every day. In fact, it’s likely that we’ll pass hundreds if not thousands of devices that will each be capable of offering me some type of interaction. There is more detail in my Zombie Apocalypse post but the cost of a smart device is dropping and in many cases going to zero. Here are a few examples:

  • Movie posters with radio tags such as RFID or NFC will allow me to get an interactive version of the poster on my phone to show me more information
  • Any consumer item, such as ketchup or milk bottles, also with radio tags, will allow me to not only get more information on these items just like the poster, but also track usage and even offer to purchase replacement items
  • My local bus stop will be geo-located so all I need is my current GPS fix and I can get just the information for that specific bus stop, knowing when the next bus will arrive. While this is possible today with some fancy urban systems, deploying a geo location system allows any city to do this, across all bus lines much more cheaply.
  • Any store will have an app that I can interact with as I walk through their door
  • Shopping malls will offer maps and hours whenever I’m there
  • A local food cart vendor will offer not only their menu but where they are going next and when they’ll return
  • An on demand rental car company, such as Zipcar, will allow me to register and drive away with one of their cars, just using a bluetooth connection on my phone.

Just-in-time interaction
All of these concepts are of course just speculation but they represent a trend that is thundering down upon us. Each of these devices will likely need some form of interaction but only as I approach them, a “Just in time” interaction model that gives me interactivity but only when I need it. More importantly, the vast majority of these interactions will be a one shot experience. I’ll interact with the device, like a poster, for literally seconds and then move on. It’s a ‘use it and lose it’ situation. What ever I’ve pulled down to my phone to interact with that device is no longer needed.

This is why this interaction will most likely be some sort of web page. It’s a simple way to pull down an interactive experience, on nearly any device, in a way that does not involve installation. The web is uniquely suited to a ‘use it and lose it’ approach. In fact, it’s been doing just that for over 20 years. For those that claim the web isn’t as capable to native apps, that is indeed true. But keep in mind that 1) the standard is improving very rapidly and 2) interaction with these small, cheap devices is likely to be quite modest, you won’t need the capabilities of World of Warcraft to interact with a bus stop.

There is no way that I’m going to be able to or even desire to try this type of just-in-time interaction with our current application model today. The energy involved in finding, downloading, using, and most importantly, throwing away an app is just far too great. The reason mobile apps must die is that it is a paradigm that is holding us back. The whole concept of just-in-time interaction is structurally impossible with installed apps.

Discovery service
Quickly opening and interacting with smart devices isn’t possible unless you can find that device in front of you quickly. To effortlessly interact with the cluster of devices I’ll pass by throughout my day, I’ll need a service that is constantly searching, using the bluetooth, NFC, GPS, and Wifi capabilities of my phone to not only find, but also rank, the devices nearby. I’m not looking for needle in a haystack, I’m looking for a needle in a needle stack. This will likely need some help from cloud servers that will know a bit more about me to enable a reasonable ranking of these devices.

I feel very strongly that this type of discovery service will be the next Google in a few years time. It’s something that Google, Apple, and Microsoft are all equipped to tackle right now. It could even be attempted by a clever startup. The idea of a system that finds and ranks the physical devices around me now is a nearly inevitable service.

What happens when I click on each nearby device would be to simply open a web page, served either on that device or more likely on a central server. What actually happens is entirely up to that device, I really don’t care.  Just like there are very few restrictions on native apps today, there should be very few for these smart devices. The purpose of this system is to just identify and offer just-in-time functionality.

Going forward
Native apps are a remnant of the Jurassic period of computer history, a local maximum that is holding us back. The combination of a discovery service and just-in-time interaction is a powerful interaction model that native apps can’t begin to offer.

No one is close to offering anything like this today. In fact, making this happen is likely going to be a long, slow process. But if we continue to worship native islands of siloed functionality, we aren’t even going to know this is possible. You have to know what you want before you can build it.

12 thoughts on “Mobile Apps Must Die

  1. What a great article. I couldn’t agree more. I wish small businesses considering an app strategy would read this and stop listening to slick marketers telling them the “app market is exploding” and never really explaining to them what that means.

  2. You should distinguish between apps that perform a useful, mostly stand-alone function, and those which are just function as a proprietary website. As usual, marketing folks take a useful concept and turn it into a front-end for their store.

  3. Hi Scott: I stumbled onto your blog through research around the IoT, and have also appreciated the peripheral concepts you discuss such as this one.

    I agree that so many apps are content which could easily be embedded in a web experience, and simply add a burden to find, install, and organize.

    While I hope that ubiquitous and ambient computing emerges, I don’t think radio tagging is the best solution for the use case you describe. Image processing and geolocation techniques have reached the level of maturity that we could achieve your vision by building a standard AR infrastructure.

    If I’m standing at the bus stop, my mobile device knows within tens of meters perhaps where I am. If I then point my camera at the bus stop sign, such a system could easily parse that image looking for one of perhaps ten or a hundred possible patterns in the viscinity and take me to the schedule site.

    We’ve reached the stage too where we don’t need ugly codes, we can easily recognize just logos etc. in a normal human context.

    Bringing some of your other blog posts into this discussion, we should be working to build an open system for vision-and-location context analysis with, as you suggest, a simple QR-style response: simply take the user to an information point.

  4. We are in agreement. I’m fine with geo location (although it is a bit harder to pull off) My claim is that there will be many ways to rendezvous, the purpose of the phone is to hide those details from me: if it is RFID, WifiDirect, or geolocation shouldn’t matter: things should just show up.

    • The argument that having lots of apps causes some user-pain is certainly valid. Yet, your point places a great deal of usefulness (I’d argue too much) on the “just in time” type of interaction. There are, after all, many many uses for mobile computing devices other than “just in time”. And so to say that the entire “app paradigm” must die because it does one class of interaction poorly, well, that just seems too much. You could argue that the just-in-time paradigm does on-demand interactions poorly, so it must die.

      And also, when you say “The whole concept of just-in-time interaction is structurally impossible with installed apps.” It made me think of standing in front of the bus stop outside my office yesterday when Google Now decided to push me a public transit card to my phone. So ironically, for some types of just-in-time interactions, there’s an app for that. :-)

      http://cdn04.androidauthority.com/wp-content/uploads/2012/12/now-transit.jpg

      • I get this reaction frequently as the title to this piece is a bit strong. I don’t mean that apps ‘must go away forever’ only that they can’t be the only tool in the chest. Apps are very very bad at some things, such as just-in-time interaction, and we need an alternative. So I’m not against apps, they clearly still have place, but only for big repetitive things like a Camera app or a games.

        As to your bus stop example, that is indeed a step in the right direction, but do you remember the old Yahoo, the one which organized all websites into a set of links? They too tried to show you what you needed to know and just ran out of people to keep up with the web. If you believe in Moore’s law at all, we don’t have dozens but millions of these devices in our lives and Google Now cards can’t possibly keep up.

        We need a system that can scale like the web scales. We need to be able to find any number of devices around us and interact with them instantly without installing an app. That’s the only way to can possibly scale into a world full of smart devices.

        • Yep. I agree. Won’t it be great to watch that new paradigm evolve (and maybe even play a part in its evolution).

  5. It’s not that mobile apps need to die. It’s that we need to re-invest in standardized protocols so we can have *ONE* app for a given *PURPOSE*, rather than one apps for every single *BRAND*.

  6. Scott,

    Amazingly spot on 2.5 years ago, and now even more relevant today!

    Your referencing of Yahoo is very similar to Ben Evan’s talk about the “pre-pagerank era” in mobile (http://ben-evans.com/benedictevans/2014/4/7/in-mobile-everything-is-still-wide-open), and the implication is the same: everything is still wide open, even 2.5 years advanced.

    Your idea of a combined “discovery service” and “just in time interaction” is spot on. And just about every service you describe is intrinsically tied to specific real world locations. A this points to the most natural solution to the problem – a dynamic, contextual map that both indexes all the available “app-like” services, and surfaces the most relevant ones contextually. Call it Map 3.0.

    Map 3.0 combines Google Now-style contextual awareness with powerful graphical representation of services and information. You can’t just clutter a map with pins, the map must become much more of a representation of the real world, including all those app-like services that will continue to explode.

    We’re building that graphical map at eeGeo – one that provides more dynamic presentation, with advanced video game-style rendering capability. Early days yet, but being free of legacy “utility” map functions allows us to focus on the needs of users in today’s mobile world.

Comments are closed.