The Sport NZ website has been on the Common Web Platform (CWP) for about a year. The move to CWP underpinned a bigger project: to improve the user experience (UX), web standards, project agility and to provide technical flexibility. We also saw it as a way to amalgamate sites.
Subsites on Sport NZ
The Sports Tribunal, which is a separate and independent body that we fund, is our subsite. The Tribunal decides what happens to an athlete who tests positive for something they shouldn’t, or allegedly violates some other sporting code. It also handles appeals for non-selection in a national team. The Tribunal is a distinct body; it requires a distinct online presence.
Moving the Tribunal's website to CWP worked well. We delivered a site much more useful than its previous incarnation, thanks largely to code sharing between our major (Sport NZ) and minor (the Tribunal) sites. We’re also saving significant money in licensing, hosting and service-level agreements (SLAs).
What we wanted
Sharing design
That’s the first lesson, especially for smaller projects with smaller budgets: be clear with yourself and with clients upfront about design dependencies between the mothership and the subsite.
We reached a compromise that didn’t involve spending too much on template re-working by the developers (DNA Design). The Tribunal site now has obvious SportNZ.org.nz origins, but is distinct enough to please the client.
Sharing taxonomy code
Tribunal Decisions areaLawyers are a key audience for the Tribunal site; lawyers love taxonomies and searchable databases. It soon seemed a no-brainer to the Tribunal that we were able to make the decisions sortable by violation type, sport and other criteria.
The subsite arrangement made this fairly easy, as we were able to adapt and re-use much of the tag-based system created for SportNZ.org.nz's Managing Sport database, which is a sports sector knowledge area. This represented real value to lawyers and other users of the Tribunal site. Feedback from the Tribunal has been excellent.
It’s notable that we were able to deploy a major new feature late in the day and on a tight budget, which is largely down to good developers and easy code sharing between sites. On the other hand, things are easier with early planning. We ran an Agile-ish project, with frequent re-prioritisation of the backlog, at least later in the project. Even so, I’d recommend identifying candidates for code sharing before you start, even if it’s a restrictive brief such as ours.
