In honor of Ada Lovelace Day, I'm giving my blog some attention today. I recently re-themed it with a customized version of AdaptiveTheme Sky. It's finally responsive (go ahead... try it). Hooray! Which brings me to the topic of responsive, on which I've been brewing thoughts for a while.
It's hard to do anything in web design and development right now without hearing the term "responsive design" until your eyes glaze over. For anyone who needs a primer, I like this one from Treehouse. Responsive is a great concept. An increasing number of people are surfing on phones and tablets, and they expect to be able to do almost anything on their devices that they can do on a desktop. There are use cases where developing a device-detecting mobile site or an app is the better way to go. But much of the time, building one website that can adapt to different screen widths, using media queries, is a very elegant solution.
So why are so many nonprofits still building non-responsive sites? I build new Drupal sites for nonprofits for a living, and I've yet to have a project that has been able to support what I'd consider to be an excellent responsive design process. Sometimes, an org will initially say they want responsive, and then change their minds later in the project. Why is this? I've observed a few reasons.
- Responsive design needs to be done well. If designers haven't learned responsive design concepts and techniques, then it can be difficult or impossible to just "make a desktop design be responsive" and get good results. I know many good, professional web designers who don't yet completely have their heads wrapped around responsive. This is in part because....
- Responsive is still a moving target. Best practices and standards for responsive are emerging. Devices are evolving so quickly that it can be very hard to keep up. Which brings me to my next point...
- Good responsive takes time and money. Although I think that, ultimately, responsive site building will become business as usual, right now it's not quite there, and so going there requires at least a little extra time and money. Orgs on budgets with little wiggle room may discover that they can't afford the extra design time it may take to handle mobile user scenarios, or they can't afford a designer with responsive design experience, or they don't fully understand how much they should be prioritizing responsive in their project budgets. This becomes a vicious cycle of sorts.
- Users don't like it. Sometimes I'll set up a responsive demo for an org, and they will tell me that they don't like that the site changes on their phone. Instead, they prefer the "miniaturized" version that they can pinch and zoom to navigate. I get this. I've had the experience of having designers and developers make assumptions about what I want to see on my phone, and they give me responsive version that's seriously lacking. I think that all ties back to my first bullet point.
As responsive and mobile-first design strategy concepts mature, I think all of this will become easier. But what the heck do we do in the meantime?
When my colleagues and I start a project, we take a good look at an org's Google Analytics numbers. Inevitably, they show a shift toward moble that's increasing exponentially every month. We use this as a chance to discuss whether or not it makes sense to prioritize responsive design in the budget. If other goals need to come first and the money isn't there, I've been building "non-responsive" sites on a base themes that are responsive-ready. I disable the responsive parts of the framework, but the framework is still there. If more funds turn up down the road, and/or users start complaining about navigating the site on a phone and responsive becomes a priority for the org, then the code infrastructure is ready and waiting for a good designer and coder to make the needed adjustments. This is far from the ideal design and development scenario, but right now it's sometimes the best we can do.
These are my favorite responsive Drupal base themes. Even if you're not using the responsive features, they're all excellent base themes for other reasons: they're HTML5 and SASS-compatible. They're all heavily used (on tens of thousands of sites, at least) by the Drupal community, so there's a lot of documentation out there of their issues. In all of these themes, there's a place in the admin UI where you can easily disable their responsive features.
Happy Ada Lovelace Day!