The BBC News’s web development team recently shared their path to responsive design. It’s a cautious, iterative approach befitting the BBC’s broad distribution, but aspects of it may be appropriate for any team wary of flipping scary-big switches while migrating a large legacy site to a more modern front-end.
When the mobile site first re-launched it was … just for devices that we classified as “basic phones”. Towards the end of last year (2012) we felt the site was good enough to make it the primary experience for smart phones, i.e. iPhones and Samsung Galaxies, so we started automatically redirecting those phones from the desktop site to the mobile one.
Sometime this year we will start redirecting tablets to the responsive site, and then hopefully towards the end of the year we will make the responsive site the default version you see on any device.
… We are slowly growing the mobile site into a fully-fledged responsive product to eventually take over and replace the existing desktop site.
Implied by this approach is that moving to a
fully-fledged responsive product involves more than the fairly trivial challenge of adding breakpoints. Designing and building a single site that feels right for users across a wide variety of devices with appropriate layouts, interactions, and client-/server-side components is a lot of work and touches more than just CSS.
BBC News’ iterative-support approach is a great model for exploring the technology and its impacts on user behavior & design, provided your team is capable of supporting two independent front-ends through the potentially lengthy transition - especially if the desktop site requires continued feature development with a separate set of legacy design requirements.
Building a shiny new future next to the deprecating past is standard practice in software development, but it’s easy to fall into indefinite parallal support. Resource-strapped teams tracking early signals to guide where to invest effort are suseptible to abandoning the lower-traffic responsive front-end if new feature development on the legacy site takes priority. The BBC News team addressed this by building new features as responsive components, then serving those componenents within the legacy desktop site. Love it. Shades of Luke W’s RESS.
A fully client-side alternative is to introduce responsive and flexible elements piecemeal, first on global chrome (header, navigation, footer, etc), then responsive-izing individual components and layouts to live within that chrome. This shares some of the BBC News approach’s advantages while keeping your entire team in one codebase, sidesteps issues with canonical URLs and both user-agent & legacy redirects. However, it introduces the potential of design awkwardness to users navigating across content at various stages of migration, can add transitionary page weight when both legacy and new front-end must be supported within the same view, and the conflation of greenfield with legacy concerns slows down development while restricting design freedom.
Challenges aside, the key benefit of these approaches is that they’re a) looking beyond device-specific sites that must be independently maintained in perpetuity with no path toward reconciliation, and b) avoiding the support gradient and usability risks of huge redesigns.