Responsive: A Harrowing Meditation on the Brutal Realities of Web Content Organization, in 5 Acts
Act I. The Imprisoned Angel: Fluid Grid Stage
It comes suddenly and without warning.
You’re in one of your 500 daily meetings, twiddling your thumbs and minding your own business, when one of those pale, little web developers on your team raises his timid little head and mumbles that we should consider making our site “mobile friendly.” “iPad compatible,” he says. “Or, you know, not-look-like-shit-on-everything-but-a-desktop.” In other words, “responsive.”
Everyone in the room immediately jumps at the idea. Responsive? I know that word! Paul Irish used it once in a blog somewhere! I heard it cures cancer and increases page views by 1.5 jillion percent! Global warming will cease to exist because of it! Hipsters will spontaneously evolve into puppies! In fact, if we make our site fully responsive to tablets and handheld devices, fuzzy kittens will upload adorable videos of themselves to all of the rooms in the Internet and our lives will be covered in cuddles!
During the dance back to your desk, you excitedly think: Sure. Why not? How hard can it be?
And thus begins the first act of a not-so-long story on how the conversion of a full-fledged company website can be both unbelievably complex and wonderfully exhilarating.
Hello, world. I’m a developer on Zendesk’s marketing-engineering team. Over here at www.zendesk.com, we have a site with over 3,000 pages of unique content. Our team of two is about to make all of those pages viewable on all mobile devices. Since I’ve already spent most of my allotted word count on the intro above, I won’t spend much time on the definition of “responsive” and what specific code snippets you need to implement it. If you’re more interested in that, I’d suggest going here or even here. For this post, I’m simply hoping you’ve got a basic understanding of what’s required to run a website and the patience to follow along.
Because our team loosely engages in Agile software development, we’ve gone ahead and conceptually split our responsive revamp into five acts (or “sprints,” if you prefer strict Agile terminology):
Act I. The Imprisoned Angel — Fluid Grid Stage
Act II. City of Blood — Content Killing Stage
Act III. Turning the Tide — Testing Stage
Act IV. Fall of the High Heavens — Deployment Stage
Act V. The Light of Hope — Enhancements Stage
We run through these acts several times for each site section, each of which is a grouping of similarly laid out pages and/or modules. Our natural order goes like this: pages with the least visits are converted first, while heavily visited pages are converted last. This ensures that we’re sufficiently warmed up by the time we get to the important stuff. Also, nobody on our little engineering team is actually using the title of an act to describe what they’re doing — because that’s just plain silly. Illegal Trademark Usage Disclaimer: The names of the acts have most definitely not been stolen from a popular video game.
This all sounds grand in theory. But when we’re over in real life, our thinking shifts to the actual practice. Here in Act I we need a grid, or some form of sanity to keep those pesky designers in line when they try to design outside the box. So, do we use a pre-built responsive grid framework? Do we Bootstrap our site down in leather binds or whip it into submission with Gumby until it’s nothing more than a beaten Skeleton with a withered Foundation?
Don’t get me wrong, pre-packaged responsive frameworks like the aforementioned Bootstrap, Gumby, Skeleton, and Foundation are perfect for brand new websites with few pages and clean slates; websites that can indulge in mobile first responsive plans and build their layout fluidly from the ground up. Our website, on the other hand, is well-established in the community. He’s a mature chap who enjoys a good scotch and some fancy tobacco in his pipe while entertaining his many visitors per day. In other words, if we did use a framework, we’d need to add all of their classes in all of our templates, remove any unnecessary styles, scripts, and features packaged with the framework, and refactor all of their CSS to fit our codebase.
That will not do for our Zendesk.com. But what other options do we have?
Well, just when you think all is lost, Susy grid comes strutting through the door. Well, not strutting exactly. She’s certainly not conceited, and she would never boast about her fine assets. In fact, you’ve probably never even heard of her. Susy is a fluid grid used for responsive layout. It’s precisely what you need and nothing more.
The creator of Susy grid, Eric M. Suzanne, says it best:
“Susy doesn’t make any effort to cover all your needs. There is no styling help, and no attempt to push you in a certain direction. Susy was built to handle one repetitive task and handle it well. It doesn’t care how you work or what styles you want over the top of your grid. It’s built for flexibility–a simple tool that you can use to create the base structure of your site. Nothing more.”
Thanks, Eric. Sweet hair, dude. Anyways, for zendesk.com, Susy was not only super slim, easy to install, well documented, and completely customizable, it was seamlessly compatible with Compass and SASS. This was absolutely dandy, since that’s exactly what we use for our CSS pre-processing.
Thus far, Susy and Zendesk have been getting along magically. We’ve got our site chrome, site map, header, footer, resources page (plus all of its children), blog (and all of its kids), contact page, search widget, old tour page, home tour, special landing pages, and all of our single modules ported over to full responsiveness. And we’re pretty damn optimistic about the remaining pages.
And with that, Act I has been triumphantly conquered. See you in a few months with Act II.