When does a web page cease to be a page and become something that is more like an app? The answer is pretty subjective, and two people can argue (and have) about this for hours and still not agree. Superficially the difference between the two may seem insignificant, however the typical characteristics of a web app do distinguish it from a web page.
At Caplin we have been creating app-like web pages for over 10 years, however we have frequently had to wrestle with the browser’s natural behaviour and find inventive solutions to achieve the desired behaviour. The rapidly increasing availability of HTML5 within the latest browsers has made it considerably easier to build web apps, with the application cache and other APIs making it viable to create a web app that is indistinguishable from, say, an equivalent iPhone native app – depending on the complexity of that app.
The signature of a web app
There are a few characteristics that differentiate a web app from a web page. The following list specifies the differences that I consider to be the signature of a web app. This doesn’t mean that a web app necessarily has to exhibit all of these characteristics, however it is a reasonable litmus test.
- Clicking on a link within a web page causes the entire page to reload to display the new content. Within a web app, only the relevant subsection is reloaded or, even better, a loading indicator is displayed and the new data magically materialises shortly afterwards. Better still if new data published to the the server is automatically pushed, in real-time, to the client rather than it having to poll for it.
- Scrolling within a web page typically scrolls the entire contents, where as a web app tends to only scroll the appropriate area.
- The GUI of a web app is designed to work on the device it is running on. A web page looks and feels like a web page regardless of the device it is running on, although perhaps with a cut down navigation system on smartphones.
- A web app can be run, albeit with potentially limited functionality, even if there is no Internet connection.
- Any issues with connectivity are handled, with data to be sent cached locally for recovery at a later stage. A web app may also cache data it has retrieved from the server to make it accessible even if it doesn’t have a connection.
Web apps are a frame of mind
Perhaps there is a whole complicated taxonomy of things that are not exactly web pages nor fully fledged web apps, but these distinctions don’t really matter to me. Any web page that demonstrates one or more of the above characteristics is likely to provide a better web experience, and that is what matters.
Creating a web app requires a different frame of mind. It is not something that is likely to happen unless it was intended. This doesn’t mean that it has to be difficult to do, or take a significant amount of time; various third party libraries can help reduce the amount of effort. Ultimately a web app requires a conscious decision that this is what should be built with the end user benefiting from the features it offers above and beyond a traditional web page.
Interesting. While I definitely agree with all these characteristics, there is one characteristic I use to determine what is a webpage and what is a webapp. That is whether the user would ever think of clicking the “back” button. If they would, then it is a web page, if not, then it is a web app. I think some processes work well with using a “forward-back” approach and some work better with a “static” approach. The question is not about which is better, but about which suits the application best.
Hi Jon,
That’s a great point. Lack of back button and bookmark support were oft quoted issues with AJAX-rich sites a few years ago. Of course no one seemed to miss the back button within an app, so its an interesting area to tackle. The lack of back button support is somewhat related to the characteristic I mentioned where a web app only reloads the relevant data, however it is certainly an attribute of a web app on its own.
In fact, if I add the correct mark up to my web app and add it to my iPhone home screen, I don’t even get to see a back button, or even an address bar.
I think your point that its about which paradigm suits the application best is poignant – removing back/forward button support for the sake of it doesn’t make sense, however I don’t see why we can’t build web apps that transcend the need for them by having a more contextural approach to inter-application navigation.
Regards,
Ian