Skip directly to content and the Omega theme - getting down to brass tacks

on July 18th, 2011 at 8:40:02 PM

In a previous post, I outlined our experience building a responsive design theme on the Omega theme. Here, I’ll go into some details for those of you who enjoy the technical bits.

Just to recap, in early 2011, Kevin O’Leary, one of Acquia’s UX Jedi, launched an effort to redesign the visual branding of Acquia. By May, the design work was far enough along to allow us to start developing a Drupal theme for a complete reboot of Michael Cooper lead the effort with his team including Mariano Asselborn, Yoni Gray, Rob Loach and Charlie GordonI joined their team for one three-week sprint in order to help them establish the framework of the base theme. 

Selecting’s base theme

Weeks before we started the themeing work for, I had seen Jake Strawn present his work on the Omega theme at the Western Mass Drupal Camp. At the time, I had been working on an HTML5 theme for Drupal and reading about the then-maturing concept of responsive web design. Jake’s work blew me away. It was exactly where I wanted to go with my own theme and there it was, coded and working. 

Months later when I heard about the reboot project in the office, I knew we needed to build it on Omega. The web team, however, had already decided to move forward with Fusion. Fusion is robust, supported and configurable. As far as themes go, they don’t get much better.

So I put together essentially the following arguments to convince the team to switch to Omega.

  1. Omega is built from the ground up following responsive web design principles. This means that it starts with a simple, one-column (mobile) layout and scales up to complex gridded layouts using media queries and
  2. The theme options are accessed through a slick configuration interface. CSS files includes, per-zone grid layouts and a debugging mode are available for tweaking through a GUI.
  3. The Delta module plays nice with the Omega theme giving themers the means to create conditionalized layouts with Features and Context
  4. One of the reasons to use Fusion with Drupal 6 was the tight integration of the Skinr module. At the time this project started, Skinr did not yet have a Drupal 7 release. This eliminated a significant advantage that Fusion had over the still-maturing Omega theme.

Ultimately, we decided to build the base theme (and its subsequent sub themes) on Omega.

Responsive design in the world of Drupal theming

When we started the reboot project, the Omega theme was well along to an alpha release. But not all of the kinks had been worked out. Of the major issue we ran into, here are a few:

  1. Dealing with Internet Explorer version 8 and earlier. These versions do not recognize @media queries.
  2. Dealing with the Windows Phone browser that should ideally have a mobile layout. Because it uses an Internet Explorer version 6/7 hybrid browser, code to deliver a desktop layout experience to IE7 incorrectly serves a desktop layout to the mobile phone as well.
  3. Overriding multiple levels of stylesheets associated with specific media queries in several layers of sub themes (we had 4 in our architecture).
  4. Establishing adequate hooks for theming.

None of these were simple problems. Let me provide some detail around the first to illustrate what I mean.

Internet Explorer version 8 and older do not recognize CSS 3.0 @media queries. To be fair, most older versions of browsers do not recognize these queries, but at the moment, any major browser other than Internet Explorer supports @media queries at least two versions back.  And these browsers have a higher rate of users updating to the current version. This means that one of the key issues with responsive design is dealing with Internet Explorer versions 7 and 8 (6 if you’re unlucky).

Scott Jehl of Filament Group has developed a javascript polyfill called Respond.js that enables min- and max- media query conditions for Internet Explorer 6-8. This fantastic solution would not work with Omega. The Respond.js script requires coders to put the @media queries in their CSS stylesheets, not in the @import calls that load those stylesheets. Drupal uses @import calls to load stylesheets precisely to get around Internet Explorer’s 32 stylesheet limit (oh delicious irony!). 

Several other IE @media query polyfill solutions exist, but for one reason or another, none of them would work in the context of the Omega theme and Drupal. So it came down to a home-grown solution.

For the IE 7 and 8 problem, Sebastian and Jake worked out a way to deliver the normal.css stylesheet (for viewports at least 980px wide) to Internet Explorer versions 8 and older. Although a simple problem with just one stylesheet, this issue was compounded by the sub-theming capabilities of Drupal. The Omega theme as to deliver all the normal.css stylesheets from a theme and all its sub-themes in the correct order in the DOM.  It took a little less than a day from when we first identified this issue to a working solution in the Omega repo.

Needless to say, I’ve never been so impressed by the speed and skill of coders as I was with Jake and Sebastian. 

Responsive design is not easy

The right way and the easy way are often different ways entirely. This is very true for responsive design as I came to understand through the inaugural development sprint and through observations of the network team’s subsequent efforts to finish out the project. I remain convicted that responsive design is the standard by which all future web development will be evaluated - especially as the ecosystem of devices continues to fracture. I caution, however, that a paradigm shift in the architecture of front end interfaces requires a concomitant paradigm shift in a coder’s understanding of front end development. 

