niksilver.com

…which was one of the key goals of the project. This exposes one of the significant aspects of R2: it was neither editorially driven, nor technically driven, nor commercially driven. It was driven by a unity of needs right across the company, and it needed to be successful in all these areas.

There are a few ways in which we’ve added flexibility to our advertising system, but I’ll mention just a couple here.

One form of flexibility is in the use of our ad slots. Our pages have been designed to display ads of various sizes, and reshape themselves accordingly. This is most obvious on some of the right hand ad slots — sometimes you’ll find them displaying an ad that’s a squareish rectangle, sometimes you’ll return to the same page and find another that’s markedly taller. In theory that’s a trivial piece of work, and HTML and CSS can handle that with ease. But in practice, of course, it’s more challenging. One of those challenges is trying avoid using an iframe container which ensures ads don’t unduly interfere with the rest of the page, but which force you define their size before the ad server has had a chance to tell what size the ad needs to be.

Another, related, form of flexibility is in our non-use of ad slots. You’ll be able to see this on the guardian.co.uk home page which sometimes has ads on it, and sometimes doesn’t. In the early stages of R2 the ad sales team made a decision I’ve always admired: not to fill certain ad slots just because they could, and ensure there were periods when the guardian.co.uk home page was ad-free. Apart from any other advantages this means that when ads do appear they have more impact, and of course it increases the value of advertising on the home page.

I like the work we’ve done on advertising less because of the technical achievements, but much more because it shows we’ve used R2 as a chance to rethink how we approach our business and break away from some conventional thinking.

…which is one of the features central to the Eduction section. An example is this page of GCSE results.

Education tables are a great example of how one specialist requirement can reap rewards for so many others. We decided the Education section couldn’t be launched until we had created the ability to display and manage tables, and that’s one reason why we waited until August 2008 to launch it — there were a lot of other features to build before we got to tables.

Since launching tables for the Education section we’ve extended them for wider use. For example, they now feature more flexible formatting and the ability to click on a column for sorting. They’re also being used in other sections, such as in the Media section to display newspaper circulation, and the Football section to compare recent Spurs managers.

Journalism used to be about writing articles; these days it includes not just text, nor just audio and video, but also — as people like Adrian Holovaty and Jeff Jarvis have long said — managing and exposing data. This is one example of how that can happen.

…which Mat Wall and I have written about extensively before, However, for this piece let me say this…

When you have a huge number of people for whom you are building software (1500 staff, 20 million unique users, and an entire wired economy influencing which way you should go next) then simply following instructions is insufficient, because your users’ demands will change and evolve over time — even if not during the current project then certainly before Version Two. So to minimise the cost of those changes you need to understand the way your users are thinking.

That’s where domain driven design (DDD) comes from. It’s about taking the concepts in your users’ heads and embedding them straight into the software you’re writing. And then when those concepts evolve and change the cost of changing your software is directly proportional to the mental shift that your users are making. When your users say “I want to make a small change” then usually it’s a small cost; if they propose a big change then they should understand when you walk them through all the implications.

For the R2 project we used DDD from the start, and it was key to many of our successes: when we discovered new opportunites which arose only from direct use of what we had implemented, then DDD allowed us to realise them.

Take, for example, the idea of “tone” — the principle that we should be able to categorise content by its “voice” or “style” (well, its tone). Its tone might be obituary, blog post, match report, and so on. The vague notion of this had been around since the start of the project, but we hadn’t settled on many details, let alone how to implement them. But after a few releases, and when the software started getting real use, it became apparent that applying a tone should be very like applying a keyword. Suddenly things fell into place. The functional requirements were clear, as were the implementation details. Tone has become a very powerful feature (here are all our obituraries, all our blog posts, all our match reports,…) yet it was a relatively straightforward piece of work because it was, in the end, a relatively intuitive idea.

Of course, domain driven design has a lot more to it than I’ve described here, and our use of it has been much deeper than feature implementation. If you’re lucky enough to be going to QCon San Francisco then today you can see our software architect Phil Wills presenting a lot more detail there.