I recently had a chance to discuss responsive web design with a Drupal developer at the vanguard of this emerging standard, Jurriaan Roelofs. Jurriaan, based in Utrecht, Netherlands, is the author of the responsive base theme Arctica and its companion theme extender, Tundra. Here's Jurriaan on responsive theme design, the challenges facing Drupal and what he thinks the future has in store.
Q: When did you first get into responsive design and decide to use it in a Drupal theme?
I'm not really sure when exactly I learned about responsive design, but it must have been around the time the technique was covered by AListApart. From that time on the technique had a place in my mind but for long I didn't do anything with it.
I think I started playing with media queries in the summer, and then decided I should start implementing it on my premium Drupal themes. That's when I started evaluating the status quo.
I looked at AdaptiveTheme, but decided it did not give me enough flexibility. I looked at Omega, and I just didn't agree with the architecture. I need something that makes my life easier, not more complicated. I think Omega tries to do too much and as a result of this it also put a performance penalty on your site. I recently did some testing and Omega made my test setups ~10% slower while most base themes were only around 5% less performant than Stark. (Stark is the baseline test).
Image: screenshot of Arctica-based theme, Respondr
For these reasons I decided to come up with a new system that meets all my requirements:
- Makes the difficult task of responsive design easy, by providing intuitive interfaces for block and layout management.
- Provide a lightweight solution. This is why I have Tundra, the base theme extender, in a separate project. No need to load all those features in a base theme.
- Provide a platform that is easy to extend with features, so that the project can respond rapidly to changes in the environment.
- Respects a design's grid system by supporting fixed, responsive gutters.
I reckoned this project was absolutely necessary for my premium themes business to keep existing in 2012, so I worked full time on it for a span of about 2 months. Then more time was spent testing the framework with some real themes, and facing new responsive problems.
Arctica now automatically takes care of a lot of responsive design problems like how it's cleverly using box-model:border-box to allows images with borders and padding to fit in a responsive grid system. Or making jQuery cycle compatible with a flexible container. It's still Wild West in the responsive design field and there's still a lot of new ground to be covered.
Q: Can you talk a bit about the relationship between Arctica and Tundra? How do they complement each other?
This one is difficult to explain. It's kind of unlike any other base theme. I'll try to define the 2 themes and explain their roles:
Arctica base theme role:
- To provide a framework for future-friendly, mobile friendly website development.
- To save theme developers time by providing proper HTML(5) markup and a full CSS Reset, including optional removal of Drupal core styles. Also, to optionally save even more time by having a set of optional style kits for elements that don't always need a unique design, like tabs, breadcrumbs, pagers, messages, forms etc. ie the Arctica visual bootstrap, which is inspired by Twitter bootstrap.
- To make the theme developer's life easy by providing a framework that makes it possible to use CSS3 styling like gradients and box-shadows in internet explorer. This is perfectly demonstrated by the TouchPro theme, which uses CSS3 for nearly all its visual effects.
- To provide a graphical user interface to themers and site builders, for managing the overall layout, the placement of blocks, the handling of responsive media queries and more.
In summary, Arctica operates mostly as a theme engine, it provides infrastructure for themers. It's a lean and fast platform to build on.
Tundra's base theme extender role is to provide integration with 3rd party libraries that are part of the theming layer like jQuery cycle, FlexSlider, Sooperfish Dropdown menus, Google Fonts, etcetera. Tundra not only seamlessly integrates these libraries with the theme, it also provides a GUI to their options and features inside the Arctica configurator (the theme settings form).
In summary, Tundra is a package you can optionally use to extend Arctica with awesome jQuery features and integrating custom typography. Of course you can also hand-code these features in your Arctica sub-theme but it's all about saving time.
Image: screenshot of Arctica-based theme, Touch Pro
So if you just need to build a sub theme that's simple, clean, lean and mean, download Arctica and use Arctica as your base theme. If you want a sub-theme with the jQuery features that Tundra offers, download both Arctica and Tundra and declare Tundra as your base theme. Tundra will automatically load Arctica and your sub theme will get the cumulative power of both projects.
Q: Arctica depends on the Skinr module and like a lot of other contributed modules, Skinr has lagged a bit behind the release of Drupal 7. In fact, it's still an alpha release. How has that impacted work on Arctica?
Fortunately when I started working on Arctica, Skinr was already kind of working. It didn't have a release yet but it seemed to work OK. When I came to the point I had to think about layout management in Arctica I found out that the Fusion team had forked Skinr and included it into their "proprietary" module Fusion Apply. I don't think this was a good move. This means that Skinr users don't directly benefit of the work that's put in Fusion apply and vice versa.
Therefore I started talking to Chris of Gravitek Labs about their plans with the module. He told me the Fusion guys never even talked to him and I think he was also displeased about the fork. Chris assured me that he and Bala would collaborate with me on getting a release out for the Skinr module and they were prepared to help me get some ideas into the module that were necessary for making Skinr media query-aware through integration with the theme settings.
In the end this worked out fine and together we got a release out. By together I mean that I spent a lot of time writing a big patch with the functionality I needed and then their awesome backend developer Bala proposed a different patch that was only like 10 lines of code and did the job better than my 100 lines of code.
Q: Moving away from themes for a bit, what is the biggest issue you see facing the Drupal community over the next year or so?
Probably the next year Drupal will have few worries because it's rise in popularity seems to be unstoppable for now. I think we need to worry about the next 5 years though. With the upgrade from D5 to 6, upgrading was pretty easy. D6 to D7 was messy. I upgraded sooperthemes.com recently and it was a big mess, mostly because the changes in tokens meant I couldn't use Pathauto and Taxonomy exactly the same way as in D6. And some modules aren't updated yet so I lost some functionality.
However, with what we're doing in Drupal 8 the upgrade path will be far more difficult, for themes and modules alike. The community will really be put to the test. Other software projects make backward compatibility a priority but we chose the opposite: sacrifice backward compatibility for agility of the projects core. I'm in favor of this approach, it makes Drupal the powerful application that it is today, but I also see problems.
Modules don't get updated, code isn't portable to the next major Drupal version and updating themes can be a lot of work. Drupal 6 has some awesome distributions, I personally use Open Atrium and Acquia Commons. Neither of these projects can be updated to Drupal 7 now because it's just so much work to port all the code over. I'm worried what will happen to the Drupal 7 distros, modules and themes we build in the next years. when Drupal 8 comes out they will be even harder to port.
Q: What's on your wish list for Drupal 8?
As a themer I have my hopes up for Drupal 8. We're going to make Drupal 8 an HTML5 application. This doesn't just mean we get new tags, it means the whole theming system needs to get analyzed and adjusted to produce a correct HTML5 DOM outline.
This means we have the opportunity to improve all markup and generally clean up the code. It also means we're going to make all Drupal output semantically correct; something that I bet is on the wish list of many front end-minded Drupal developers.
The Mobile initiative looks great as well, admin_menu doesn't really work well on my iPhone. I saw Lewis is working on some mock-ups that look much easier to use, although maybe not quiet as fast as admin_menu.
I'm also excited about Jeff's core initiative that I'm in, although we're kind of lagging behind on schedule.
So apart from that front end stuff I'm also expecting a lot from the configuration management initiative. Configuration management is something we really need . Being able to do 1-step builds in multiple environments is something that big software companies take for granted but we often have to do manual stuff to stage new features or new content. Or write really complicated build scripts, thus defeating the purpose of building a build script (saving time).
A Final Word...
I want to thank Jurriaan for taking the time to share his thoughts on responsive theme design and what's happening in the Drupal community. I highly recommend you check out Jurriaan's work on Arctica and if you're looking for a commercial solution, sooperthemes.com is where you can check out some of the great options he has available.