Responsive design starts not from the standard dimensions of design for desktop computer (i.e. 1013px max with a fold around 600px), but from the content - the raw, unstyled HTML document.  It is a happy coincidence of recent web history that anyone accessing HTML documents was mostly likely at a computer with a screen of sufficient width and height to support multi-column layouts. The multiple column layout worked well for designers making the switch from print design to screen design as well. A main content column with a couple sidebars has analogs in magazine and newspaper layouts.

Starting from the raw, unstyled HTML document requires both designer and developer to consider how a page looks through a spectrum of device viewport sizes: from tiny mobile devices to larger format screens. For a designer, this might mean that he needs to create at least 4 versions of the same page at different widths. For a developer, this might mean she needs to style the same page across 4 stylesheets, each subsequent stylehseet building on and overriding styles from the previously loaded sheets.

For example, in the theme, we have 4 stylesheets:

  1. small - 0px to 740px wide
  2. narrow - 741px to 979px wide
  3. normal - 980px to 1219px wide
  4. wide - 1220px and wider

The small stylesheets contains all of the basic typography as well as some basic layout styling. The narrow stylesheet assumes a columnar layout and optimizes styling for tablet-sized devices. The normal stylesheet optimizes styling for desktop screens. The wide stylesheet optimizes for large-format displays. In an instance when the viewport is larger than 1220px, all four of these stylesheets will be loaded into the browser and will have effect. In an instance when the viewport is smaller than 740px, only the small stylesheets will be loaded and take effect.

What we discovered during the reboot project is that this added flexibility translates into increased design and development time. One could estimate the increase around 3x of the normal development time for a project. The benefit of taking this extra time is a robust and flexible theme that will remain relevant for a long time as new devices come to market.

Another consequence of spreading the styling of a web site across four conditionally-loaded stylesheets is the skill required of the developer to place style declarations in the right sheets. Personally, I found myself moving large chunks of code around in my stylesheets (multiple hundreds of lines) as I came to better understand the behavior of a responsive design theme. Most often I was moving styles from the more specific sheets (normal and wide) to the more general sheets (small and narrow).  Given pressures to get a project done quickly, stylesheets for responsive designs quickly devolve into unoptimized tangles. 

Lessons from working with Omega and building a responsive design theme

The initial release of uses the Omega theme to deliver a desktop-optimized experience. The pressure on design resources, the extra time required to develop a responsive theme, and the lack of familiarity with the techniques of this new approach caused us to delay the implementation of a fully responsive design until Phase 2. 

Even with the trade-offs we accepted to meet time to market, we have the following benefits at the end of Phase 1 because we leveraged the Omega theme:

  1. We were able to easily configure the theme to just render desktop-optimized layouts, essentially hiding the mobile-optimized media query matching.
  2. The responsive design capabilities of the theme are still present. We can now very easily build out a mobile-optimized component of the theme and push it to production without rearchitecting the theme.
  3. Omega’s integration with the Delta module means that if we need a mobile-optimized page or set of pages, we can create a Context and Delta combination for specific URL paths that enables small screen matching matching media queries across constrained portions of the website.

We took the following lessons away from the reboot project and our experience working with the Omega theme.

  1. Responsive design is the ideal state of front end development. Given the resources and the talent, all work should be going in this direction.
  2. The Omega theme is the current state-of-the-art for responsive design on Drupal; it’s a model for other CMS’s as well.
  3. Developing a responsive theme requires more resources - time and skill.
  4. A development team should either be trained in the techniques of responsive development or committed to establishing them in their practice.
  5. Designers must be involved in establishing the look and feel of pages for all viewport size buckets that the code will target with the @media queries.

We at Acquia are taking what we learned in this project and applying the lessons to the work in our pipeline. We’ve always had passion for incredibly web experiences. Now that we have powerful tools like the Omega theme to let us build even better ones. 

Many thanks!

All of the credit for the coding and implementation of the amazing Omega theme goes to Jake Strawn and Sebastian Siemssen (fubhy). These guys were phenomenal. In the three weeks I was working on the theme, they put out five major releases including the first alpha release. Often times I’d report an issue to Sebastian and it would be resolved and pushed to the repo in under 10 minutes..and this at 7pm EST and Sebastian over in Vienna, Austria!

The lion's share of the Acquia theming work belongs to Michael Cooper's team. It's one thing to put together abstract stylesheets, but the details, those persnickety, endless details are what front end design is all about. The Acquia Network team performed the magic of updating reams of legacy pages to a drastically new theme. I hope I get to work with them again soon!

I am thrilled that I had the opportunity to work with Jake and Sebastian putting the new theme together. It showed me that Drupal not only remains relevant in the current world of web development; it also continues to establish the definition of best practice in emerging front end development techniques.  

Post new comment