Dries made an interesting post about the new HTML5 standard the other day. OK, the post itself is more of an announcement, but the meat (as far as I’m concerned) is near the end, where he says that “The trend in development seems to be towards native mobile applications rather than mobile websites.” He links to the excellent Mobile is Eating the World presentation by Benedict Evans as evidence.
Really? Because while I agree with Evans that mobile in general is the future, I don’t see it as evidence that mobile apps, specifically, are the future. In fact I believe the contrary: mobile apps are just a phase. Mobile web is going to eat the world, and it’s because of the capacity for a single source to provide machine-readable, machine-reformattable content.
What do I mean by machine-readable and machine-reformattable? Technologists will understand what I mean when I say “responsive”, and they may even understand that responsive and accessible go hand in hand. I am avoiding those terms because they are more specific than what I’m getting at.
For the uninitiated, remember that what you see in your web browser is actually an interpretation of code, and all the machines see is the code. It is possible to structure your code in a way that makes it relatively easy for a computer to understand what is the title of a page, what is the main menu, what is main content, and what is secondary. You can even include suggestions for what to do when encountering certain sizes of screen (“responsive” behavior), and offer a version of your content that has no layout, just the text. If you are careful, your website can be easy for a machine to read and understand. It can also be easy for browsers to reformat in a reasonable way, no matter what shape or size their screen. This is what I mean by machine-readable and machine-reformattable.
There is simply so much pressure/incentive for building machine-reformattable, machine-readable content on the web, that I believe it will absolutely take over for per-platform applications.
Legislated accessibility requirements for web and related content. All over the world “section 508 compliance” style directives are being strengthened, both legally and technologically. More big brands are sued every year for insufficiently accessible content. At the same time, never has it been so easy to make websites that meet accessibility needs. In fact, if you’re clever about it, designing accessibility is very close to designing responsiveness. Because of this trend, websites increasingly have to create reasonably machine-readable, machine-reformattable content anyway.
Platform diversification. If you want real universal coverage for your app, you presently have to build for iOS, Android, FirefoxOS, Windows, Sailfish, Tizen, Ubuntu, and probably more. You can decide that it’s not worth developing for some of those, that you can trade off market share for a cheaper development cost. But no matter what happens with their app stores or market shares, all of these devices have to include web browsers as a basic feature. A machine-readable, machine-reformattable web experience supports all platforms automatically.
Device diversification. People are consuming content on an ever-expanding array of devices: phones of varying shapes, tablets, mini-tablets, laptops, touchtops, TV sticks, GGlass, smartwatches, and more. If your product can only be consumed with a special application, you have an extremely large development and support problem. But again, no matter what the device, it has to include an interface to the web as a basic feature. A machine-readable, machine-reformattable web experience supports all devices automatically.
Machine-curated content. Increasingly our information worlds are shaped by computer algorithms attempting to decide what content we want to see. Whether it’s google interpreting a search or facebook filtering your feed, it is critically important for brands to create truly machine-readable content. If you don’t, the machines won’t know when you’re relevant, and you won’t be recommended.
These factors are enough for us to see the decision that organizations face. There are two options to provide a branded, controlled digital experience:
1) Develop a minimally machine-readable, machine-reformattable website for legal and SEO requirements, and develop separate apps for each possible combination of OS and device. That’s 19 apps at my count. Maybe 24, depending on Ubuntu’s hardware compatibility.
2) Develop a single, truly machine-readable, machine-reformattable web application.
That’s a pretty significant cost and efficiency pressure towards machine-readable, machine-reformattable web apps, especially in the medium/long term. It doesn’t cover everyone, though. There are some organizations for whom it will continue to make sense to develop and maintain standalone apps. Some of these are:
very large organizations. The budget and staffing requirements are simply too expensive for a small or medium sized organization. It may cost $1 million to develop an application for all 25 devices, and $300,000 to develop that application in truly machine-readable HTML. Some organizations are simply big enough that this amount of waste can go unnoticed.
organizations with special requirements. For example, a bank may need extra layers of security that are difficult to do in HTMLX in order for you to deposit checks by picture.
extremely personal brands. Mobile devices are extremely personal, and persistence there is more intimate than a bookmark or a website. Facebook is one such example; in fact most social networks probably fall under this category.
For the other 99% of organizations out there, I expect that unique snowflake apps will give way to standardized, truly responsive and machine readable, web interfaces. I believe that in the next decade or so, most websites will be machine-readable and machine-reformattable. This shift will mean legibility and engagement for everyone: from Google’s spiders to visual assistive devices, from TV pluggables to smart watches. And it will mean that the “apposphere” will largely evaporate away.