Mobile is becoming an increasingly important channel for brands to engage their customers over. The consequent development challenges of providing mobile experiences for the huge number of different device specs has, over the past few years, sparked interest in responsive development methodologies.
Brand consistency: By applying these popular web technologies to adapt a single site to different device contexts provided a more consistent experience when viewing the website on either desktop or different mobile devices. With one experience optimized for different devices it helps companies maintain brand consistency. In addition by maintaining a single URL, there is no need to re-direct users to a separate mobile site, again, in theory, improving the experience.
Easier maintenance: A single website with one code base and a consistent content flow it was seen as a way to avoid the accretion of complicated siloed code and bloated code libraries. For organizations where content needs to be rapidly and frequently updated such as news and information providers this was seen as a boon. Having one site also negates the need for additional sites and their associated certifications.
So far so good? Well, sort of. While RWD offered many benefits there were also drawbacks. It can be an expensive and resource intensive method often implying more effort to adapt an existing desktop site than would be needed to redevelop it from scratch.
Focus on the content: By utilizing a single site, developers and collateral owners can focus more on their content production strategy and less on the deployment of it to users. Any update from a Content Management System (CMS) is rendered across all endpoints automatically with Search Engine Optimization (SEO) in theory made easier as a consequence.
Problems in scaling images to fit different screen sizes, load-time issues as whole codebases for device adaption are sent in response to a single mobile user request, and a lack of support in older IE browser versions for web technologies also add complexity.
RWS Moves to RESS
From 2012 the underlying principles of RWD were evolved to include server-side components, commonly understood under the umbrella of responsive with server-side components (RESS) approaches. RESS utilizes a server sitting between the device and the website to send simpler device-specific web codebases as the device browser hits the website, improving performance and maintainability.
While improving performance RESS requires additional backend coding—which RWD’s “load-in-all-on-the-client” approach doesn’t—it may still require enterprises to rethink their website strategy to better serve the right content to the right users.
Where Now For Responsive?
Ultimately responsive methodologies must evolve to meet enterprise’s rapidly expanding mobile requirements. Whereas traditional enterprise mobile applications were fairly binary in nature connecting to maybe one or a few data sources, increasingly they are drawing on diverse cloud and non-cloud services.
The first generation of responsive approaches looked to address how to optimize the viewing experience of the same content on different devices, the methodologies now need to progress to address how companies can customize their content strategy and associated business logic and workflows for individual devices without bloating their codebase. Onward rolls the responsive revolution.