Not a cautionary tale about that kind of RWD antics – the rear wheel drive, V8-powered, rubber-shredding, pony car shenanigans kind – but some thoughts about the increasing power (and pitfalls) of responsive web design.
In this post, I describe two current mobile optimization projects: one where we used RWD, and one where we didn’t walk but ran away from it.
Like 400 horsepower hotrods, RWDs are not always the best tool for the job even though, as with bad-ass, tail-happy rides, enthusiast types swear by their virtues. And 90% of the time, they do what we ask of them, often with a little excitement to boot.
But let’s take RWD for a spin and see how it fares out there on the mean streets of the web. Our two projects – I’m calling them “the daily driver” and “something for the weekend” – highlight the questions you need to ask before you even consider taking an RWD off your designer’s lot.
Project 1: the daily driver
This web site had to be all things to all people: slick and big and graphical on the desktop, small and light and swipey on an iPhone. This is like asking our Mustang to perform double duty as an autocrosser and an interstate cruiser. If you want to perform such disparate tasks of automotive conveyance you will quickly realize that a vehicle competent at one task is likely lousy at another (or mediocre at both, and nobody wants the Toyota Camry of web sites). Unless you were to invent some kind of magical vehicle switcher/transformer device thing. Hmmm…
Fortunately, the industry-best CMS, Sitecore, can run just such a magical switcher/transformer device thing that works great with web sites (and not at all with cars). Big screen desktop (analogy: wide open highway) where comfort and style are needed? Why that sounds like the plush Explorer/desktop version. Small screen smartphone of patchy “4”G service (analogy: a tiny, fiddly intricate parking lot autocross course) where lightweight balance wins the day? That’ll be the mobile/Miata version.
For this project, we chose to take full advantage of device detection to serve up optimized versions (“Devices” in Sitecore’s language) for the users’ most common device types: i.e. desktop computers and smartphones. This involves server-side optimization, and is, generally, far more efficient than RWD. The point to note here, above all else, is that successful server-side versioning of a web site requires a robust content management system, such as Sitecore. That way, we ensure that our client creates content once, and pushes out the results to (potentially limitless) device-customized versions.
Maybe a server-side approach, ideally using Sitecore, is the approach for you. If you answer “yes” to any of the following, that could very well be the case.
Do you need your site to be fast?
Do you need your mobile user experience to be…simple?
Our client needed a real mobile-optimized user interface. Granted, given a whole lot of time (and hoping for the best) it is possible for a RWD setup to jQuery the heck out of a navigation structure and transform it into some kind of ostensibly mobile-friendly list.
That’s a reasonable approach for a simple site or straightforward navigation structure. But our client’s existing desktop site had at least four types of navigation, a level of complexity unsolvable by purely technical means.
Thus, we built out a new navigation control, from the ground up, specifically for mobile. Drawing on the same dynamic Sitecore content that drives the desktop site, our client’s navigation works simply and smoothly… and they will never have the pleasure of dealing with a jQuery developer!
Additionally, we made sure that an oversized image will never be downloaded again. Resizing images on the server-side (or producing graphics with mobile in mind) is a wonderful thing. With RWD, the full-sized image is downloaded, and then (hopefully) CSSed down to size. Three minutes later. After your user got bored already and moved on to Facebook. Squirrel!
Do you need your mobile site to feel like a mobile site?
Native mobile interfaces are almost universally pretty these days (sorry Blackberry users). Mobile users have certain expectations about how mobile sites should feel. For the Android/iPhone/Windows crew, swiping and tapping are expected interactions.
With RWD we could load, say, a “desktop” slider and mobile/swipe-enabled function and only show the mobile to small screen devices. Which is great, but when I resize my desktop browser to the top ¼ of the screen and try to swipe and tap it, I get some very funny looks from across the aisle, and I now have greasy fingerprints to deal with.
Do you have a good content management system (CMS) in place?
And by CMS I mean a CMS, not a blog engine. You may also need a little help from a developer to get things going, but once you do the performance and user experience gains will be money in the bank. Create and manage content in one place, present it in potentially infinite ways for your target devices.
Project 2: something for the weekend
This is one of those web sites a designer hopes will never be seen. You read that right. In the case of a crisis – natural or man-made – our client needs a way to easily update members of the public and media with timely updates. This is like the ultimate collector car, kept under wraps, out of sight. Out of sunlight. Stolen. With 149 jars of Kentucky moonshine stashed in the trunk. Under this scenario, the regular web site would be replaced by a pared down crisis site. In an extreme case, all web pages redirect to the front page with a parsimonious design. Clearly, Sitecore is the correct place to make this switch instantaneously and to manage the content that populates this crisis communication function. Here, we deployed RWD to provide an optimized experienced for all of our clients hopefully-non-existent users. We did so, because we answered yes to the following:
Is the content straightforward and simple?
If there are few interactive or complex client-side functionalities, RWD can make sense. Superfluous code and images are not downloaded, making discrete platform-specific versions unnecessary.
Does a single IA make sense for all devices?
Typically, in the case of a relatively complex site, desktop-centric IA (information architecture) requires serious thought in order to work well on the small screens and low bandwidths of mobile devices. In that case, RWD is often imperfect requiring complex and high-maintenance workarounds. However, in this case, the required navigation was exceptionally simple: a list of three static links providing vital information pulled from the CMS. In this case, a very simple CSS media query makes perfect sense.
Does CSS accomplish the customization required?
As with separate device definitions, RWD allows (theoretically) limitless customization based on screen size. The downside, however, is that each iteration of the site yields a more cumbersome (and larger) CSS file and set of assets. If you are content with a good rather than a “native” user experience, RWD can be a good option. In this case, we defined three “bands” of customization corresponding approximately to desktop devices, tablet devices, and smartphones. In this case, none of the site’s functionality required device-specific functionality or styling which would detract from the primary goal of the site: to provide gravely important information in an efficient manner.
RWD is gaining prominence, and is loudly advocated in some quarters, but it is not the only show in town. Be sure to kick the tires before making the plunge.