In the web design/development community, there’s been a lot of energy, excitement, and critique around responsive design. Responsive design is essentially the pracice of building a website from the perspective that it will be viewed across mobile, tablet, and desktop/laptop screens, with the (usual) approach of targeting the leveraging of CSS’s media queries. There are positives and negatives to this approach, and indeed, its something that can add some considerable time to the building and testing phases of a project. However, the results – having one website that adapts its content display on the basis of what the device, device’s screen/resolution, and browser capabilities – is an attractive proposition to other routes (building/managing multiple websites, dealing with User Agent scripting, etc.) for many.
Going down this route of responsive design, there’s a fork in the trend when discussing responsive design. Specifically, how does a developer manage responsive design when pieces of the the website are driven by scripting and dynamic generation from a server (responsive design leans heavily towards the browser/client making the decisions towards the display). I saw this linked on Twitter last week, and its probably one of the better tutorials on the subject of RESS (Responsive Design w/Server-Side Components). Here’s a snippet:
…With this setup we have two sources of information about the browser. Modernizr is a feature detection framework that makes it easy to detect browser features. It simply runs a test in the browser to get a boolean answer as output: “does X work?” and the answer is mostly “true” or “false”. The beauty of this is that it works on all browsers, also those that are not released yet. But it does not have much granularity, and the capabilities that are available is limited to what is possible to feature test. Examples of features that are possible to test include boxshadow, csstransitions, touch, rgba, geolocations and so on.
Device detection on the other hand, is something different. It all happens on the server and it’s a framework that analyses the HTTP header of the device. It then looks up in a database of known devices and return a set of capabilities for that device. The beauty of this is that it’s a database of information that is collected and maintained by humans and it can hold incredibly detailed information about capabilities that is currently impossible to feature test. Examples include device type (desktop, TV, mobile, tablet), device marketing name, video codec support and so on.
The downside is that User Agent analysis can go wrong some times and many devices tend to have a non unique UA string or to fake the UA string, but using a framework will minimise the rist of false detection. Device detection and feature detection cannot really be set up against each other as they are not two sides of the same coin…
Responsive design is something that’s been considered for MMM (given our content focus). As of now, we aren’t leaning towards that direction. There are things we have been learning from responsive design, and especially this tutorial given its server-side focus, that allows us to consider tweaking potential new routes for creating device and context-respecting content.
If you’ve gone the route of starting or implementing a responsive website, what are some of the challenges you’ve run into? Or, if you’ve visited a website that says it has employed responsive web design principles, has the context of how you wanted to use the site been lost or accented in that approach?