Posted By Matt Morley on June 1st, 2012
How to Tell the Difference between a WebSite and a WebApp.
Given this grey area, the best way to differentiate a WebSite from a WebApp is the intended interaction.
If it’s primarily a reactive interaction for the visitor then it is a WebSite. If it is a responsive interaction, then it is a WebApp.
But how you make that determination gets tricky. Context is everything.
Lets take an example: You have a website that lets you keep a todo list
For people viewing a todo list, it is reactive.
For you, viewing your todo list is also reactive.
Editing your list, using traditional page reloads is still a reactive interaction for your visitor. Therefore, it is still just a WebSite.
At the heart of the matter, you want it to feel responsive when you add a task, but it just isn't there yet, there are too many segmented interactions. Even if fast, the interactions are still segmented.
This is where the blur comes in... the tighter the interaction loop between the various reactive operations, the more it feels like a responsive interaction. That feeling is what defines a WebApp for me, it is all about the interaction from the visitor's context.
This is also where lots of people start splitting hairs... so lets consider the aggregate view.
If you reason about a website from 40,000 feet, it easy to consider anything a WebApp. Which I think is somewhat accurate. Most WebSites from that height do feel responsive, not reactive.
What Web 2.0 did was define that experience as having to exist in the visitor's context.
So if you want your WebSite to be perceived like a WebApp and feel responsive to your visitor, tightening that interaction loop is essential. A good sign that you want this responsive interaction is that you will want to call your visitors by a different name.
You will want to call them users.