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 (69)

  1. October 15, 2014

    believe that you have owned a body now, and then the next step is the lens. 1635 2.8L is the first choice of wide angle lens that has good performance in glaring and vignetting. The aperture of 2.8 is still acceptable at dim environment. 35 1.4L is a good choice for random shooting. 50 mm prime lens is not as necessary as in photography but still good choices. 85 1.2L or 1.8, you can make the choice depend your budget. 100 2.8L is a really great device for macro. 70200 mm 2.8L is wonderful in wedding than other event videography. DSLR movie kit is apparent helps you a lot in shooting. However, you needn’t carry it all the time. For enterprise business, you need it to persuade the customers, but you know that you needn’t to use it all the time especially in wedding shooting. You won’t like the experience of heavy burden all the day. In the microphone part, VideoMic is the top choice of many DSLR video users. Except it, I also add the Zoom H4N and Sony UWPV1 wireless tie clip Mic. I believe they will meet most of your needs. To external monitor, my choice is the FEELWORLD FW1042AH 10.4″ LCD Monitor, which has great performance in rendition. ND filter is not necessary in most of conditions. What’s more, the price is not low. Cbllens white balance board is a good but also expensive item. Many people take less concern on CF card, but I believe that they are totally wrong. Purchase better ones, or at least you need to backup several cards. Tripod can maintain the image stability of video shooting. Do purchase the camcorder tripod. Manfrotto is my current choice. Of course, a monopod is also eligible as substitute. DSLR Slider is necessary in wedding videography. There are four mainstream sizes: 60, 80, 100, and 120cm. My recommendation is the 80 cm slider, which is enough for shooting while not too heavy for carrying. The chance of location is common. At this time, the reflector becomes necessary. For DSLR movie kits , welcome directly visit koolerbuym We provide sufficient solution of Digital SLR video Shooting Equipments.

  2. October 15, 2014
    Louise said...

    There is definately a great deal to learn about this topic.
    I really like all the points you’ve made.

  3. October 16, 2014
    Pamala said...

    Pretty section of content. I just stumbled upon your weblog
    and in accession capital to assert that I get in fact enjoyed account your blog posts.
    Anyway I’ll be subscribing to your augment and even I achievement you access consistently
    rapidly.

  4. October 16, 2014
    Margareta said...

    you’re in poinbt of fact a good webmaster.
    The site loading velocity is incredible. It seems that you’re ding any
    distinctive trick. In addition, The contents are masterpiece.

    you have done a wonderful process on this subject!

  5. October 17, 2014

    Moreover these games could do so will lead plants vs.
    zombies 2 cheats (http://Bit.ly/1D8SRQz) the Dumbledore’s Army together with management features.

    Fun-on-the-run with your quest such as to avoid getting any unexpected charges.
    Java is widely known as Java, palm OS, WIPI etc.
    The Java games belong to that question may be charged.
    As soon as possible so as to reach specific goals.

  6. October 17, 2014

    Tower Bloxx’s New York that he achieved other budding artists like Jean-Michel Basquiat, he says, Give
    it a bit overrated but if you are using samurai siege cheats two operating systems.

    These free mobile games have come up with such very high, color schemes are very catchy and as well as timber and some cheats.
    Mobile phones are not going to develop samurai siege cheats
    more sports. Or maybe needing a second story. If you are a delight for people of all
    advantages of this medium is growing at a CAGR of over 50″ space.

    My website samurai siege hack download

  7. October 17, 2014

    Excellent site you’ve got here.. It’s hard to find high quality writing like yours nowadays.
    I seriously appreciate individuals like you!
    Takee care!!

  8. October 18, 2014

    Good information. Lucky me I came across your site by accident (stumbleupon).
    I have saved it for later!

  9. October 18, 2014
    Vera said...

    The fact that this item provides sensible, easy-to-implement guidelines and approaches
    is definitely the largest advantage of all of it.
    I guess that a lot of law of attraction goods fail simply
    because they consist of practically nothing but fluffy, theoretical, impractical BS though the creator
    of Manifestation Miracle managed to place together a program that is laser centered on having results, Fast!

    So when I first found out about this course I was
    actually pleased, even when it sounded somewhat too good to
    be real, and decided to obtain a review copy as soon as
    possible. And it had been the right selection! I think this is certainly the program
    which has helped me by far the most in understanding
    the law of attraction the most effective and also to be capable to place it to
    very good use, so I really am grateful to the creator for
    putting it together.

  10. October 19, 2014
    Neuro3x said...

    Hi it’s me, I am also visiting this web page daily, this site is really fastidious and the visitors are in fact sharing pleasant thoughts.

    For an incredible response please view this page :: Neuro3x

  11. October 20, 2014
    Senaida said...

    I believe that is among the such a lot important info for me.
    And i’m satisfied studying your article. But should remark on some common issues, The site taste is ideal, the articles is in point of fact
    great : D. Excellent job, cheers

  12. October 20, 2014
    Sammy said...

    Very great post. I simplyy stumbled upon your weblg and wanted
    to say that I’ve truly loved surfing around your blog posts.
    In any case I’ll be subscribing onn your rss ffeed and I hope you write oncee more very soon!

    Alsoo visit my web page baldness cure breakthrough – Sammy,

  13. October 20, 2014
    Wolfgang said...

    you’re in reality a just right webmaster. The website
    loading speed is amazing. It kind of feels that you are doing any unique trick.
    Furthermore, The contents are masterwork. you’ve
    performed a wonderful task on this matter!

    Look at my blog post … San Diego bankruptcy attorney (Wolfgang)

  14. October 20, 2014

    It also suggests that there’ll be a three-axis
    gyroscope like there is in the i – Phone 4. If you are not used to the
    way of depart controlling, you can purchase a Incase Origami, which can play the role of i – Pad dock and keyboard protector.
    It will be possible to plug an Apple dedicated keyboard on a
    docking station, but they don’t come cheap and you can forget about using Bluetooth to plug your
    own writing instrument.

  15. October 20, 2014

    This will maintain its resale value, by drawing back money that
    would have been lost through the nicks and scratches
    throughout usage. Some of them have a fixed set anywhere
    in particular for viewing or playback. Maps are
    very smooth, browsing huge pages is a breeze and all round efficiency
    is seriously promising.

  16. October 21, 2014

    If 10 thousand people this, then you can as well! Pros: In depth training program full
    of valuable info.

    Alsoo visit my site cb passive income scam

  17. October 21, 2014

    Get Cash for Surveys is usually a membership program that connects you to a huge selection of firms wanting to pay out you for the viewpoint
    about their goods. The program will direct you to signing as much
    as online corporations by means of emails and forms.
    Once you will be on their database the surveys begin coming to you
    through emails.

  18. October 21, 2014
    sms nusa kaskus said...

    Hi, this weekend is nice designed for me, since this
    point in tiume i am reading this impressive educational post
    here at my home.

  19. October 22, 2014

    The Diabetes Protocol isn’t really a wonder strategy to diabetes.
    It will require comprehensive decision to accomplish 100 % reliable end products.
    Remarkably, the suggestions of the process are extremely simple to comprehend and also aren’t whatsoever requiring.
    You just need complete inspiration, emphasis, and
    also discipline to expect best outcomes.

Leave a Reply