Building for the future
Posted in Web strategy on: Saturday, May 31, 2008 by Paul Boag
Does building with web standards really provide a firm foundation for the future or will websites be forever stuck in a cycle of sporadic redesign?
This year at @Media I moderated a panel on communicating best practice. My fellow panellists were exceptional and nobody could dispute the excellent advice they gave. I on the other hand managed (as always) to court some controversy with my off hand remarks.
At one point in the presentation I endeavoured to argue that one advantage of applying best practices today (such as separating content from design) was that it broke the cycle of continual redesign.
A major grievances of management is that every few years the old website is thrown out and a new one is built. They are horrified by this for a number of reasons:
- It means a massive outlay of cash every few years.
- It involves completely writing off previous investment.
- The site rapidly becomes out of date but they cannot justify another big rebuild.
I argued that a standards based website moves away from this model towards an evolutionary, rather than revolutionary, approach.
Stuart Langridge who was also speaking at the conference, challenged this line of reasoning suggesting that over the next 5-10 years the web would change beyond recognition and that the speed of change would ensure the redesign cycle continued. He even suggested that we would all be building our sites in Silverlight by then. Fortunately he was only joking and this wasn’t some kind of prophetic vision.
Although I certainly understand Stuart’s position I have to say I think he is over estimating the speed of change. When looking at the future we all have a tendency to over estimate the speed of progress (I am still waiting for my hover board and cyborg eyes) and I believe Stuart is doing exactly that.
The web will certainly be a different place in 10 years, but it will not be so different as to undermine the benefits of standards in planning for the future. For example separating content from design is going to allow for a gradual transition of content from HTML to XML or whatever follows. It will also allow for easy design changes to keep in line with best practice or the latest design trends.
Am I saying that if your site is built with the standards now that you will have the same site in ten years? Well yes and no. Probably the entire site will have been replaced bit by bit. However, I don’t anticipate having to dump everything and start again every few years.
It reminds me of a scene with Trigger in Only Fools and Horses. Trigger was boasting to Del Boy and Rodney about his road sweeping broom. He proudly announced that he had had the same broom for over 20 years. The other two looked at his mint condition broom and appeared dubious. Trigger went on to say that he had cared for the broom lovingly, replacing the handle 14 times and the head 17 times.
Was it the same broom as he started with? Of course not. The handle and head had both been replaced. However, he had never had to throw out the whole broom and buy a new one. That is what it should be like with our websites. We should replace and upgrade parts of it on a regular basis rather than start again every few years. Standards and best practice make that possible.
6 Comments
Comments are for the discussion of this post. If you have other questions / comments then post them to the forum or send me an email
Hrm. What I was driving at was that, to take an example, the beautiful promise of _actually_ “separating presentation from content” was that all future re-designs would involve merely changing the CSS; your markup, because it was done once properly and semantically, would never need to change again. In my experience, that’s rubbish; I’ve never, not once, not ever, been able to deliver a re-designed site without touching the markup. (Maybe I’m unusual in this, but I don’t think I am.)
In the same way, separating the behaviour layer from the content offers the same promise; we’ll overlay some unobtrusive scripting over that beautiful semantically-designed HTML and to change the behaviour merely change the scripting. Again, it hasn’t happened, and critically (unlike CSS) the behaviours we’re building now are fundamentally different from those we were building three years ago. What will they be like in three years time? In five? In ten? The web of 1998 was a fundamentally different place than it is today; we understand it a lot better, for a start. I have no reason to suppose that we won’t have undergone similarly radical shifts in our understanding (and thus be in a position to undergo similarly radical shifts in how we build the web) in 2018. It’s not that the technology changes (although it does), but that our depth of understanding does. That’s why it’ll be different; we’ll look back on our efforts of today and chuckle ruefully at how childish and ill-informed they seem by comparison.
I really don’t think it’ll be Silverlight, though :-)
Love the Trigger analogy.
Building with web standards is the basis of future thinking, and it is the best method to avoid major redesigns. Being forever stuck in redesign though, should be a normal consideration when building a site. We all like to have a new computer time to time.
When I get new clients the first question I ask them is what EXACTLY is your site for? Usually the answer is vague at best. I then quickly inform them that building a site is a financial investment, and they will need to have good rea$oning. It makes it a bit easier to design then too. Too often people or management take the idea of having a site for granted, and may have forgotten the financial gain or savings they get by having a website.
Robot eyes will be here soon. Wait and see. I’m with Stuart – I can’t see a redesign ever being done without markup being changed. After all, wouldn’t that be more of a reshuffle than a redesign?
Another thing that using standards certainly does though is to ensure that the website is in a state where anyone can redesign it. If you move on from your company etc. the next person who gets to do the redesign at least gets a good starting point. No having to spend several days just trying to trace where they have put everything.
I am not suggesting that the markup wouldn’t need to change if you did a redesign. What I am saying is that we shouldn’t be redesigning. We should be evolving over time and standards make this a hell of a lot easier.
I am with Paul on this one. We should be “evolving over time”, just like he did with the headscape and boagworld websites.