Mobile apps must die!

I've written previously that the history of mobile has been a long, painful process of copying desktop computers and then sheepishly realising 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 organise 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, organised and culled. It's a common task we all perform, removing old and unused apps every few months, effectively garbage collecting our phones. Very organised 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 realise 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 behaviour. 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 thse 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.