Disclaimer: this has been said before in different ways – e.g. search for separating navigation from structure or separating behaviour from structure – just adding my spin.
The notion of separating content from style, pretty much, become the accepted norm of web design, the benefits well known
What’s been on my mind recently is the notion of separating browser from resource. By “browser”, in this context, I mean the user interface elements in a web application that allow users to get around (navigate), modify content (forms) etc. while “resource” means documents / content published on a web site.
There are multiple prompts for this line of thinking;
– A personal grievance: I hate writing admin interfaces for web applications. The “front end” – what a site’s visitors see – no problem but the admin interface, which is typically both more complex and at the same time, visible only to a limited use group, drives me nuts – lots of work for people who tend to have very evolved opinions.
– Another personal grievance: I (generally) hate using admin interfaces. Browsing / managing a list of users, for example, tends to be painful. The same admin tools being reloaded on every page request (slowing things down). Switching between the list of users and the view of an individual user tends to involve excessive DB queries (unless I’m being smart with tabbed browsing – ie. violating the intended use of the interface). And things like search functionality are never powerful enough, compared to, say, working on the command line with grep or attempting search and replace (side note: tool name of the year: http://fart-it.sourceforge.net/).
– The notion of REST (Representational State Transfer) as raised in Roy Fieldings dissertation and summarized neatly here. A while ago, Jeff kicked off a discussion on Sitepointforums about REST, asking the question “Is there anything there that we can apply to user interface oriented web applications?”. My interpretation on REST, seen from a web app perspective is “REST seems to suggest you have documents represented by URLs and tools for editing (and perhaps navigating) them.”. Mervyn makes a number on insightful comments in the discussion such as this. The bottom line; “what’s the benefit of a REST based architecture?” seems to be that your sites “resources” (content / data) become available to more than just web browsers – many different types of application can “consume” them (web services, specialised desktop content management tools, blog aggregators etc.).
– Recent versions of IE and Mozilla have decent support for XSLT (as demonstrated by Sitepoints RSS feed). This opens up the possibility of publishing “browser” separately from “resource” – for web browsers they can load the navigation / tools to “browse” a site separately from documents being browsed the while other applications consuming the can simply ignore the stylesheets. A given stylesheet may apply to many documents on the site (perhaps even the entire site) so only needs loading once. XSLT isn’t everyone’s cup of tea but think illustrates the point of having “sticky” user interface definitions, that stay with the browser, while documents / resources are loaded separately.
– Recent IE / Mozilla versions also have “workable” Javascript implementations. By that I mean it’s standards compliance is 95% there and it’s less effort these days to write code that runs fine under both browsers. Bit by bit this web developers are starting to realise that there’s alot more to JavaScript than meets the eye. If you look at this example you get the picture. Powerful user interfaces can be built this way.
– With XMLHttpRequest available in Mozilla, IE and Safari, using Javascript, it’s possible to build “sticky pages” that provide all the user interface elements needed for a site. In other words you begin by loading a page that contains everything needed for menus, tabs and even windows. From the “sticky page” resources can be loaded via XMLHttpRequest.
– Rich web clients, spearheaded by XUL, are on the horizon. I’ve experimented with “enhancing” (in fact degrading in this case) users browsing experience before here using XUL. By providing a “sticky menu”, locating individual documents no longer needs multiple page reloads to traverse navigation normally rendered “inline” as static HTML. In practice DHTML is still a safer bet that XUL today but think XUL is succeeding in getting people to rethink the web as we know it.
The main benefits, as I see it, of separating browser from resource are flexibility and re-use.
The documents / data you publish on your site become (potentially) available for consumption by other applications, other than web browsers, hopefully preserving their relevance as technology progresses. By making this separation an objective, it becomes possible to develop / collect standard tools / widgets (DHTML or otherwise) that can be applied to many sites; perhaps the forerunner here is the desktop blog aggregator. Being able to “grep” or search and replace, as a site administrator, using the same command line utility has a higher probability.
As a side effect, bandwidth is also preserved and perceived performance, from the point of view of an end user, should be improved, as the UI is only loaded once.
Anyway – this ringing true with anyone?
Harry FuecksHarry Fuecks is the Engineering Project Lead at Tamedia and formerly the Head of Engineering at Squirro. He is a data-driven facilitator, leader, coach and specializes in line management, hiring software engineers, analytics, mobile, and marketing. Harry also enjoys writing and you can read his articles on SitePoint and Medium.
