Mobile Commerce

Be kind, RWD

The core tenets of RWD are sound: a fluid, nested grid of objects that all flow and resize beautifully as the client screen is big or small, oblong or wide.

Remember the good old days when all we had to worry about was IE6?  Those of us coding sites in the real-world have had the same problem to solve for decades: Will the page look right for everyone?  Well, in 2013, yes, web developers can now expect a computer’s browser -- and certainly a mobile browser -- to run whizzy, consistent HTML5.

Thank you users-around-the-world for updating, but now we have hardware problems.  Tablets, phablets, that Z10, and new, weird devices coming out ... often.  It’s a whole new diversity problem: lots of devices, screen sizes, screen densities.  And so, new thinking -- or at least a new vocabulary -- on how to handle them all.  Last year’s favorite methodology was “progressive enhancement” (which dates back to 2003), this year, it’s “RWD” or “responsive web design,” an absolutist take on methodologies whose roots go even farther back.

Ages ago, we made HTML tables that were 90% wide and centered them to look nice on little laptops, as well as bigger desktops.  We nested DIVs, each sized with percentages.  That was when back when Snoop Dogg asked us to Drop It Like Its Hot.  Now he’s called “Snoop Lion,” and we are asked to call these same techniques “Responsive Design”.  Both names are catchy, but it’s essentially the same stuff.

Who doesn’t want their site to “respond”?  Responsiveness is always good.  The term suggests you can rely on response -- on responsiveness even -- just by following its methodology.  And the word is already part of your hope for internet: server response time, user response, etc.  Conflate the emotional and technological appeal, and you have a meme in the making.

The core tenets of RWD are sound: a fluid, nested grid of objects that all flow and resize beautifully as the client screen is big or small, oblong or wide.  In RWD, all the HTML5 code needed to run on any size screen is sent over by the web server.  The code senses what type of screen its running on (size, density, colors) and rearranges its text, buttons, all the screen elements really --  if you do things right -- to provide a nice display using Javascript and CSS.  All this happens on the client.  The theory goes that you only need to write one version of the code for all screens.  In practice, there’s little room for error in such complex code.  (“Jenga!”)

And what a mass of code it is.  Enough to accommodate all possible outcomes.  The élite of the technique can produce results both subtle and elegant.  For them, the interface shifts and morphs effortlessly, dancing from screen to client screen.  For mortal engineers, the vision, the genius really, that is necessary to visualize how the code will flow to fill varied spaces is rather elusive.  And the results can be disappointing:  behaving more like and advanced game of Jenga than an advanced programming technique.

Alternative ways to develop across devices vary from a hedging version of RWD called RESS (RWD with Server Side components) that tried to reduce the amount of code you throw over the wall  by sending only what the requesting device actually needs.  But isn’t that cheating for the RWD crowd?

For those organizations that have Michelangelos on staff, so-called responsive design may be a good option.  For real-world companies, and enterprise IT departments, straightforward languages that emphasize simplicity and power might be a better choice.

Want to take your site to the next level?
Join the Layer0 Newsletter for the latest updates on performance.
Thank you! You've been added.
Oops! Something went wrong.
Thanks for registering, you're being redirected!
Oops! Something went wrong.

Don't wait another second. Go instant.

Get started in seconds