The Financial Times recently launched their new web app, replacing their dedicated iPad app. It’s been widely speculated that this was in response to Apple’s (since relaxed) policy of not allowing publishers to offer cheaper subscriptions outside the App Store than they do within the Store itself, preventing those publishers from offsetting Apple’s margin-destroying 30% cut.
I contributed some thoughts on the relative advantages of both approaches (native app vs web app) to the lead news piece in the new issue of .Net magazine, and I’d like to talk a little more about the distinction between native and web apps from the user’s perspective.
The first thing to state is that this article isn’t about web technologies themselves. HTML5, CSS, JavaScript and so forth are all excellent technologies, and we all use web apps every day; the web is a thoroughly proven platform. Instead, this is about mobile devices, and our relationship with them.
When deciding how to build and deploy an app, web technologies provide many temptations:
- Working on every platform (inasmuch as that’s ever been true for web sites/apps; i.e. pretty much, but not completely, and with some effort).
- Being immediately updatable without waiting for approval.
- Having complete control of monetisation, including advertising.
- Being able to do all the tracking and data-gathering you want.
- Being insulated to some degree from the minutiae of rendering.
These advantages are tempting, and it’s easy to understand why we’ve see a proliferation of mobile web apps. There are, of course, disadvantages too, compared to native applications – but even this simple distinction is somewhat misleading. In fact, there are perhaps four different categories of app:
- Web apps, explicitly running in a general-purpose browser.
- Web apps, running in a dedicated browser and launched from a Home screen (appearing at first to be native apps).
- Web apps, running within a web view inside a native app shell.
- Fully native applications, without an HTML/CSS user interface.
These fall into two neat categories. Category A (types 1 and 2) run within a browser, and category B (types 3 and 4) run within, or are, native apps.
There are three primary problems with web apps as an alternative to native apps. Let’s talk about them individually.
Frames of Interaction
This issue applies to type 1 apps: true web apps, running explicitly within a browser.
The core of the problem is that computing devices are already task-compromised. We can perform tasks on devices, but we’re almost always making a compromise or allowance for the device. This isn’t just about the glib “my paperback’s battery never runs out” type of remark; it’s about the hindrances that come from apps being virtual entities within unrelated, unspecialised physical devices.
Yes, devices bring many unique and almost magical advantages (a thousand paperbacks within the physical size of one), but not without corresponding problems.
Here, for example, is a desktop calculator.
A calculator (photo by Paul Downey.)
It’s a tangible physical device, recognisable to most people (for now, at least), and with a single primary domain of functionality. We understand the discrete set of tasks we can perform with this device, and while using it we’re (by necessity) focused entirely on those tasks.
As a dedicated piece of hardware, it has one frame of interaction. You’re interacting directly.
Now, here’s a calculator app running (essentially full-screen) on a smartphone.
A calculator app, running on a phone.
Very similar, at first glance, to the dedicated hardware above – until your eye strays to what surrounds the calculator. We have a status bar, with signal strength, cellular carrier identification, network attachment indicators, the current time, and a battery charge indicator. Above that, we have a speaker and a camera. Below, a Home button. Surrounding the device, various other hardware buttons and ports.
None of those other things pertain to the calculator, because they’re part of the actual, underlying device – the smartphone. We have a second frame, surrounding and enclosing our primary area of focus.
Apps, by virtue of running on devices which we’re physically interacting with, have two frames of interaction: the app, and the device. You’re reaching through a window to do whatever you’re doing.
Finally, here’s a calculator web app, on the same device:
A calculator web app, running in a web browser, on a phone.
The calculator web app is running in the frontmost tab of a web browser app, which in turn is running on a smartphone. The device’s screen is no longer task-dedicated, but instead is conceptually split into the “content” (in this case, our task-specific web app), and the “chrome” – the actual interface of the web browser. The browser has an address bar, a search field, navigation and bookmarking controls, tab-switching UI and more – none of which has any meaningful or intrinsic relationship to the actual calculator we’re using.
A web app (frame 1) running within a browser app (frame 2) on a smartphone device (frame 3) has three frames of interaction. You’re reaching through a window, then putting your hands into a box, to perform your task.
Chrome has a cost (“chrome” in the generic sense; no disparagement of Google’s excellent browser is intended). The more interface you have visible, the higher the cognitive load on the user. When parts of that interface belong to entirely different, unrelated frames (or levels) of interaction, the load is high.
We can cope with a surprisingly high degree of interaction frames, but we’re not optimised for it. Try running an operating system within a virtual machine, and tell me you’ve never made an error of input scope, sending a command to the host instead of the guest system or vice versa. Web apps within browsers are essentially the same situation.
The nesting of interaction frames is uncomfortable in itself, but browsers also introduce an additional dimension (pun most definitely intended) of difficulty.
Separation of Concerns
This issue also corresponds to type 1, true web apps running in a browser.
Arguably (albeit humorously) excluding women, humans are designed to focus the majority of our attention on a single task at a time. Interfaces which permit and even encourage this separation of concerns reduce our stress level, and facilitate concentration. Many mobile devices use an interface design which enforces a “one app at a time” interaction model.
Even on devices like desktop computers, where history, experience, screen size and other factors make such a mandatory approach undesirable, there’s considerable effort being expended constantly on ways to reduce the number of things we have to focus on (and a thriving third-party software market offering solutions).
Our operating systems have become very proficient at allowing us to focus on one thing at a time. The concept of the frontmost application, for example, complete with a corresponding inactive state and appearance for non-frontmost windows, is ubiquitous. Window-management methods and technologies are myriad. Full-screen modes, the ability to minimise windows or completely hide running applications, virtual desktops and more all speak volumes about our wish to focus on single tasks.
The logical extension of task focus is task separation; the putting of things into places, for dedicated access and retrieval on a deliberate, controlled, organised basis. We all do it (to a greater or lesser extent) in our own homes, by assigning a particular cupboard to cleaning products, and a specific closet to towels or bed linen. A place for everything, and everything in its place.
This is critically important on computing devices, because doing a task electronically usually begins with a huge compromise: you’re using the same tool for every job. Consider these tasks, in their analogue, real-world forms:
- Writing a letter
- Reading a book
- Watching a movie
- Playing a game
All discrete tasks, with appropriate venues, tools/media, and styles of interaction. Now consider the digital equivalents – in every case, it’s a person sitting at a computer, or tapping on a device. There are many enormous advantages, of course; for example:
- Spell-checking of your letter, and sending it electronically.
- Immediate availability of your book, and the ability to look up words, or search the text.
- Watching movies anywhere you like, and being able to pause for a bathroom break.
- The many wonders of videogames, including online play with distant friends.
All well and good, and indeed wonderful. But we give up task-specific hardware, which our brains like so much. We introduce frames of interaction, and so we must then invent our many ways to re-separate those concerns within the virtual environment.
Now, consider modern web browsers. Multiple, independent web pages or apps, each in a tab or window of its own, but all gathered into a single app. Each page or web app is a third frame of interaction, beyond the browser itself and the device it runs on. Apps within an app; a computing environment within another. Suddenly our coping mechanisms of app-switching and so forth no longer work, or at best become poor imitations.
If your app is running within a web browser, it’s automatically victim to a second-order version of the fundamental compromise of computing devices: the violation of one tool per task.
No matter how commonplace and mundane computers have become, we still exist in a physical world – and our experience continues to teach us that the best tools are dedicated. Fundamentally, multi-purpose tends to mean multi-compromise. Indeed, in this case the compromise is almost fractal.
In some particularly egregious cases, such as sites which embed chat functionality into their pages alongside their main purpose, you have a fourth frame of interaction to deal with: the multiple “mini-apps”, within the web page, within the browser, running on the device. Our capacity for wilful focus, and our tolerance, has a limit. If your app approaches that limit more closely than another, you’ll lose users.
These are the disadvantages of engineer thinking about how to design an app, i.e. thinking mainly about technical feasibility rather than how the user feels.
We’re all guilty of ignoring the fact that the browser is not the same as the device itself. It’s another level in the hierarchy, and you can’t pretend otherwise.
System Integration
This issue applies to web apps in types 1 and 2, i.e. those that run within a generic browser application. To some extent, and depending on implementation, it may also apply to type 3 apps; web apps which run inside a dedicated native application wrapper.
With computing devices, the platform is king. Not the hardware (though Apple makes a tidy income from it), and certainly not the operating system itself (which is just a facilitating commodity). It’s all about what we like to call the ecosystem: the degree of external investment in the platform, in the form of everything from apps to compatible peripherals. The health of the ecosystem is the herald of a platform’s fortune.
It follows logically, then, that a platform provider will commercially want to tie customers to the platform as securely as possible. This means unique selling points, exclusive features, and native applications. The primary advantage of native applications (for both customers and developers) is integration with the platform. All those little things we take for granted, and miss when they’re not present. There are hundreds of examples, including:
- Having access to standard contact lists and calendars
- Participating in centralised notification systems
- Having data which is accessible through system-wide search facilities
- Responding to appropriate dedicated hardware controls, like music playback or volume buttons
The list goes on. These niceties are conveniences, but they’re also privileges – and the price of privilege here is to be native. Users want and to some extent expect these pieces of functionality, and native apps are the only type of apps with the ability to implement them. Web apps (for the most part) are forever locked out, because their domain is that of the browser, not the device which lives one frame of interaction above. This separation is self-imposed, and is often for very good reasons of security. A purgatory of choice.
Single-Site Browsers may initially look (to the user) like they’re dedicated apps, but it quickly becomes clear that they’re not, and that their sphere of influence is severely limited. App-wrappers (native apps which embed, for example, a WebKit view which runs a web app) are slightly better off; there are ways to bridge the two worlds of the web and the surrounding app, offering at least the potential for integration. But native apps, inevitably, need do far less work to integrate themselves with the user’s chosen environment.
We’ve already discussed the advantages of web apps, but the disadvantages are by now also manifest. It’s not just about technology, and certainly not just about economics. There’s psychology to consider, specifically psychological distance.
Apps feel designed. They feel tailored, and special. They’re lean-back, on-the-go, crafted, targeted things. The immediate extension of these properties is how at home they feel. We’ve all been pointing our fingers and hissing for years at the app that just wasn’t at home on our platform. An intruder in our midst, often from that worst of all possible worlds, cross-platform.
I said it wasn’t all about economics, but it’s also a bit about economics. Native apps are the fortune of an ecosystem, and thus of a platform. For that reason, native apps tend to get free marketing, both at the user level and at the platform-provider level – and that’s never been more important than on mobile devices. Apple’s walled garden is the sleek toyshop that’s already in your customer’s pocket, and they’re willing to put your app in the window once in a while if it’s good enough.
They’ll dip into your wallet for the privilege, of course, but it doesn’t change the fact that your vegetables are in the supermarket and your novel is in the bookshop. Do you really want to be left outside? Consider very carefully what you actually get for that thirty percent.
Conclusion
Each project must weigh up the relative merits of native and web apps for itself, but the inescapable fact is that when deploying on the web, from the user’s perspective, you’re probably starting with a disadvantage. There’s cognitive load associated with your app being a bookmark instead of an experience, and there’s an implicit trivialisation which occurs in the user’s mind. It’s unfair, but it’s a reality.
Many of the arguments I’ve seen that are pro-web tend to be technological arguments, and they’re maybe mostly true as far as they go. But consumers don’t buy based on quickness of updates, newness of technology, or whether their vendor is “in control” of the development process. Platform-agnosticism is part of your politics, not your customers’ buying decision. Users couldn’t care less, particularly non-technical users.
Instead, people want an experience that’s delightful, and tailored to what they want to do. Something dedicated, and designed. Something specific, and something special – and something that works with what they already have, without effort or aggravation. They want to hit a button and be subscribed, and wake up to a new issue waiting for them while the coffee machine is bubbling away.
You can do those things on the web, and you can even do them well. But when your goal is to make a mobile app that will delight, each technology path giveth just as it taketh away.
Be very sure you’re making your decision for the right reasons, and not beginning with an unnecessary compromise.
