Before: The Existing Site

Amdram.co.uk is a venerable site in today’s internet, having been in existence since 1997, and over the years several different ways of storing content had arisen – from static HTML pages and old Perl-driven flat file databases to separate forum software and external Blogger.com posts. Going hand-in-hand with this legacy was that the information was not always structured consistently as navigation elements changed and were added, so while specific elements of the website remained lively, the bulk of the articles and features had fallen into disuse.

Although the site did deliver good search engine rankings (as it had been around long enough to build up page rank), SEO had not been a main consideration when the previous site was designed and a general facelift was also required. On a related note, advertisers had to be entered manually into the HTML and could not get much, if any, feedback from their ads.

Overall, a complete redevelopment and redesign was required, along with the preservation of eleven year’s worth of variously formatted data.

After: The New Site

For the relaunch of amdram.co.uk, we had the following conditions to meet:

• Migration of all existing content.
• A fresh look to the site and a level of organisation to the data contained within.
• Ease of use for the admins to edit content and generally maintain everything.
• To maintain the search ranking built up over the years, while ensuring that it can remain healthy for the future.
• Separation of advertising management from the actual content.
• To encourage users back into the bulk of the site, rather than solely visiting the forums.

Firstly, the existing site structure was analysed and broken down into rough collections of content. From this, we could draw up a site map in conjuncture with the site owner and start planning how we would classify the data in the new site and how the users could navigate through it.

After my latest vow of trying not to reinvent the wheel again, it was decided to look for an existing CMS to adapt to the needs of the new site and for that purpose WordPress was chosen as I had recent experience in customising it for a similar purpose. So before we proceeded any further, conversion scripts were written to parse the original data and automatically create WordPress database entries. Now that the existing content could be successfully imported into a default install, we could design and create the front end of the site.

A heavily modified combination of two existing WP themes sufficed to meet with the owner’s approval for the look and feel, but the speed was something of a concern. Since an off-the-shelf CMS must be generic enough to be downloaded and installed by potentially anyone on anything, it carries overheads (and other drawbacks) that aren’t suffered by a custom CMS.

Fortunately, there are ways of speeding up WordPress sites – and indeed, any site:

• caching common database queries to stop having to look up the same information,
• compressing the content so that the user doesn’t have to download large static files,
• having content expiration dates so that those static files don’t get downloaded again,
• caching the compiled PHP code to save the server working it out each time,
• using the WPcache plugin as WP can need all the help it can get,
• and removing unnecessary code in the WP theme since it is specific to just one site.

With these tweaks in place, the site was much quicker and bandwidth usage was reduced as a welcome side-effect.

Since I knew that the site owner was interested in developing additional websites (with different content) in the near future, decisions regarding advertising and media files in general had to be taken with one eye firmly on expansion.

For the advertising management in the new site, prior exposure to an existing solution was invaluable again. I had already been impressed by OpenX when researching it for a previous job, and here it was the logical choice as it was design to serve ads across multiple sites.

Likewise, ResourceSpace was already known to be a fairly useful way of managing an image library, making it easier to build up a central store of the type of images that accompany articles.

With a few other additions and alterations, amdram.co.uk was ready to be relaunched. Over the forthcoming months, feedback will be gathered from various sources and incorporated into the next phase of development.

Overview of the Systems Used

With the following four open source software packages, it is relatively straightforward to build a network of easily managed websites:

• WordPress – the heart of the matter. Replace with your favourite off-the-shelf or custom built CMS.
• osTicket – a user support ticketing system that may or may not see heavy use, depending on said users. Can integrate into your design fairly simply.
• OpenX – an advertising server which is, admittedly, a bit over the top if you’re not running it across multiple websites.
• ResourceSpace – digital asset management so that there is one central place to both manage and serve media files – again, overkill for single sites.

Without harking back too much to the bad old days of the nineties, when sites were "best viewed in Internet Explorer with a resolution of 800×600", this website has been designed to comply with the open standards as set out by the W3C, the official standards body of the web. In theory, any recent browser should be more than capable of displaying these pages as nature intended, and they should still degrade gracefully on older browsers.

In practice, of course, the real world isn’t as simple as that; some browsers pay only lip-service to those standards, and no browser completely supports all the standards all of the time, even though the more important standards have been around for some years now. In addition, you can never overestimate the inertia of an existing install base – not all machines can run the newer software, or the IT department will be upgrading them "real soon now", or the end user isn’t aware or doesn’t care that there’s better browsers out there. And that’s just on desktop machines, nevermind mobile devices or home convergence units.

Why Use Them?

Those latter cases – looking at your websites through an iPhone or similar mobile device, or sitting on your couch in front of a big TV browsing via a games console – are one of the main reasons why standards are so important. For the vast majority of websites, you don’t know for sure what your audience will use to view your website, and you certainly don’t know what they’re going to be using a year or two from now. If you start developing for one specific browser, or even for one particular screen (and text) size, then you’re raising a big middle finger to potential customers who didn’t fit in the niche you expected.

It’s not the job of the developer to dictate what someone should use to access their website; it never really was, but we didn’t know any better a decade ago. The web isn’t a novel experience for users any more and they are a lot more resistant to finding out that their setup doesn’t work with your website – unless you have no online competition, then they will just go somewhere else and not come back. If your website is standards compliant, then they will be able to use it. It may not look the same to them as it did to the designer with the big screen, high resolution, fancy computer but the customer will still be able to use your site.

(There are other benefits to standards as well, mostly to do with the ease of development, maintenance and interoperability. Plus, of course, when it’s easier to develop and maintain something, it’s normally cheaper.)

What’s The Answer?

How closely you adhere to the standards really depends on who your target audience is and how much time you want to spend catering to the widest possible audience. To a certain extent, it also depends on accepting that the users will not (and should not) have an identical experience in using your site, or else you’ll find yourself ignoring standards and usability guidelines vainly trying to make things look the same on everything under the sun.

There is an small caveat to that statement – if you’re developing for an intranet, or other closed audience site, then you should know what browsers are in use (and possibly even what they’re likely to be replaced with) and how the site will be accessed. This gives you a certain freedom to embrace the standards that are supported and to ignore the inconvenient ones, but don’t go overboard.

Normal internet sites don’t have that luxury at all; it may be quicker to develop for one version of one browser on one platform, but you’re not doing yourself any favours in the long run. If you have any interest in ensuring that the next wave of handheld devices can use your site, or in not excluding any potential customers from this generation of browsers, then there is no real choice other than coding to the standards first. If you have the time, and the inclination, then you can add the kludges that bring the nicer features of the standards to a few of the other browsers that don’t support them properly.

Put simply, write compliant code now and you won’t have to rewrite it later. The CSS Zen Garden is a great example of how this can work – you can change the whole look and feel of that site without a single bit of the content having to be rewritten.

Supporting Browsers

Whilst I hold it on faith that standards will win out in the long run, there are browsers that currently support the range of standards better than others. I’m not that much of a hypocrite to say use these or else, but there’s no way I’m writing a page about web standards compliance and not mentioning them. The following browsers are all free and all offer a better browsing experience than you may be used to:

• Firefox (Windows/Mac/Unix)
• Opera (Windows/Mac/Unix)
• Safari (Windows/Mac)