Of Sites and Apps
Users probably don’t care what’s a web site and what’s a web app. But I believe web practitioners should, if only to know when certain best practices apply, and when they don’t.
But does an established distinction exist between the two genres of experience? Not as far as I know. Is it to do with creation versus consumption? Linkability? User experience? Or the architecture underlying the way they are built?
Personally I think there is a way to clearly delineate the two types of experience, but I’m also sure it’s not the only way to do so, and that the distinctions are very likely to vary with individual’s perspective. I’m unabashedly trawling for debate.
<tldr>
There’s one notable result of the disruption that mobile is wreaking upon the way we think about the web. The blogosphere, the conference circuit and various online communities – not to mention boardrooms up and down the country – are abuzz with hypotheses regarding the “One True Way” to do something, the “Dawn of” this, or the “Death of” that.
No doubt I’m a part of this. It’s quite fun. (Although let’s be honest, none of us really has a clue about how mobile’s going to play out eventually.)
In the real world, such binary proclamations are less useful than we like to think. Building mobile and web experiences for real users, real business – and with real constraints of many kinds – is not at all easy. Being buffeted around by voguish black-and-white philosophies (or even the outmoded ones) is of reduced benefit when you’re really trying to navigate the shades of gray in between.
One of the shadiest boundaries to have to consider when using web technologies is that netherworld that lies between ‘web application’ and ‘web site’. As far as I can tell, there aren’t established definitions that help us decide what is one and what is another – let alone a decision tree that developers and designers can follow to decide what sort of experience they should deliver to their users in different circumstances.
On one hand, the differentiation between these two things seems rather academic. If a user can access what I want them to access, and can do what I want them to be able to do, then who cares how we label that experience? It’s the web right? (Stop reading now.)
But again, this belies the subtlety of the real world, and especially in mobile. It’s 2011: iPhone-plus-four. Users want apps. Marketers want apps. Boardrooms want apps. This is, we’ve been trained to believe, the way in which we enhance our phones’ capabilities and access information in elegant, consistent ways. We can assert as much as we want that users should only be using their devices’ web browsers, but apps sell, and will continue to.
Of course, many of these apps are written with native technologies, and distributed via non-web-based stores. This article is not about them: they are likely to become evolutionary dead-ends. But if the web is to succeed as a distribution medium – and as a stack of technology – it will have to rise to match the expectation that’s been set. It will have to provide what is needed to create and deliver app-like experiences, just as well as it can classical site- and document-based content.
The good news is that smarter people than me have long seen this coming. Although much of HTML5 (the markup specification) is about improving the semantic qualities of web documents, HTML5 (the suite of related APIs and technologies) is unashamedly focussed on enabling web applications of increasing complexity. And with browser vendors now competing on such metrics as JavaScript performance and API completeness (rather than how well they support the
Nevertheless, in frequent discussions about the mobile web, its best practices, and its tools, you’ll hear many arguments qualified with clauses like “oh, but things are different if you’re building an app” or “this is a better technique for traditional sites”. I know, because I do too.
And so, as we enter conference season again, I thought it might be interesting to see if there’s any consensus about what these two things even are, and how we can differentiate between them. What is a mobile web app? And when is it not a mobile web site?
For me, there are a few possible vectors that we can consider.
Creation versus Consumption
Imagine a large structured collection of interlinked documents, where the user is essentially limited to a read-only interaction (give or take the odd comment form or search box). There’s no doubt that such a thing should be classified as a site. Blogs, news sites, academic papers – these are clearly the heartland of the classical web. Online stores too? Probably.
But what about micro-blogging services? Photo-sharing? Online email clients, document editors, IDEs even? Games? It seems debatable as to whether one should classify twitter.com as a site or an app (especially on a mobile device), but I am most certainly using an application when I’m logged into GMail, Google Docs, or playing Angry Birds – let alone working in some web-based data admin interface.
Interestingly, this second category of experiences all seem to be read-write (or at least, highly interactional). So can we classify sites as being read-only and apps as being read-write? That certainly seems simple enough: sites are to consumption as apps are to creation.
Does this feel right? One problem here is that there are some beautiful and enjoyable app-like experiences – Flipboard comes to mind – which are clearly oriented towards consumption. (But then again, maybe the logic is backwards here… perhaps Flipboard is what the web site of the future should look like, though Gawker’s infamous app-like blog felt clunky). And how would you classify Facebook? Entirely user-generated content, but it still looks and feels quite like a site.
Linkability
If you are launching an experience from a desktop or homescreen icon, it is easy to feel that you are in a sandboxed and closed environment whose boundaries are explicit and inescapable. If you start your experience by entering a URL into a browser, conversely, you’re more likely to feel that you are at the start of journey – one where every link clicked can immediately take you to another page or another site or another domain, across the web’s endless interlinked landscape with no boundaries.
So does this serve as a way to distinguish between site and app? Most native apps certainly do have impermeable boundaries: outbound and especially inbound. Even the iPhone Twitter app opens up links in a modal, embedded web view rather than spawning a new Safari window (much to my frustration, at least).
But web apps? Need these be silos? No, of course not. They’re still running in a browser, and (unless in hybrid environment) hanging off a URL like any web site does. There’s no reason for a web app not to contain links that lead you off to other parts of the web, either in new browser tabs or the present one. While reliable deep-linking back into web apps seems to be less commonplace, this is more a function of implementations and browser’s fragmented History APIs than some fundamental flaw in the web’s architecture. (I never shared purists’ distaste of hash-bangs, for example. These are a symptom of developers trying to make this inbound linkability and bookmarkability work for single-page web apps: fixing the web, not breaking it.)
So, like others, I’d definitely hold up linkability as a huge advantage of web apps over native apps – but not as a reliable way to distinguish between web apps and web sites.
User Experience
Another way we might classify apps and sites is by assessing the user interface and experience presented. What are the visual cues that an app’s an app, and a site’s a site?
The use of fixed toolbars is certainly an obvious one: at the top, containing a title and maybe a back button; at the bottom a series of large tab-navigating buttons within easy thumb-reach. This is a UI/UX paradigm that, pioneered by iOS, emerged entirely from the native application world, and which, before 2007, had absolutely no precedent in the classical or mobile web worlds.
Ditto disclosure lists. Ditto sliding transitions between master and detail records. Ditto action sheets, spinners, and momentum-based scrolling. Ditto even the disablement of pinch & zoom on document-like content (controversial to some, and yet understandable if you argue that viewport zooming was merely the browser’s way of dealing with legacy, not-made-for-mobile web content in the first place).
Many developers work hard to bring these platform behaviors in their web apps. And many web frameworks work hard to make it easy for them to do so. (My employer is one of those, of course.) Many rightly blanche at the thought of slavishly mimicking a particular operating system – nothing looks dafter than iOS pinstripes in an Android browser – but the point is that many of these generalized UX characteristics are highly suitable for one-handed, touch-based interactions. No-one will claim that legacy desktop web sites (often replete with tiny mouse-centric sidebar menus and table layouts) can ever match a dedicated app-like user experience. Responsive web sites can indeed improve this greatly, with navigation often flowing to the top or bottom of documents for certain screen sizes. But still, these sites are rarely mistaken for apps.
Because the visual appearance is the “I somehow just know this is an app” argument, and one that users might particularly relate to, I do give the UI/UX distinction a lot of credence. But still, it’s a very fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list looks like hyperlinks instead of tappable disclosures? What if I style plain scrolling instead of momentum? This is a question that the likes of jQuery Mobile have pondered too, in an attempt to follow a site-like, progressive enhancement philosophy. Nevertheless plenty of developers are undoubtedly going to describe the results as apps.
Architecture
So this leaves us looking for a more technical distinction. Is there an architectural, boxes-and-arrows argument that might clarify the difference?
The web we’ve known and loved for almost 20 years – undoubtedly a web of sites! – is unashamedly thin-client in design. Web servers do all the heavy lifting, hosting the storage, business logic, and the construction of the user interface that the user sees. Indeed it is surprising that we’ve had to suffer so much browser inconsistency over the years considering that all they’ve had to do is turn a stream of < and > into pixels.
But the rise of the use of AJAX was a clue that this architecture wasn’t always particularly elegant. A user clicks a link to another page on your site? That might mean a whole set of HTTP connections (again), a blocked server thread (again), a clutch of database connections (again), the execution of a bunch of business logic (again), the generation of a whole new slab of markup (again), and its dispatch back across the wire (again). And that’s all before expecting the browser to re-render the entire user interface (again).
I love URLs, hyperlinks and SEO as much as the next man, but that’s some price to pay to simply display a new record of content.
On the other hand, consider an architecture in which the browser is given far more autonomy and responsibility. Think “AJAX++”, perhaps, where not only fragments of the DOM are elegantly updated, but where the entire application can reside and execute in the browser.
The big breakthrough here, of course, has been HTML5’s storage APIs, which allow JavaScript in the browser’s environment to persist reasonable amounts of keyed data throughout or between sessions. This finally brings honest statefulness to our previously stateless browser clients.
On top of this, mature JavaScript runtimes and frameworks happily allow the creation of robust business logic to be applied to this data. DOM manipulation, made reliable and fast by contemporary browsers (and commoditized by libraries for others) means that you can programmatically construct and manipulate entire user interfaces in the browser – in the extreme case, bootstrapping them up from a <body/>-like document whose main purpose is merely to include a <head> of the linked resources required to execute.
This is the world of the thick web client – or ‘Rich Internet Application’ in slightly out-moded nomenclature. A world in which patterns like MVC can be used again to describing client-side behavior, as well as a server-side technique. With this approach, once a client-side application has loaded its resources and is up and running, it can function more or less independently of the server that originally provided those resources, and creates and maintains a DOM that looks very different to that originally sent in the HTML’s markup.
(One might wish to argue that GMail is really just a site comprising a set of documents. Conceptually, perhaps. But comparing the app’s view-source with an inspected DOM tree will present a dramatically different perspective.)
With perhaps the exception of simple games, these applications nearly always need to bind back to some sort of web-based data API. As required, though, they can then easily cache that offline in their own data stores, greatly increasing the responsiveness and user-experience of the application, and making the prospect of continued offline operation a reality. This is a bold new step for the web. Not the web as constantly humming HTTP-pipes, but undoubtedly the web as stack of standardized, open technologies, working in interesting and evolutionary new ways.
I don’t want to give the impression that I feel this type of architecture should be used for all web experiences, nor even that it’s easier to build. Creating apps this way can be a daunting experience for many. Using imperative APIs may seem like a step too exotic next to the familiarity of declarative markup-based documents generated from a server. Your mileage will most certainly vary, and definitely some sorts of experience are better suited by one approach, others by the other. No binary proclamations implied.
</tldr>
But the point is that perhaps this is the watershed that we are looking for: a relatively clear definition between web site and web application.
The former we can define as an experience constructed on a thick server, delivered, with declarative markup, to thin browser clients, which then render what they’re told. Sprinkle on some progressive enhancement to maximize the user-experience and increase the chances of delivering a suitably degraded experience to legacy browsers.
The latter, on the other hand, is an experience constructed on a thick browser client, from imperative instructions dispatched, probably only once, from a thin server (or, in the case of a hybrid app, even no server at all). The philosophy of progressive enhancement survives – perhaps better characterized as ‘feature detection’ in this programmatic environment – although such apps often assume a certain higher baseline of browser capability. Local storage is utilized, MVC-like patterns are followed, concerns of data, logic and presentation are completely separated, and markup, if present at all, might be used merely for templates to be applied to that data.
So…
…yes, I’m a developer. I think in boxes and arrows. But as a relatively unambiguous classification criteria, this final, architectural distinction works best for me. Assuming you agree that such classification matters at all (in particular to those developing such experiences), how does this suit as a working hypothesis?
Discuss, etc.