Responsive Web Design (RWD) has been spreading through the Internet like wildfire, and the trend is easily understood.
It promises quite a bit, such as the ability for publishers to create content once that will visually reflow appropriately for all devices. It also promises to capture more viewers as the mobile market continues to grow.
However, a move towards RWD is not the immediate no-brainer that many would make it out to be. The technology itself is quite powerful, and because it is built around modern-day Web standards, it is an overwhelmingly positive step in the right direction for the industry. However, there are definite business-oriented caveats, the first in terms of preserving the integrity of quality content, and the second in evaluating mobile apps as superior value proposition.
But there are other complications, notably the technical business considerations around the move towards responsive, and whether it’s the right move from a publishing standpoint.
The days of large-scale bespoke content management Web development are dwindling. A majority of publishers have shifted to choosing existing platforms and customizing them. These platforms come in a variety of sizes — from consumer friendly ones like Drupal (powering The Economist) to more enterprise-oriented ones such as Escenic (powering The Telegraph). There are hundreds available, and knowing their capabilities and shortfalls will help decide whether the move towards responsive is a smart one.
Ultimately, these platforms are the reason why it becomes easier to develop for the Web, as they have plugins that can be added on to extend existing functionalities, such as a plugin for social integration or a plugin to display slideshows of images. Likewise, some platforms may have a "responsive plugin" that makes it easier to develop responsive layouts. However, for platforms that don’t have such plugins, the move to responsive can be an excruciatingly painful one that forces a software team to bend backwards to accommodate the varying layouts for responsive design.
From a technology standpoint, RWD affects the software lifecycle and the timelines for going live with a site. The math is relatively simple: The average responsive website will have at least three separate layouts — one for laptops, another for tablets and a third for smartphones. As the screen size of the browser changes, the content should fluidly snap to display optimally for the device.
While the development phase of a responsive site should take roughly the same time as that of a non-responsive site — the design phase definitely will not. A concerted design has to be mapped for each layout so that the site knows how to position every element. This requires thinking through each component, whether it is the menu navigation, a streaming media player or the search box, to ensure each has been thought through at varying sizes and dimensions.
From this standpoint, well-built responsive sites treat the design phase with the utmost care because each layout can potentially affect the other, ultimately requiring the team to spend more time around getting it right.
The beauty of the modern Web comes from the interoperability of so many services. Integrating Facebook commenting, using Google Analytics and implementing Brightcove for video streaming are just a few examples of how sites can extend their own functionality without having to build from scratch.
These various extensions are extremely helpful, but at the same time, have to be treated with caution. And while the aforementioned features have relatively strong support for handling RWD, there are thousands of third party tools that publishing sites may use on a day-to-day basis that are not quite ready to handle a move towards responsive.
For example, in Icreon’s work in the media publishing space, we’ve encountered multiple occasions where third-party streaming media solutions cannot keep up with the constant layout resizing inherent with RWD. We’ve also encountered the same when working with current click tracking and heat-mapping analytics tools that a majority of publishers use to gain better insight as to how viewers are navigating through their sites.
While the future of the Web is seemingly shifting towards the responsive route, there are still many tech-related questions that need to be answered to ensure it’s the right solution for one's business. Looking at the big-picture: Are publishers in the position to deal with the timeline and budgetary considerations of RWD? And how does a publisher deal with future-proofing a publishing site for tomorrow based on the limited information of have today?
Ultimately, this determines the move to responsive, and answering the previous questions about platform preferences, flexibility in timelines and ecosystem interoperability should invariably guide the decision to use RWD as the overarching mobile strategy.
*Originally featured on NetNewsCheck.com