Category: Guardian.co.uk

An ABC of R2: X is for XL

…which was a size of problem we noted but wouldn’t tackle.

When we estimated the work for R2 up front we used t-shirt sizes for each feature: S, M, L and XL. The largest single task the team would tackle was an L, which was the equivalent of five days’ work. We felt this was a good maximum for two reasons: first, it delivered something of value within a reasonable space of time and what should have been one iteration; second, if we could imagine developing it within five days then it was probably sufficiently understood, whereas anything bigger risked being too complex to estimate without a lot more thought.

However, during the time-limited initial planning period we were required to estimate things that needed more analysis than we had time for. These features we labelled XL and gave a nominal equivalent size to: 10 days’ work.

However, we would never actually start a task that was labelled XL. We would always break it down before the event into smaller parts. The aim was that although individual estimates might be over or under, on average they should balance out and the total size of the project should remain constant.

Of course, for XL tasks it was quite possible that a more thoughtful estimate would produce a total that was far too big to be able to be balanced out by other tasks. In these cases we would have to reconsider our options and think about dealing with the problem in a different way — most likely by having a less comprehensive solution. However that didn’t tend to be too much of a problem. In many cases by the time we got to the XL task our stakeholders’ needs and priorities had changed so much that there were a lot of new options and directions that people wanted to explore, and ones that they would not have thought of in those very early planning stages.

This is an example of why planning was important, but very detailed planning would actually have been quite wasteful.

An ABC of R2: W is for Wiimbledon

…which was a semi-regular event of Wii tennis in the office, but a very useful part of our R2 work, too.

Each launch required a small army of technologists to be on-hand: to run the various scripts, check the results, and deal with any problems that might arise. We needed to arrange these teams carefully because launches happened overnight, so we’d need an overnight team and another team in early the next day to pick up any remaining issues.

All this was fine, but after a while someone realised we’d missed a trick. I think he actually wanted to be part of the overnight team (it’s always exciting to see these thngs go live) but wasn’t actually on it. So he arranged with others to bring in some games consoles, and wired one up to a big screen, the others to projectors. It was a big draw, and a great way to have an extra group of techies staying late in case the need arose.

Still, we couldn’t be cavalier with this. For example, we made sure the gamers were located far from the launch team — the launch team had a serious job to do and didn’t need distraction. But that didn’t prevent the benefits: every so often a gamer would slip out of Guitar Hero and wander over to the launch team to check up on progress, offering some advice and support if necessary. One time a critical SQL script was running worryingly slowly and a call came through to see if someone could contribute to the investigation; a couple sat down at a machine a few feet from the Mario Kart players, traced the problem, and suggested a change to the script which was agreed and did the job. That night it made the difference between “go” and “abort”.

If there’s a general lesson to be drawn from this I don’t think it’s to keep a Wii console in the stationery cupboard along with the paperclips and envelopes. But exploiting opportunities that are specific your particular situation is probably a good thing to do, even if they aren’t enshrined in official company policy.

An ABC of R2: V is for video content

…which changed in the way we thought about it (and implemented it) a long time after it was released.

Originally any piece of content was designated as being of exactly one type: it was either an article, a video, a competition, and so on. To take the video content as an example, putting a video onto the site involves opening up a video content editor in the CMS, referencing the appropriate asset in the Brightcove system, and adding some video-specific metadata such as its source and preferred display size. Clearly you aren’t going to confuse that with writing an article, which is why it made sense to say that each piece of content was of exactly one type, no more and no less.

But one day one of the editorial staff made an unusual request: she had an article and wanted us to add a checkbox in the article editor marked “Display on video page”. This puzzled the tech team initially — if it was an article then people wanting videos wouldn’t want it to appear on the video page. Also, we were wary about adding a feature which would complicate the article editor but be used by few people. We quickly found the good reason for her request: she was creating an article with an embedded YouTube video, and the purpose of the content really was to showcase the video. Anyone looking for videos on the site would want to find the content, so it should appear on the video page, but the video should remain outside the Guardian CMS, so the video content editor wasn’t appropriate.

We realised this was a general need: content could fall into several categories at once and editorial staff should be able to flag it as such. The solution, then, was not to add a checkbox marked “Display on video page” because that wouldn’t solve the general problem. Instead we took an existing “labelling” facility present in all the content editors, and we extended it allow content-type labels to be added. Of course, we also needed to ensure the system responded to these new labels, but since it was an extension of an existing feature it was a more natural and reliable solution than we might otherwise have implemented.

The end result therefore didn’t introduce any complexity for end-users — no extra buttons or checkboxes — but it did give them the power to do what they wanted.

This is a good example both of how our understanding of apparently-basic questions (“what is video?”) can change with experience, and of how understanding the source of a requirement can lead to better solutions.

An ABC of R2: U is for URLs

