Ah, Drupalcon. Three days of panels and BOFs, one Advomatic code sprint, and some very late nights with the Advoteam. Now I’m thrust back into the land of overflowing diaper pails and spaghetti bits everywhere that is work-from-home motherhood. But I promised myself I’d put my DrupalCon notes into a fancy blog post in the hope that others will find them useful (and so I can find them later). Two weeks later, here goes.
This year’s DrupalCon was particularly fruitful for us theme developers. In years past, there hasn’t been much new and shiny for us beyond CSS3 goodies we couldn’t touch because of legacy browsers. But technology is changing, as it is wont to do. We’re seeing a revolution in how we plan, design, theme and QA our sites, thanks mostly to responsive design (and SASS/Compass, but I’ll save that for a later blog post.)
If you need any convincing that the mobile revolution is mandating a change in the way we design and build sites, check out Luke Wroblewski’s super engaging keynote. LukeW coined the term (and wrote the book) “Mobile First” to redirect planning sites for handheld devices first — then for computers — because of the clear trend in how people are accessing sites. A collateral benefit is that by designing mobile first you are forced to prioritize your site’s content — maybe the main thing people need when they go to your organization’s website is how they can help the cause, not a letter from the Board. There were a few “future is now” moments in there too, for better or worse. Do check out his Future Friendly manifesto.
At Advomatic, responsive sites are rapidly becoming the norm, and we’re figuring out best practices as we go. So these DrupalCon sessions were a top priority:
- UX Design For Every Screen
- Rethinking responsive building techniques with Drupal
- Responsive Web Design: The Past, Present, and Future
- A Responsive Project Process
- Creating Responsive and Mobile-First Drupal Themes
There was a bit of buzz around the idea of doing “design in browser” versus in a design program like Fireworks or Photoshop, which inevitably mean a fixed width conceptualization of a site (even if the designer creates versions for a variety of browser widths.) SASS and Compass would give you a leg up to design something quickly directly from your browser, and I hope to address that in future blog posts. However, I tend to camp with those that say that starting from the browser will inevitably stunt a designer’s creativity:
The browser was intended as a delivery mechanism with HTML and CSS a means of describing content rather than defining it (a subtle distinction I know, but an important one). As such the browser lacks even the most rudimentary tools, such as the ability to draw lines or irregular objects through direct manipulation. Instead this process is heavily abstracted through code. As the best design tools are the ones that put the smallest barrier between the creator and their creation (the pencil is a good example of this) designing in the browser adds an unnecessary level of craft to the process. – Andy Budd, Clearleft
I’m not sure whether Photoshop and Fireworks will soon have built-in flexibility, or if browsers will have built-in design tools, but currently neither is a perfect tool for responsive design.
Another interesting approach to the the problem of graphic design for responsive environments is Style Tiles, which was mentioned in at least four of the sessions I saw. It’s a method for designing for a client without creating full comps, somewhere between a “mood board” and a comp. I like that it allows for some flexibility, and look forward to an opportunity to try it out. Another suggestion was designing a few comps for different breakpoints in Photoshop/Fireworks and a style guide — and then move to designing in the browser.
One Drupal module that would help with in-browser design (and makes testing for different displays easier) is the Style Guide module, which generates a page where you can test all common HTML elements for a site, so you don’t miss anything.
There is still a lot of debate on how to handle images in responsive design. While the img {max-width: 100%;} goes a long way, it still means you are potentially downloading a unnecessarily large image on your phone. And unlike CSS background images, img tags have a single, immutable source. The Adaptive Image module for Drupal is suggested, as is Borealis Responsive Images, for creating smaller images on the fly depending on the browser size. It’s a complex issue, and you can dive deeper here and here. For video FitVids was suggested (and FitText for flexible font sizes.)
What about content? While there is this mantra of “mobile first” — designing the site around the smallest of devices first, keeping content super streamlined — there’s another thread that content available to larger screens shouldn’t necessarily be hidden on smaller screens. Mobile users may in fact be looking for a more rich experience, not just the bare bones. So think twice before plunking in a display:none on an entire region. However, I imagine that will probably be a site-by-site decision.
Responsive Design Testing
So testing for all these various devices inevitably will be tedious. I collected a little list of some tools to help.
- Responsive Design Testing Tool – See how your site will look in four different device widths together on a single page.
- Adobe Shadow – plug in devices to a desktop, pull up your site on one, and view it in all devices (no need to surf to it on all devices.)
- Opera has a few cool tools, like the Opera mini simulator and the Opera mobile emulator
- And here’s a comprehensive list of mobile emulators
- The Browser Stack, a cross browser testing tool, just added mobile support
- Mobitest – a tool for testing site performance on a mobile device
And, finally, here’s a collection of fun responsive examples to check out for inspiration.
There you have it. Hopefully something in my extended brain dump will be of use to you!
Watch all Drupalcon sessions here, and fill me in on anything I missed below.