One of the things that we try and emphasise when talking to clients is that a website is much more than it first appears. It's better to think of a site as an application in its own right, in the same way as you'd think of a web browser, or an inventory management system, or (if you really, really have to) a spreadsheet.
On a technical level, that means using REST techniques when building the site. It's too big a subject to go into detail about here, but the basic idea is that you have a very simple set of common actions that you can perform on the objects in your system - create, read, update and delete - and you "expose" those actions through a consistent set of site addresses. So an address of "http://something/1" that arrives at the server is automagically assumed to be a "read" action that's aimed at the object 1. That's a drastic simplification, but it's good enough to get the basic drift.
That's important because it provides consistency - if it works for object 1, it'll also work for 2 and 3 and beyond. And that makes interfacing other sites with yours very much easier.
It's also important because it makes your site extensible - which means that you can hook other systems into it at a later stage, and you're not necessarily going to need us to do it for you. Anyone who knows about the basic principles of REST will be able to figure it out.
While it's clever at a geeky level, it's also a bit arcane if you're thinking in "website" terms - and particularly if only you're thinking about interacting with a site in a browser. This makes explaining it - and justifying why it will make building your site slightly more expensive in the short-term, but a much better investment in the long-term - a bit tricky at times.
A conversation in our Skype chat earlier today reinforced this - there's a potential client who are looking to redevelop their website - but they seem to be struggling to think of it as anything beyond a simple electronic brochure.
So I got quite excited when I stumbled across something the Guardian are doing with their RSS feeds, because it's a tangible application of exactly these principles. They've taken the same REST approach and applied it to their feeds, but done it in a way that makes sense in the browser or RSS reader.
For the Guardian, it starts with a consistent addressing structure - so the UK news section is accessible via a simple "www.guardian.co.uk/uk" URL.
Then the same applies to getting at the associated RSS feed - tack "/rss" on the end, and you'll find the same (and full) content but formatted for consumption in an RSS reader.
That's an example of a "destination", but there's also the option to do the same thing by "theme" - so content that's about politics will show up at "/politics".
And this gets remixed further with the actual topic, so political news about Labour will show up at "/politics/labour". Again, if you want this in RSS form, just tack on "/rss" to the end.
This is very, very clever, and got me rather excited at the simplicity of it all - but it doesn't stop there. You can start to combine various topics together SIMPLY BY CHANGING THE URL - if you want to see everything that's related to Labour and the environment, change the URL to "politics/labour+environment/climatechange" and the results are now a mash up of the two topics. Tack "/rss" on the end, and you've got a machine-readable format.
So why is this so interesting, and why should you care if you're not an RSS geek like me?
Well, simply that the Guardian has just given ME the ability to create a customised feed of news to fit my requirements. They don't know me, and they've got no way of knowing what my specific requirements are - nor for that matter are they likely to have the resources to satisfy them if they did. But that doesn't matter - if I can figure out the options that they've exposed, I can create something bespoke for myself - which greatly increases the value of their service to me, and makes it far more likely that I'll stick around.
The crucial point here is that they've gone beyond thinking of the website simply as a publication, and are thinking of it in terms of being a service or application in its own right. They've got no way of predicting exactly how people are going to use it, and to a certain extent they've got little control. But what they ARE doing is making their core service much more useful to me, which massively increases its potential value to them.
Now instead of thinking in terms of news content, think cinema listings, or train times. Or imagine exposing your product information and inventory in this way - "tell me about the specifications of all the blue left-handed widgets", but done through a simple web address. You start to get a glimpse of the possibilities that might be out there if more sites worked this way. It might make the initial build slightly more expensive, but the long-term possibilities are greatly increased.
The Headshift blog feed