Making Magento Responsive Using Foundation: Part 2

Our approach to making Magento responsive began with the intention of building a custom responsive Magento website. We ended up building an internal front-end framework built on top of Foundation that leverages SCSS. This provide our team a base responsive theme and one code base for easy upgrading, and rapid development.

Part 1 of our two part series outlines a lot of the thoughts and methodologies around selecting and using Foundation to make Magento responsive.

Part 2 outlines our thoughts and methodologies around choosing and implementing Foundation to make Magento responsive.

2.1 – Yeti
2.2 – Goals
2.3 – Approach – How to Play Nice With Magento
2.4 – Refactoring CSS into SCSS
2.5 – Removing fixed widths, absolute positioning for some things, and “float: right;” for some things + flexible media
2.6 – Setting up Foundation with Yeti

Part 2 – Making our own responsive theme + internal framework – Yeti

2.1 – Yeti

The right approach was to establish a front-end framework of our own built upon Foundation. One that we could improve over time. It would be our own internal product built modularly with reusable bits so that we could focus more on UX and not sweat creating the same solutions over and again.

Yeti-Feature-Small-2

Foundation itself is a forward-looking framework, [which might even be named after my favourite Isaac Asimov series: Foundation, as mentioned in their post A Yeti’s Trek], and we were inspired to name our own internal front-end responsive Magento framework built on Foundation after the mascot that embodies that aim, by naming it Yeti. Plus the yeti character is pretty cool, and Zurb encourages people to play with it, providing .ai and .eps files for it.

2.2 – Goals

By establishing our own internal framework / platform for responsive projects we can save time and effort, creating more time to focus on delivering excellent user experience to help increase our customers eCommerce sales. It also allows for a consistent reference point for our own projects, so that we can improve the platform and even more easily roll-out upgrades for it going forward.

  • From the ground-up, a responsive framework specifically for Magento
  • Mobile-first
  • Modular re-usable components
  • End result in fully responsive Magento base theme

2.3 – Approach – How to Play Nice With Magento

i) I came across an open-source HTML5 responsive Magento theme. Waterlee Boilerplate was used for reference at the beginning of the project for building Demac Yeti into a responsive base template of it’s own. After checking out Waterlee-Boilerplate, I realized it was simply using Foundation’s CSS grid by applying Foundation’s grid classes directly to elements. I realized this was the wrong approach as it didn’t take advantage of SCSS at all.

ii) Waterlee Boilerplate’s method of adding CSS classes to the PHTML files in order to work with Foundation’s grid system was deemed an incorrect approach as it does not support changing the reflowing of content easily. I wanted to have a more modular approach so that we weren’t stuck applying or changing element classes in the PHTML view files every time. The solution was to use Magento Enterprise’s existing CSS classes and to change any column sizes and reflows within the SCSS itself by extending Foundation’s SCSS grid system. This allowed for a more modular set-up, making rapid front-end development more likely.

iii) I felt better about taking this path after reading this blog post: Refactoring Magento for Responsive Web Design, which confirmed that other people had also taken this route to achieve similar goals. Using SCSS, as well as Foundation’s innovative responsive framework for a mobile-first modular approach, were two key factors in making this project a success.

2.4 – Refactoring CSS into SCSS

Building on top of Foundation’s SCSS and JS, the first major task was getting Magento’s CSS into SCSS format. I googled around a bit to see if anyone else had gone that route (but apparently didn’t look hard enough because someone had already done it)

It was great that I went through the process of refactoring it myself as it allowed me to get up close and personal with every line of CSS in Magento Enterprise.

Enterprise default CSS file:

Compact (default format for Magento)
Nested
Expanded

2583 lines
7692 lines
9309 lines

Refactored into SCSS:

SCSS (if it was all one file)

8297 lines

The main comparison above being between CSS expanded style and SCSS style (which is expanded, but in it’s own way).

After refactoring, I preprocessed it and fixed any missing brackets and checked to see that output CSS file matched up (as much as possible) with original CSS file. Of course there are a lot of changes due to the nature of nesting and organizing your styles. At that point I made a copy of the SCSS as a non-responsive version, which we can use for any non-responsive projects while still taking advantage of using SCSS.

2.5 – Removing fixed widths, absolute positioning for some things, and “float: right;” for some things + flexible media

The next step was commenting out most set widths that were specified in pixels. It’s not always the case of course, but for a lot of large elements, they need to be fluid. Same idea for product images. Removing inline CSS in the PHTML was also part of this step, and adding in parameters to ensure flexible media.

Note: This was one of the more challenging parts of making Magento responsive, and it is also the most important step.

The main part of it is making the elements work within a percentage-based grid system (that has an overall specified width); as well as removing any counter-intuitive styles such as floating something right simply to put it beside another element.

2.6 – Setting up Foundation with Yeti

a) Folder structure

