There’s an emerging class of website that tries to behave as much as possible like an app – to the extent that a device’s capabilities enable it to. I think the label “siteapp” suits such websites. They’re sites that transform themselves into apps – if possible.

The new Metro site feasibly falls under that label. Its app-like user experience on certain touch devices is an extension of it’s principal role – as a website. If the user’s device offers the necessary capabilities, it abandons the usual request/response page paradigm and becomes an app (i.e. it loads new “pages” via Ajax, updating the URL in the address bar as you navigate, all the while retaining a single page execution context).

This idea isn’t new. It’s just Progressive Enhancement taken to its conclusion. Yet it maybe warrants its own label, if only to differentiate it from what’s more widely understood by the term “webapp”.

Even though the user on a fully featured mobile might not perceive a difference between the two, a webbapp (such as the FT‘s) is conceived as a full-blown substitute for a native app; it comes from the other end of a spectrum. Yet you wouldn’t demand that a webapp honours canonical URLs; that’s a website’s job. A page on ft.com isn’t a page on app.ft.com, or vice versa.

Whereas you absolutely should expect a siteapp to honour all URLs on all possible devices. Because before anything else, it is the website.

The distinction shouldn’t need to survive our eventual realisation that the term “website” is sufficient to cover anything that can be built with available web technologies. The whole HTML5 campaign is, of course, the huge leap towards that. In the meantime, let’s keep inventing bedazzling jargon for the same thing – the web. Just to show off its many faces.