…whose structure we worked hard to get right as part of the project. This was an important part of weaving ourselves into the fabric of the web: to ensure our referencing system had a useful structure to those outside our organisation.

Previously our URLs looked like this:

http://politics.guardian.co.uk/tonyblair/story/0,,2075005,00.html

today the same piece of content is referenced like this:

http://www.guardian.co.uk/politics/2007/may/10/tonyblair.labour3

There are two obvious changes here. First, the obscure numbers have gone — a legacy of our old Vignette StoryServer software, and utterly useless to anyone who happens to be a human being. Second, we’ve included the date in a friendly format, to provide some sense of orientation, and particularly useful if you happen to be looking at several URLs at a time.

There are other changes, too. The “politics” reference has come out of the domain name and into the path, to reflect the fact that all our content is part of the guardian.co.uk site. A couple of keywords also appear in the URL, partly to convey what the content is about, and partly to distinguish it from any other content that appeared in the same section on the same day. As it happens, quite a lot was written about Tony Blair and Labour on that day, so the “3” adds a further unique identifier.

In some ways URL structure is an obscure topic, but getting it right opens up access to more of our content in more ways to more people. Further examples have been given by Matt McAlister in his discussion of the RSS feeds.

An ABC of R2: T is for timeline

…which looked like this:

  • October 2005: Start detailed planning of Travel section. Involved about 12 people from Guardian and ThoughtWorks. Much preparation needs to take place before work can begin.
  • February 2006: Start building the Travel section, initially focusing on the servers, development environment and build pipeline.
  • May 2006: Launch first visible item on Travel section, a keyword component.
  • November 2006: Launch entire Travel section. From a technical standpoint it was then the biggest single launch in the website’s history, and one of the smoothest then known.
  • January 2007: Start planning phase two. Involved around 20 people fulltime for six weeks, but sufficient clarity was achieved after three weeks to start one stream of work then.
  • May 2007: Launch new guardian.co.uk home page. Within hours of the launch, Tony Blair obligingly announces his resignation as prime minister, allowing us to make full use of our flexible templates as the story develops throughout the day.
  • July 2007: Launch Science, Technology and Environment sections. Included a new feature: series. This allows special navigation back and forth through items in a series such as Bad Science or Nature Notes.
  • August 2007: Launch integrated video. Includes reskinned Brightcove player with dynamically-inserted pre-roll advertising.
  • October 2007: Launch sections for Business, Society, Media, Money and Guardian America.
  • February 2008: Launch Observer, News, and Politics sections, plus integrated audio.
  • April 2008: Launch Sport and Football sections. Includes live scores and fixtures, and match facts among other features.
  • June 2008: Launch Comment is Free. Includes community features from Pluck.
  • August 2008: Launch of Culture, Education and Life & Style sections, plus 14 blogs moving over from the old Movable Type system.
  • September 2008. Launch the remaining 21 blogs onto the new platform. Some of these blogs didn’t go in August due to the key part they played in August news events, and some because they were awaiting additional features such as remote working tools.

An ABC of R2: S is for sitebuilding

…which was the penultimate step before a launch, after the software had been built and released, and before the technical work to finally lift the curtain.

One of the big changes that was part of R2 was how we structured our content — our information architecture. Previously each piece of content lived in a section, up to two levels deep, and a lot of content was duplicated so that it could appear in more than one section at a time. An extreme example we often used was the affair around David Kelly and the consequential Hutton inquiry. Almost every story there crossed the boundaries of politics, media and daily news.

With R2 we were introducing much more nuanced keywording and more options around navigation. So the content in the old system didn’t map directly into the new system: it all had to be examined and reclassified by hand. Additionally, production staff needed to build subject pages in ways they couldn’t before — for example, the pages on Afghanistan, the British monarchy and the BAE corruption investigations. All this was called sitebuilding.

Of course, the tech team built tools and wrote scripts to make the production staff’s job easier, but some things just need human expertise and take a very long time. Typically we allowed six weeks between the time the software was released and the relevant site was launched and that was the period in which sitebuilding took place.

An ABC of R2: R is for R2

…which people often think stood for the fact that we were building “revision 2” or “release 2” of guardian.co.uk. It didn’t stand for that, not least because this is actually the third or fourth such revision since we launched in 1999. In fact, it stood for “rebuild and redesign”.

However, while plans for the project were still being hatched, and for just a very short time, it had another name. We were just finishing a day planning the project’s priorities and were aware that when The Guardian newspaper changed to its Berliner format the transformation was called internally Project Kennedy. With slightly too much levity at the end of a long day in single room we chose another 60s icon to provide the name for this project. At the time it seemed like a jolly good idea.

Next morning the cold, fluorescent office light of reality hit: no-one wanted to go in front of the board and ask for a large amount of money for something called that. After a flurry of e-mail Mina came up with R2, and everyone liked that — it was neutral and serious.

So R2 it was, and remained.