The Making of a Responsive CSS Framework

Author Avatar
Written by Digital Surgeons,
• 13 min read

Hello internet, my name is Craig Keller. I’m a front-end developer/designer around these parts. This week Digital Surgeons announced the launch of our very own Responsive 960 Grid CSS Framework that we affectionately call, Gumby Framework.

  Gumby Framework is the result of a number of issues, frustrations, and redundant coding that we found ourselves encountering when using virtually every other responsive framework that the web has to offer. Working closely with Pete Sena, Digital Surgeons co-founder, we began working with our fellow hybrid designer/developer geeks to find a way to launch a better front-end kit that fit our needs and hopefully the needs of the community. In this article I will discuss why we built Gumby Framework, some problems it solves, how it works, and the plans that we have for the framework going forward. Buckle your seat belts and grab hold of your barf bags — you’re about to be hurled into orbit around the brain of a designer/developer.

❤ Grids

  As a designer and a developer, I have always had an affinity for grid frameworks. They’re pretty amazing tools for people in the business of building websites and applications in a collaborative environment. They help designers maintain a consistent layout and structure across pages they design, they keep the developers and designers on the same page throughout a project’s lifecycle, and they help developers build out sites rapidly by eliminating the need to establish structure from scratch on every single project.

  We, at Digital Surgeons were early adopters of the framework, and had always felt extremely comfortable using it. Way back when the web was built using static 960px layouts, designers and developers could easily stay on the same page because was awesome enough to provide templates for designers in addition to the stylesheet for developers. It was a harmonious time, designers and developers became BFF’s (bee • eff • effs). They laughed together, played together, bought each other ice cream cones; romances and bromances abound. But everything good must come to an end.

A Bit of History

  Since the introduction of the iPhone, the web has transitioned rather rapidly towards mobile. With that, the days of fixed-width (960px) layouts has waned into extinction. In this new future, sites need to be responsive and context-aware so that no matter what device you open a website on; the site adapts the layout and “responds” to the width of the device that it is being viewed on. The responsive movement had begun.

  With this new movement, and requirement, that all websites moving forward absolutely had to be responsive in order to accommodate the bevy of users pummeling sites from their mobile devices; a new rain of responsive grid frameworks hit the web in an attempt by the community to proliferate this new, responsive web.

  We caught that wind early, and it seemed like every week one of the developers here at DS was proposing the adoption of another responsive grid framework. Through trial and error, we quickly discovered what we liked and what we didn’t. Although we certainly had a few favorites, none of these new frameworks quite filled the void left by Many of these new frameworks deviated greatly from the standard layouts that we were used to with What was making the web better was hindering our ability to maintain consistency, and affective collaboration between members of our team. The time of harmony had ended.

The Problem

  What was the problem? Put simply: moving towards responsive design had seemingly created a rift between designers and developers. There were problems with how to wireframe for responsive websites, as well as the differences in margins and columns found on familiar templates and the lack thereof for the new frameworks.

  Without PSD templates, designers could only guess whether or not they were designing the website in a way that was friendly to their former BFF, developers. Developers were forced to guesstimate, (which is like plucking out eyelashes for structure-loving developers) and many websites were left in pixel-anarchy. There was no way to REALLY translate a photoshop design into a pixel perfect website like there once was. As a designer and a developer, I was at a crossroads.

  In a time, not so long ago, layouts were 960px… everything was so certain. Now developers were being handed PSD’s to build out that were designed using outmoded photoshop templates, yet we were expected to translate these designs into pixel perfect, responsive websites. All without a compatible grid to build them with.

A New Hope

  Gumby Framework was conceived while working on an internal project where we were using a different responsive grid framework to mark up a design that was handed to me on a 960 grid template. I was trying to cut it and code it the best that I could; nothing was working smoothly. I was left frustrated, and wrestling with this project when it dawned upon me…

  What was wrong with 960 in the first place? Nothing. We all loved it so much. Why can’t 960 respond? Whats wrong with that? Nothing was again the answer. But how can we keep 960 and responsivity at the same time? Can cake be had and eaten to? With a semi-liquid layout, the answer was yes. That is when we decided to create our own 960 grid framework using a semi-liquid layout that would work to re-establish the harmony between designers and developers. Designers would, once again, be able to use the templates that they’ve been working with for years and developers could rest easy knowing that they wouldn’t have to be left guessing what percentage widths and margins were being used in relation to the document width. Order would be finally be restored.

  Math was in our future. But we just didn’t know it yet.

I Frustrate Easily…

  I quit trying to hack the crap out of the existing framework that I had been using on the project, and decided to write what started out as a basic rewrite of a responsive 12-column grid. We were new to this whole grid business. At the time, we were users of the tool; creating one (especially using percentage widths) was quite a challenge. Needless to say, we have newfound respect for anyone who has built their own grid framework before haha.

  After I had this new grid coded out, I passed along the test page that I had created to another awesome developer here, as well as our creative director to get their thoughts. The reaction was insanely positive, with the only request being that I create a 16 column version of the grid as well (because there were no 16 column responsive grid frameworks at that time). Anyhow, after a few more brainstorming sessions with my fellow genii here at DS, a new beast was born. Gumby Framework had been incepted.