Setting up a folder structure that made sense for myself was one thing, setting it up to make sense for others so they could see where things were (or should be) at a glance was challenge in-itself. Separating sections into folders and making smaller .scss partials definitely helps separate your concerns. The primary take-away was having a few files that you would configure at the start of your project and those settings and SCSS variables would be changed across the Magento SCSS.

This is actually something we’ve made some updates to recently. As new responsive design projects came in, we added more devs into the mix which allowed Yeti to evolve over the last few months based on adding new features and moving towards a more straight-forward modular approach.

The gist of it is to have a top-level .scss file that imports the rest of the files including Foundation. Pull in your main configurable styles that are used across all the rest of the templates, such as your fonts, mixins, and colour platte fairly early on. Use the existing Foundation variables and settings inside the Magento partials; and then customize the styles themselves as needed, starting from the higher up files that have the settings.

Ultimately,it’s what makes sense for your team or project, but there should be a clear logic/order to it so that settings and SCSS relating to specific .phtml partials are easily found.

b) Fonts, palette, variables, & mixins

Yeti is now our base responsive theme with many features out of the box, such as a mobile off-canvas menu that uses a checkmark box (no JS needed for the click-event) and CSS3 animations, as well as many mixins to help our developers with pieces of repeatable code. It also provides a structure to build upon.

i) Fonts and font-stacks are set-up as variables, and then pulled into the general files, as well as the Foundation settings.

ii) Same deal with the colour palette, allowing the developer to make slight changes to HEX values in one place rather than across all files.

iii) Foundation variables are extended for use throughout Yeti where possible, and where it makes sense to do so.

iv) Any time you have a set of styles that will appear many times, you can create a “mixin” so that you don’t repeat those multiple lines over and over again. This also helps you keep your code neat and organized in case you need to change something. I find it particularly helpful for sprites, such as when you have social media icons that look the same, but serve different functions (like follow-us in the footer, and share this on a blog post). Using one mixin for both, such as @include socialFacebook; in multiple places is one line and a simple update in one spot (in your _mixins.scss file) if you change your sprite layout.

Here’s an example of a mixin that also includes media queries. This mixin uses Foundation’s grid, and is for a specific reflow, named after how much it would take up on a desktop screen (one third):

A use-case example for this would be a feature box on the homepage of a site that takes up one-third of the grid on small-screen desktop, and reflows to half the grid size on tablet, and then the full-width of the grid on mobile. You would simply add @include thirdReflow; to the style of that particular element or class.

c) Grid & Foundation set-up

A framework leveraging a framework using a meta-language and pre-built options. Below is an example of a three column page layout template, using Foundation’s grid, and specifying reflow points with media queries.

Extending Foundation’s grid and SCSS set-up is by far the most beneficial feature included in Yeti.

d) JS Extensions & SCSS Components – Image Sliders, Product Sliders, Modals, & More

So far, we have included modules and examples for two types of image sliders, and a few other JavaScript components. Some of which are included in Foundation, and we can simply turn on by include the styles and JS files needed.

i) Foundation’s image slider Orbit

ii) WooThemes’s image slider Flexslider2

iii) Foundation’s modal Reveal

There are several more we have in the works, including different types of menus and category filtering.

e) Configurable Options in XML

We’ve set up our Magento .xml files for Yeti so that we can include modular features, that can be turned on or left off as needed.

One example would be extra blocks in the header of a site for calls to action for sales or free shipping promotions.

This allows us to build out certain features as modules for Yeti and then depending upon the features of that site design/build, set-up or left turned off.

f) Pattern Library

Another new feature we’re adding into Yeti to make things easier, both from a design perspective and code-wise is creating a UI Pattern Library that developers will match up with a Style Guide provided by our designers. The purpose of this library is so that once a developer changes Yeti’s (+ Foundation’s) variables and configuration, they’ll be able to see the output of the styles in one place; where they can match up the Style Guide side by side to ensure the right fonts are used, spacing is correct, colours are correct, etc. This will also free up some time doing Creative QA (quality assurance).

The Pattern Library’s output comes from the general settings of the project as well as specific settings for the fonts, colours, and more.

Using the colour palette as a small snippet example from our Pattern Library, we start with the HTML structure:

Then, using these SCSS variables that define our colour palette and a re-usable mixin for the square block style of the palette output:

Interpolation

Using interpolation (see Sass-lang doc here), we can take SCSS variables and output them into CSS styles such as content: ” “; style of that element.
Figuring this part out was quite fun, and the added benefit is that you can see the output visually to compare it with a Photoshop Style Guide, provided by a designer for that project, side-by-side with the HTML output.

Finally, we get the output from the above 3 code snippets:

Pattern-Library-palette-view

As with most things, it’s a work in progress, and there will always be more handy features to add to improve our workflows. Eventually, once Magento 2.0 comes out, a similar framework could be adapted to the new paradigm. Though it might not exactly be needed if Magento 2.0 is responsive out-of-the-box.