In February 2010 we launched the most recent iteration of ABC Local, by my calculation the fifth I’ve been involved in.
This time the project took 14 months but when you consider there are 54 sites and hundred of thousands of pages, along with significant photo, audio and video media files this is not as long as you might think.
Local has been producing significant content online for about 10 years and to a certain extent has flown under the radar in the broad scheme of development for ABC Online.
The last build was released in March 2008
In November 2008 Local Radio decided on a User Centred Design process that used new User Interface standards, and via user testing, fed back into those standards.
In December 2008 an external company, Different, came on board to to supply design, interaction specifications and user testing. Their work included preliminary research, interviewing stakeholders both internally and externally and developing a concept for the sites overall.
An interesting part of this work was the development of personas, representing segments of the audience Local wished to target.
The early part of 2009 saw the development of the designs, and the testing of the interactivity specs.
Different handed over the final designs and the interaction specification in July 2009. Different designed the high level pages, but the interaction specs allowed us to design the lower level iterations â€“ making the interaction spec is at least as important as the designs for the high level pages.
HTML work began immediately, as did a large body of graphical work.
While the scale of the project was large, so was the variety of technologies used. These included:
- Wallace and SiteProducer, the inhouse Content Management Systems
- Electronic Rundown – and in house system for managing radio program information
- TypePad – used as a blogging platform by radio program teams
- Twitter – used a short message alert system
- The Big Diary – a community events content management system
- XML data feeds – external feeds such as weather
In the background the XML team had been working on a core publishing system, designed to aggregate and publish content for topic based sites such as Arts. Early on we realised we could use some of these concepts to develop location based core publishing.
XML work itself started in late October 2009 with a number of large jobs including the building of a local radio electronic program guide that could deal with 54 stations, 260 odd programs and 5 time zones.
With html and design in Brisbane, xml and systems in Sydney, program configurations from Mt Gambier, and content producers and stakeholders across 54 locations, the communications plan was essential to its development and build.
For the bulk of the time we used BaseCamp as a task management tool when building the html and CSS, and once the XML team came on board, used Google Docs, including spreadsheets to rank jobs and fix bugs.
The Local team in Brisbane developed a newsletter based on the palette and design of the sites to create a weekly progress update for Local radio staff. This newsletter highlighted individual modules that were being produced as well as design features which were specific to different sites.
A couple of strategies that worked well for the team:
1. Remove some people from the day to day site maintenance to just focus on the new project
2. Take at least one day a week to just write code â€“ no meetings, no phone calls, no emails.
While the process didnâ€™t always run smoothly I think one of the major outcomes was how beneficial all the developers felt about there being a process, and that because of this when things didnâ€™t run smoothly the process could be used to ask the right question of the right person and work these issues through.
Having all sites available a couple of weeks out, yet hidden from external view enabled us to get about 40 producers to look at individual sites. Designated a â€˜Many Eyesâ€™ process, having this 8 days out from launch enabled us to find any major holes, fix them where necessary or hide them if deemed less important.
The launch day was smoother than any Iâ€™ve been involved in. The sites were only down for 45 minutes which, when you consider it was actually 54+ sites with a lot of of data involved â€“ was an incredibly short period of time (allowing for our infrastructure). It also implemented a number of processes for go live that were hitherto unused and could possibly be a model for launches in the future.