Syrupy Responsiveness

In a different lifetime, I remember working at Starbucks at a time the company was shaking things up a bit. In an effort to reduce costs and create more space on the back counters, the company downsized its syrup selection to a modest ten flavors. Those of us that can remember that far back (circa 2003) now relish the days of ordering a hazelnut latte or a valencia mocha without it being a special promotion or holiday. The decision was a little unpopular at the time, but customers loved the speediness and consistency that the efficiency provided.

The same is true with responsive web design. More often than not, the posts I see on the topic are either opinions about the best design approach or a showy piece on how to hit as many viewports as possible. Though they are interesting and certainly contribute to the web community as a whole, I think most of these posts miss the point of responsive web. Whereas one is an extreme towards a one-size-fits-all approach, the other errs on the side of agnosticism to the point of being irrelevant to the user. Instead, I propose a Starbucks syrup approach to responsive design and development.

Understand your customer’s tastes

Now, as a barista I was certainly not on the Starbucks board or anywhere near senior leadership, but I imagine they knew a thing of two about the tastes of customers prior to dropping syrup flavors from the lineup. I’m guessing they poured over sales receipts, surveys and any bit of data they could possibly get their hands on before making a decision.

In the same way, I find it helpful to know a thing or two about the people visiting a website before I determine whether or not a responsive layout is even necessary. Sure, it’s fun to show off your chops and make something that bends and moves when the bottom right corner of a browser is pulled around, but if no one is visiting the site on a mobile device, tablet or anything below 960px, then there’s very little sense in doing the work.

For that reason, I often request access to a client’s analytics account or reports to get a sense for the type of traffic the site attracts. Of course, some clients give me a confused look at the slight mention of “analytics” in which case I try to set them up with a Google Analytics account or a short-term qualitative survey to get the best idea possible.

Eliminate unnecessary options

I love this tweet from Josh Brewer:

Responsive is not simple. It is a chore.

So why make it even harder than it needs to be? By reducing the number of flavors it offers, Starbucks also reduced the number of options for customers to create a personalized drink experience. Doing so not only made the ordering process easier for customers who may have been overwhelmed by too many options, but it smoothed the production process for employees who had to make the drinks.

Until there is a bullet-proof one-size-fits-all way of developing websites (I hope it never happens, personally), it’s virtually impossible to be everything to every person and viewport without a lot of serious tricks, hacks and hard work. And even if you do pull off the impossible, you’re left with a mess of code that is difficult to maintain and probably lowered your hourly rate of return on the project.

Learn what people need from the site and tailor accordingly, eliminating viewports that get little or no traffic in the first place. It’s better to add viewports later than to account for them unnecessarily in the first place. Work smarter, not harder.

Design for the occasion

This has nothing to do with syrups (well, it would be a stretch if I tried), but is worth mentioning because of the hype around whether it’s better to start with mobile or desktop in the responsive design process.

The short answer to me is: it depends.

I was totally on board the first time I heard the mobile-first approach because I love how mobile forces you to get to the core of a site’s purpose before plopping in a bunch of shiny bells and whistles.

But the more I think about it, a mobile-first approach can be discriminating because it puts the needs of one segment over another. The same person visiting a site on a mobile device will probably use it differently on a desktop (depending on the general purpose of the site), because of the context of the visit. Are they on the go and need quick information? Are the in a stationery place and want to have an experience? Are they hanging out on the couch in the mood to consume content? The needs can vary greatly.

For that reason, I feel it’s more necessary to start with the viewport that is most conducive to the primary goal of the site. And if the goal fits one extreme or another, just go with your gut and degin with what makes you most comfortable. No one is going to show up at your door with a death wish for that.

Write opinionated code

I’ve always been a fan of adopting early standards and trying graceful degradation where possible. But I believe that going responsive requires your code to choose sides as far as what browsers it does and does not support. The most obvious example is older IE versions (I’m looking at you, IE8-!) that do not carry support for media queries or HTML5. There are polyfills for that, of course, but there’s no need to bend over backwards for users who are already used to experiencing an outdated and unsatisfying version of the World Wide Web. You probably shouldn’t even be diving into responsive design if a a majority of your visitors are surfing in on IE7 anyways.

Short story: take a side and reward those who choose the same.

Conclusion

I love how responsive design has reinvigorated the web community and created an active dialogue but, as far as standards and best practices are concerned, the craft is still far too new to command a definitive way of getting it done. Until we see a shake-up within the browser community to determine a standard for how pixels dance to the viewport they’re displayed on, it’s best to design for the users and use a process that fits your level of comfort.

✏️ Handwritten by Geoff Graham on May 23, 2012