September 11, 2011

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 <aside> tag or somesuch), it seems we should expect to see ever more advanced web apps in the future.

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.

Comments (29)

  1. September 11, 2011
    Jonathan Stark said...

    Thank you for this brilliant post!

     I just finished reading and wanted to give you my gut reaction while I ruminate on a more thoughtful contribution. In no particular order:

    - The distinction between web apps and web sites is not merely academic. When I’m working with a client to spec out a new project, we need to start roughing out the resource allocations. I’d staff up for a mobile web site with different talent than for a mobile web app.

    - I do agree with your conclusion that a “fat web client” is definitely a web app. But I do think that there are plenty of thin web clients that can/should be considered web apps based on the UI/UX points you made (i.e., if the user thinks it’s a web app, it’s a web app).

    - I feel like the ability for the app to run offline is an important consideration. I’ve been wrestling with a post that explores the distinctions between “web apps” vs “HTML apps”, and “web apps” vs “native apps”. The lines between these things seem very clear on the surface, but when you dig in they start to dissolve into each other (which ultimately is what I think the future holds – no meaningful distinction between web, HTML, or native). Anyway, I think that a web *site* should not be reachable if a user can’t get to the web, whereas, a web app almost always should have at least some offline capabilities. 

    Thanks again for a great post,
    j

  2. September 11, 2011
    Jason Grigsby said...

    For the book we went with the fat versus thin client definition. Seems to be the clearest distinction.

  3. September 11, 2011
    Brad Frost said...

    James,
    Holy shit that was an amazing breakdown. It’s becoming more and more apparent the chasm between sites and apps is growing and I’m really happy you took on the difficult task of articulating the differences.

    In my own little world, I often say the distinction is “fidelity vs. reach”.

    Apps, whether native, hybrid or web are a concentrated effort, the result of which is a focused experience which works on a relatively limited range of devices. This is awesome because we can deliver high quality experiences for high quality devices and push the envelope.

    Sites, on the other hand, have a different superpower, and that is universal access to content. In no way can a site deliver as interactive experience as an app because it’s held back by the lowest common denominator, but as you said you can progressively enhance the experience to make it better for more capable devices. Horray for progressive enhancement!

    We need websites. We need apps. Depriving people content because they aren’t rich enough to afford a best-of-breed device is taking the whole concept of the web (and its effect on humanity) in the wrong direction. We need apps because we need to deliver high-quality, highly-interactive experiences to increasingly-advanced devices. We need to continually push the envelope and move things into the future.

    LinkedIn’s new web app apparently didn’t make the distinction between site and app and as a result pissed people off: http://blog.wapreview.com/14814/ . I think the app is FANTASTIC as an app, but if they shut off the ‘site’ version (m.linkedin.com) they’re depriving a whole lot of users an experience. That’s not cool, I do declare, that’s not cool.

    Again, thanks for such an insightful and thorough look at this and I look forward to continuing the discussion!

  4. September 11, 2011
    Randy Peterman said...

    I’m going to jump out and say that applications do a known set of tasks wherein web sites do not necessarily allow the end user to do a task. A web app can display or write email, connect a friend’s data with your data (social media), and of course create cookie cutter memes [cheezeburger network]. A web site displays information and content in a less tool oriented manner.

    That was clinical, but it is where the line is drawn for me. I work on both and enjoy both, but I think that designers must consider these issues either way.

  5. September 11, 2011
    Ray Daly said...

    The distinction is only relevant, as you say, for developers. The reason is simply because “interface is content.” Or perhaps put another way “interface is the message.”

    Take some content and provide a simple HTML interface. Put the same content in a JS/CSS3/HTML5 interface and the message is different. People will “read” it differently and have a different user experience.

    So the distinction becomes blurred in my view as soon as you cross the line pure HTML line. Ask yourself at what point does adding JS/CSS3/HTML5 take the content from site to app? I suggest there is not a brightline using that (ie. fat client) as a measure.

    However, there may be another measure. Again, it may not be a brightline, but it does help.

    Sites can support an RSS feed while apps don’t.

  6. September 11, 2011
    James King said...

    I use the working definition that a mobile app, whether native or web, is of a narrow focus, typically task oriented and normally not as content heavy.

    A mobile site, on the other hand, is broader, focused and more content dependent.

    I use this simplified definition as a working definition not a rule, but it helps to focus clients on the diversity and flexibility of mobile without overwhelming them.

  7. September 12, 2011
    Mason Brown said...

    Nice read! Also, it was nice meeting you last Saturday in Atlanta during the Mobile App Hackathon. Here’s our recap; I think you’ll find we share a similar mindset:

    http://maysundays.com/blog/?p=1221

  8. September 13, 2011
    Ted Jenkins said...

    Interesting and thought-provoking article. I think Ray might be on to something with interface being content–put another way (and to borrow from literary theory)–I think that there is less “authorial voice” in a web app than a web site. True enough, content exists in both, but in a web app the content is mostly user-produced than in a site.

    A sticking point is, as you mention, the example of Facebook. However, I would argue that Facebook, while certainly “app-like”–almost entirely user-produced content–there exists a strong Facebook voice throughout.

  9. September 14, 2011
    Vivian Cromwell said...

    In our little chrome devrel land, this is one of the most discussed topics within our team as well as most asked questions from clients :) . Here is a summary from Mike Mahemoff and Paul Kinlan http://code.google.com/chrome/apps/articles/thinking_in_web_apps.html

    web apps should be
    - task oriented, you should be able to describe a web app staring with a verb (e.g read a book, watch videos, etc)
    - thick client design that leverages client storage solutions to deliver speedy app expected in native app
    -viv

  10. September 15, 2011
    kopuschen said...

    Thanks for such a great write-up. It’s refreshing to read some of the greatest minds.
    I have couple comments about the future for native mobile apps though. There are reasons why Apple chose to finally open a native development platform on iPhone (and other iOS devices later), among others:
    - It’s much more secure and less risk in cases like phishing attack.
    - Discoverability (by featuring in the App Store, which in itself is a mind-shift easy concept)
    - Total offline capability. While latest web technology allows for some offline features, it’s never meant to be a totally offline experience.

  11. September 19, 2011
    Tim Klapdor said...

    Thanks James! great article. While the lines are definitely grey, I think there is a need to define for precisely the same reason – best practice. Best practice from a developer and design front but also from a clients view. I think one of the biggest issues with mobile currently is managing customer/client expectations. Users often don’t care – they want stuff to work – they don’t care how it does it. Perhaps it’s best to cascade a definition is it this, no/yes, then is it this?

    Facebook is a good example of stuff that falls between the gaps. My point of view is that generally it is a site, but that it has the ability to launch widgets or applets to provide app functions.

  12. September 28, 2011
    José said...

    Great article!

    In my opinion, we can differentiate an app from a site with a mix of architectural and UX point of view:

    1) If the inner workings of the “thing” have some complexity

    AND

    2) It feels like a native app (with more or less fidelity), i.e., we are giving the user a native-like UX

    it’s an app. Otherwise it’s a site.

    For example, Facebook IMO it’s not an app, because it complies with 1, but not with 2. Same with Twitter.com and any other complex site that scrolls and you lose sight of part of its UI (I have never seen a native app scrolling completely, do you?)

    Gmail of course, complies with 1 and 2, it’s an app without doubt.

    Just my 2 cents.

  13. October 4, 2011
    Anthony Forth said...

    Fantastic article that clearly breaks down the issues at present and you thin client / fat client definition is clearly the right one. However, you also rightly point out that native apps are a dead end.

    I think what we’re actually doing is moving to a situation, with evolving HTML5, where we need to develop native apps less and less. My view is that I should create whatever possible in HTML5 now, use a native wrapper and only use native languages for things are not currently possible in HTML5. With a view to maintainability, this will hopefully mean future versions of the apps can rely more and more on HTML5 and I can dump native code.

    So at some future point most ‘stuff’ will be thin client. At this point the consumption or creation definition you mention will be key.

  14. October 7, 2011
    James said...

    “It feels like a native app (with more or less fidelity), i.e., we are giving the user a native-like UX

    it’s an app. Otherwise it’s a site.”

    This, along with the OP, was a nice summary. Everything else feels like you want to respond with ‘WEll, yesss, buuuuut, what about in ‘. And it all falls down a bit – for example, an authorial voice – well, plenty of apps are informational – there’s no difference in that measure between the BBC News App, and the BBC News website.

    I would say that you can and should make the distinction from an development perspective, where it impacts directly on what you’re doing. From a user perspective, I don’t really care what it’s called – does it deliver the info/perform the task/play the game/quinkle the wotnot :-) that I want it to.

    Site? App? Dunno and don’t care.

  15. December 3, 2011
  16. December 13, 2011
    wowgoldkmy said...

    I am going to go ahead and bookmark this page for my brother for a coming up research project for school. This is a appealing internet site by the way. Where did you obtain the template for this webpage?

  17. February 7, 2012
    Event Organiser said...

    Great post! Would like to invite your readers who have Mobile App ideas, developers & marketeers

  18. April 27, 2012
    Goce said...

    Native apps to become evolutionary dead-ends? That’s when I stopped reading based on the fact that you don’t get mobile. No mater where you work and what you think, you really don’t get mobile and even less UX. web/HTML apps? Please lookup the meaning of HTML, would you? HTML based apps are (would always be) fall back mechanism. Native is the future, accept it sooner rather than later or you may end up like… Adobe Flash?

  19. June 9, 2012

    It moves a deep part in my heart. Thank you very much.I like this site.

  20. September 26, 2012

    [...] What about apps? “Native Vs Web” Is Total Bullshit. There is a difference between sites and apps. Check out James Pearce’s fantastic article that breaks down the differences between sites and apps: Of Sites and Apps [...]

  21. September 26, 2012

    [...] Of Sites and Apps [...]

  22. October 31, 2012

    [...] Sink‘s recent discussion of this perennial debate, and also the concluding section of this chestnut from Facebook‘s James Pearce, for more detail on this. Sink, and ultimately, Pearce, focus their [...]

  23. November 1, 2012

    [...] Sink‘s recent discussion of this perennial debate, and also the concluding section of this chestnut from Facebook‘s James Pearce, for more detail on this. Sink, and ultimately, Pearce, focus their [...]

  24. November 7, 2012

    [...] Sink‘s recent discussion of this perennial debate, and also the concluding section of this chestnut from Facebook‘s James Pearce, for more detail on this. Sink, and ultimately, Pearce, focus their [...]

  25. July 29, 2013

    [...] whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web sites and Web [...]

  26. September 20, 2013

    [...] Of Sites and Apps [...]

  27. January 5, 2014

    [...] wanting to get into the debate over “sites” and “apps”, I think the distinction has some bearing on how you choose to spend your money in building a [...]

  28. February 11, 2014

    [...] whether it’s contained in the browser or installed via an app store. Facebook’s James Pearce outlined a few possible vectors that need to be considered when differentiating between Web [...]

  29. March 29, 2014

    Its such as you read my thoughts! You appear to grasp
    so much approximately this, like you wrote the e-book in it or something.
    I think that you could do with a few % to force the message home
    a little bit, but instead of that, that is great blog. An excellent read.

    I will definitely be back.

    my web site … maturetubedemon.com

Leave a Reply