If You’re Gonna Make It. Make it Better.

  We decided to use similar class naming conventions to Zurb’s Foundation because we loved how incredibly succinct and elegant they were (as all classes should be). Using rows to create horizontal containers which housed the grid columns makes building pages that have source-ordering engrained into their core an afterthought. This greatly improves the accessibility and SEO friendliness of the sites built with Gumby Framework. We also came up with the idea of creating a Hybrid Grid to include with Gumby Framework at this time. It wasn’t until we had built that grid that we realized how truly powerful and liberating it would be.

  The Hybrid Grid allows you to define a 16-column grid wherever you want on a page, at any time. You can use it to make an entire page 16 columns, or just a certain section. This gives designers and developers freedoms that they have never had before with a grid framework. Designers can achieve things that were never possible before without “breaking the grid”. They can accomplish new, creative layouts without fear of developer backlash or dramatically disrupting development timelines. It also allows developers to be a little bit more flexible when creating more complex layouts, as things that would add significant development time before can now be accomplished quite easily by switching to a 16-column grid for a particular section and then switching back. We think that this is pretty revolutionary. We’ve already used it on a few projects and we’re as impressed with the results as our clients are.

America is all about speed. Hot, nasty, badass speed.
Eleanor Roosevelt, 1936

  With the base structure in place, and the internal project that I had been working on now completed thanks to Gumby Framework’s grid system, I thought about what else we could to do make our jobs better/easier/faster. One of the things that we thought that would be extremely beneficial was a UI kit that would allow anyone who used Gumby Framework to create rapid prototypes, or edit to their needs in a production environment. The idea seemed great, but there was a potential problem with this that we couldn’t live with. In our travels and experimentation with some other frameworks that included UI Kits, one thing that we noticed about them was that their UI kits were always included no matter what, and that they were always HUGE. We didn’t want this to be the case with our UI kit; we accepted the challenge to create one with a light footprint, averting bloat with vanity-free css.

  Another thing that we decided early on when creating our lightweight UI Kit was that it also had to be OPTIONAL. A lot of our team members here don’t really like the UI’s included with the various frameworks and find it to be more work to customize them than to just write everything out on their own. We wanted to give our users the option to not use the UI kit, so we made it a separate css file.

  Now, just because we’re giving people the OPTION to resist our UI Kit, doesn’t mean we don’t want them to use it. To hammer home that point, we designed the UI Kit and associated Javascript to be insanely easy to use, lightweight, and flexible — aka we made it irresistible.

My secret identity is a designer

  I love buttons. My secret identity is a designer, he designs buttons and clicky thingies all day long and is never happier than when he is doing that. My superhero identity is empathetic towards sweet, innocent, designer me. So “Developer Craig” made sure to create amazing buttons for Gumby Framework. The buttons that resulted from this love are structured hierachically, taking full advantage of the cascade to allow for some really neat things to be done with them. You can mix and match classes on all of the button types that are included to create multiple variations of any button type that you want. We also named them according to their function and order of importance which allows you to quickly and easily define roles for your buttons just like you would with headings. The buttons built into Gumby Framework are incredible.

  We also created a ton of other sick UI elements that are equally amazing as the buttons. They really make life easier when you use them, so we encourage you to download Gumby Framework and take full advantage of that.

Protip: Use The Styleguide Inside

  We built-out our entire UI kit on a single page html file for testing purposes, and to make developing it a whole lot easier. However, when we were done with it, the one off page we had created looked a lot like a web-based styleguide! It happened almost by accident, but we thought that this could be a really useful tool for our developer friends, so we included it. Having this page acts like a cheat sheet for developers. With it, you can build out your entire project’s UI elements separately from the structure and just pull those universal elements that you created into your layouts as needed; pre-styled and ready to roll. This tool’s utility will surely be one of the most under-appreciated and under-utilized features of the framework, so I just wanted to point out its existence and purpose in hopes that you consider making it a staple of your workflow. wink

Gumby Framework is for you, and because of everyone.

  I could seriously go on and on about the benefits and thought processes behind Gumby Framework. It was thought and rethought, tooled and retooled, many times during its creation to optimize its flexibility, modularity, compatibility, and ease of use. The best way for me to show you just how useful and pliable it really is is to have you download it. Download it, use it, love it, and give us feedback. Heck, you can even contribute your own code to the project because Gumby Framework is completely open source. Clone the repo onto your machine and tinker around. If we missed anything that you think would make Gumby Framework even better, commit away!

  Gumby Framework is the lovechild of the genius thinking of all those who came before it; without the work of everyone else who has helped push the web forward, and those who have created responsive frameworks before, Gumby Framework would not exist. We could not have created this without the web development community and its amazing contributors. Companies like Zurb; people like Nathan Smith, Nicolas Gallagher, Paul Irish, Dan Cederholm, Andrew Maier, Ethan Marcotte, Jeffrey Zeldman, and Eric Meyer who have helped forge the web ahead are the reason why tools like Gumby Framework are even possible. So, we would like to thank them and everyone else who has helped push the web forward. Gumby Framework is for you, and we couldn’t have built it without your hard work coming before it.

Gumby Framework Links