Having a Responsive Design Code Base: Pouring Your Foundation

Jeremy Pratte
January 08, 2013
User Experience Design

Basements: there’s not much to them until things like hot water heaters, washers, dryers, shelves, and other furnishings are moved in. It’s basically four walls and a floor made of concrete. When a house’s foundation is poured, which is usually the basement, they all more or less look the same, with size really the only variation. If we lived in a virtual world where such a thing would be possible, if an enterprising home builder used copies of the same basement over and over a lot of time – and money – would be saved, wouldn’t it?

Websites, unlike homes, do exist in a virtual world. So when it comes time to build a new website, many web developers out there use foundational code instead of starting from scratch every time. Sometimes they just take a similar site they’ve developed before and strip things out, but it’s most efficient to actually have a package of bare-bones code ready-to-go. The proverbial basement for their website is already complete. This can be anywhere from a “resets” CSS file that resolves a lot of common browser-compatibility bugs from the start, to an entire package with a default header, footer, grid system – markup, HTML, CSS, and JS. Some packages may even contain a default responsive design system to tweak as-needed. Others might even go so far as to have modules for tabbed content, drop-down menus, rotating featured content, modal windows, and more. Just imagine how much time that can potentially save not only in the initial development but bug-fixing later. And any foundation system worth its salt will be more or less bug-free from the start.

One foundation system, the aptly-named Foundation, looks to be a really good one. It has an easy-to-use 12-column grid system as well as all the aforementioned modules. The simplest version just has HTML, CSS, and JS files but there are packages with options for more advanced users, like code compilers. But the grid system is the beauty. It’s based on percentages which make it perfect for responsive design. Each of the 12 columns is 8.3333% wide (with a little fudging with that imperfect decimal all 12 together would equal 100%). “But, my design doesn’t need 12 columns anywhere!” you might be saying. No, the idea is, you have 12 columns available to you, you don’t have to use all 12. If you wanted your layout, or sublayout, or sub-sublayout to be only two columns wide, and both are equal in width, you’d use 6 of the 12 available grid columns for each real column you’re using. (In actual practice you’d apply an additional class to each of your columns, “.six” – clever naming scheme, huh?) Or you could have two columns where one is a rail and one is a main content column and for the rail use 4 of the available grid columns and for the content use 8 (“.four” , “.eight”). Bootstrap, created by Twitter developers, is another foundation system with many of the same features Foundation has, including a 12-column responsive grid system. After being compiled by a pre-processor, in the end Bootstrap’s code is purely CSS.

If a web design and development firm decides to use a CSS/HTML code foundation, before deciding on Foundation or Boostrap or any of the other competing systems out there, first it must decide whether to use one at all. Over the years most firms, perhaps ad hoc, have developed their own boilerplate front-end UI code that they’re already using. It becomes more important to do that the bigger the firm and the bigger the projects. But considering that responsive design is a relatively new concept, most of those homegrown boilerplates probably don’t have much, if any, responsive code. This is where adopting, or at least integrating into what they have already developed, a foundational system like Bootstrap or Foundation, can be a huge advantage. Retrofitting a site’s design to be responsive – writing copious amounts of CSS in media queries – can involve a lot of hand-wringing and be fraught with bugs. The same goes with any of the other features these systems boast like tabbed and featured content. Using a default system with responsiveness – and the other cool stuff – already built-in can save a lot of time and headache.

But switching over to it is not a decision to be taken lightly. It doesn’t just affect the front-end developers, it affects everybody in the entire process, from sales to the back-end coders. Clients are starting to request responsive design but ones who have not yet heard of that must be sold on it. Some clients might not want it, or it might actually not be appropriate for all projects. To fully leverage a code foundation it must be kept in mind from the get-go in the design process, in particular how the grid system works. When the designer decides the pixel width of the columns, etc., percentages with respect to the container should be calculated so that the grid system can be dropped-in without much – or any – need for tweaking. For example, if the pixel width of the left rail is too wide if the front-end developer uses four of the columns, but too short if five of the columns is tried, that would be frustrating when trying to adhere precisely to the concept. The person or team doing the concepts also has to take into consideration that the client might want an approximate visual concept, or two, of what will happen to the site once the break points are reached and the layout changes, as a good responsive system will have a default built-in way the site changes when the screen size reaches the tablet and phone screen sizes. The back-end coders that deconstruct and integrate the project into a content management system will need to prepare to receive code they’re not used to seeing and adjust their process accordingly – if they’re willing to do that at all (the recent switch to HTML5 might have been traumatic enough for them). In short, everybody must be on board.

All things considered, though, sooner or later it makes sense to have some sort of front-end code foundation. After a company has fully come around the learning curve on the first few projects using the system, it would almost certainly in the long run save time – and money.

comments powered by Disqus

STRATEGIC PARTNERS