In February I wrote about Responsively Refactoring a Magento site. Since then I’ve had the opportunity to design four Magento sites as responsive from the ground up. This post will go over the structure and principles my fellow UI Engineers and I developed across these sites.

There were two main issues I wanted to solve in the Magento design process:

  1. We were designing new sites and themes based on the default, fixed-width Magento. We were wasting considerable time unsetting the default theme each time we built a new site, and the styles required a massive overhaul to work in a fluid design. We addressed this issue by creating our own base Magento theme, built with SASS, which replaced the default CSS (and as much of the JavaScript as we were able). In this post, I detail the CSS principles we used.
  2. We were increasing our design times, both because of responsive design as well as our push to create more complicated and unique layouts. We needed to keep our schedule manageable and competitive, and we needed solutions that could be extended, reused and maintained easily. We leveraged SASS, Compass, and our own custom mixins, in concert with our newly created base theme to address these points.

 

Structure Revisited

Before I dive into the specifics of SASS, I wanted to revisit the theme structure as it applied to CSS and stylesheets. Previously, I encouraged you to make SASS partials for individual page types. I will amend that and suggest you make folders for each major page type, with several partials in each folder. Keep an eye out for parts you can reuse, such as price formatting, product grid items, page titles, and star ratings. You can include these on a per-page-type basis or in the main stylesheet. This approach is especially useful when you have requirements such as AJAX quick order screens where you need some but not all of a given sheet’s assets in a new sheet.

We use several stylesheets per theme. We’ve done away with separate print and Internet Explorer sheets. Instead we create a base sheet with our compiled frame, theme and common elements, as well as any related print styles. We use a modified version of Paul Irish’s conditional CSS classes to create IE specific rules, when needed.

Next we create stylesheets for products, account pages, the home page, etc. We use Magento’s CSS combination feature to combine these, and to act as a cache buster for when we deploy CSS updates. Using this method, we allow the user to only download the CSS required for a given page view, but spare them the extra HTTP request.

 

SASS to the Rescue Again

SASS and Compass are absolutely essential for a project of Magento’s size. There is an ever growing list of SASS and Compass mixins and techniques we leverage to speed up our design times and provide the extensible, reusable style modules we needed to meet our design schedules.

If you’re looking to leverage SASS and Compass in your own build, I would suggest checking out DEG’s own Simple Icon Font Sass Helper and Compass Helper repositories, as well. These will give you some nice tools to simplify and speed up development. I already covered some features of the Compass Helper repository and the joy of REms in my last post. The Simple Icon Font helper lets you quickly and cleanly use icon fonts in SASS (while you’re browsing our Github account, you might want to look at the Phingento repository for automating Magento development tasks, which is outside of the scope of this post, but still very helpful).

 

Claim Your Inheritance

One great feature of Compass is the ability to share SASS partials between compiled sheets. This means that you can use the same style of inheritance that Magento uses for templates and layout files in your CSS. Here’s an example of what I mean:

Theme1’s config.rb

 

Theme2’s config.rb

 

Using these config files Theme2’s will first look in its own directory for SASS partials. If it can’t find a partial, it will then look in Theme1’s. If you need to replace CSS in a given area, you just need to create that partial in Theme2. There is no need to try to keep duplicate partials up to date with each other. Further, you can bring in partials from one page type to another on a case-by-case basis. Let’s say you’ve already styled pagination on the category product list, but now you need pagination on the account pages. If pagination is in its own partial, you can reference just the styles you need, without bringing in unnecessary product grid styles.

One thing to keep in mind: using this method requires you use full paths when importing partials in both themes; if a partial in css/foo references a path in css/foo/bar, we want to make sure and use @import foo/bar, not @import bar. Even though both versions will work, only the full path import will insure inheritance stays intact.

 

It’s All Variable

We can leverage inheritance further by careful management of SASS variables. I highly suggest creating a dedicated variable partial for each theme. There may be cases where changed colors, fonts or border styles might be the only difference between Theme1 and Theme2, and you can make these changes in one place.

Here’s an example of what that might look like:

Theme1’s variables.scss

 

Theme2’s _variables.scss

 

As long as you’re using SASS variables every time you reference color, you can easily change them everywhere in a theme. You can also leverage darken, lighten, saturate and other SASS functions to reduce the amount of defined colors while still having the supporting colors you need for borders and hover effects.

You can also store widths, fonts, file paths and any other CSS values in variables. You might want to implement a SASS variable naming convention to keep things tidy, and be careful not to tie your variable names too tightly to a given color. After all, you may change your background color from white to gray, and you don’t want your $color-white variable to actually be the color gray.

 

Breakpoints

Regardless of how many breakpoints you prefer to use and how organic you make them, we have created a mixin that helps you manage them.

Our Breakpoint Mixin

 

Assign Variables for Breakpoints

 

The breakpoint in use

 

Using this approach, we can place the selector inside of the query, or we can put the query inside of a selector. This mixin helps keep things tidy, and lets you use your breakpoints in natural positions within your stylesheets. This method will allow for as many media queries as you need, and you can name them whatever you want.

 

Time Comparisons

In the comments on my previous post, a few people asked for a time comparison between different Magento design scenarios. While the true answer is always “it depends”, here’s a rough table based on my experience across ten plus Magento theme designs.

Static Width

Design

Responsive Redesign

Full Responsive Design

Initial Theme

100%

80-150%

140-180%

Testing

100%

150%

150-200%

Modifications to Design

100%

80-120%

80-120%

Creation of Related Themes

80-100%

50-100%

50-100%

 

There is a definite increase in development time with responsive design, especially regarding testing. This time is sometimes recouped during modifications and the creation of related (child or sibling) themes if you leverage SASS and the principles in this post. There is also a correlation between the time involved and the difficulty and experience needed. Each design we complete leads to new tricks and resources we can leverage to increase our development time and quality.

 

Conclusion

We have definitely seen positive results from creating our custom base theme and implementing SASS, Compass and our custom built tools. With the CSS principles detailed here, we have accomplished our two goals; by creating a custom base theme we no longer waste time on the default theme. Instead we develop on a flexible base of reusable style partials designed to be used modularly, as well as to be shared across themes, to reduce the time needed to design, revise and maintain our styles. While we will always be revising our methods and bringing in newer and better ideas and tools, we will likely keep the general ideas in this post into the foreseeable future.

Next time I will be diving into JavaScript and the plugins we use, including how we handle some of the trickier issues with responsive e-commerce builds.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments