In the last few months we at Joy and Revolution have begun to change the way we design websites. In a nutshell, we have decided that all of our future client projects will be built as responsive websites, as long as there is a valid business case.
We’re pretty excited about this, as it means we can more effectively empower our clients by building them websites that are truly platform-agnostic, meaning they are more accessible for their customers. For many of them, this will go a long way in helping achieve their online business objectives.
Our latest responsive project was a website for our friends at GV Film. With the help of HTML5 Boilerplate, and a sprinkle of Andy Clarke’s 320 and Up add-on, we built a site that can deliver a portfolio of trailers to visitors on desktop computers, tablets and mobile devices, without the site’s content being compromised by smaller screensizes.
Respons-ify a Drupal theme, I challenge thee!
The GV Film site was built on a small CMS called Pulse, which integrates very easily with static HTML and CSS, but when trying to use responsive design techniques on a large CMS like Drupal, there are a few challenges.
A project we are working on for a major London Charity has given us the opportunity to develop a responsive Drupal site as a real world case study. It uses Drupal 6 and the theme is being coded from scratch, using HTML5 boilerplate as a starting template. I will write a more in-depth blog post after the site is launched, but for now I will mention a few issues we’ve come across.
Drupal isn’t mobile-first by default
Drupal’s theming engine hasn’t been a problem, so far. We’ve managed to include the usual API variables and hooks to create and display the theme on various screen sizes using media queries. This was expected; at the end of the day Drupal is just a system that outputs HTML and CSS, so there should be no reason media queries would cause a problem.
What has been a bit of a struggle is getting the CMS to output un-bloated code in its views and blocks templates. Drupal started as an open-source project many years ago and hasn’t yet adjusted to the new mobile-first approach that many are attempting. As default, the system generates many, many nested divs with multiple id’s and classes, which is great for granularity when styling, but not so great when aiming for small data sizes, and quick page loads on mobile devices. Of course, the solution is to create customised template pages for the blocks and views that are being displayed, but this takes time and also adds to theme folder size – meaning the system has to work that much harder to display a page.
Third-party module developers have their work cut out
The beauty of an open source system like Drupal is the availability of add-ons built by developers the world over. Of course, these developers work at their own pace and have their own priorities, so ensuring their modules are compatible with the latest web trends (like responsive web design) is way down on their list. Because of this, third-party modules can output code that breaks a responsive web site.
I had this exact problem with the image module. It extends a Drupal site to allow a single image to be uploaded, and then derivatives of that image to be produced automatically into pre-set sizes. The fatal flaw occurs when the module outputs img tags that specify a width and a height. This, of course, prevents an image from resizing on a responsive web site because the use of CSS’s max-width : 100% becomes overwitten by the dimensions in the HTML img tag. The result is a site whose images are far too large and fall off the side of the page on small-screened devices.
We could re-write the image module to output the images without widths and heights, but that requires time and resources, something that most clients can’t spare. Other image modules, like imagecache, may be more compatible, and this is what we are experimenting with currently.
Changes come slowly
There is a slow rise in development of modules that are compatible with the responsive web design approach, most of them being implemented in Drupal 7. Hopefully, 2012 will see more developers building their modules’ functionality from a mobile-first perspective so that we can continue to empower our clients.