When I first started at NGI in late 2006, I used to flat code CSS based layouts with the best of them (well, maybe not the best, but the good of them?). I was setting forth on my first major web project here when I came across a Smashing Magazine article, Rapid Prototyping For Any Device With Foundation. The article talked about a brand new, or at least new to me, form of front-end coding, the framework with the idea being that you could quickly produce a responsive layout (admittedly another new term for me at the time) from prototype to code complete in no time. There were some basic styles and elements like navigations, image sliders, and buttons that were easily customizable. The class based layout definitions gives the user the ability to create great grid based layouts for desktop, tablets, and mobile devices. The documentation is thorough and software is well supported.
I got started right away with the framework and produced some great sites in a fraction of time by leaving all the little details behind and focusing on the greater whole. No more scavenging the web to find a dropdown menu system that worked with IE7 and didn’t interfere with my front-page Jquery image slider (it was 2006, your website had one, too, and if it didn’t, you probably thought it should).
All well and good right? Well, yes really. The Tech Team here at NGI has used a framework to create every major site since that article came out. It’s allowed us to work quickly, iterate quickly and work cross project without having to dive deep into the display level CSS to get things live.
Then things started to turn for me, as I noticed myself spending more time trying to work around the way things were done to get exactly what I wanted. And I’m not anti-framework at all, I believe that frameworks are a great tool to get started with responsive design, and I don’t really buy the “same site” mentality either. But, I did start to think recently, what if I wanted more control than the mainstream frameworks gave me? Maybe I want different breakpoints on different pages. Do I need all the extra features in the framework that we might use, but probably won’t? What if we made our own framework, something completely tailored to what we do, and not something that’s made for everyone?
That’s what this project is about, creating an NGI framework from the ground up. I won’t sit here and say that I’m going to break new ground and revolutionize the whole framework world. In fact, I’d bet whatever this project produces will be heavily influenced by my experience with the framework we use now, and to be honest, it’d be weird if it didn’t. What we do want to make is a framework that’s lightweight, flexible and easy to pick up, based in SASS and Jquery.
Since the idea of trying this out on an actual website is not going to fly with the Chief, I’ll be building the new framework on a dev site where it can be free to break and look like garbage until all the little and big bugs are worked out. I’ll be documenting my progress on this blog, I’ll be posting about the steps we go through, issues, features, and the overall implementation of our new in-house framework, codenamed Hindenburg. Why Hindenburg? Because despite our best efforts, whatever shiny new framework we produce could still end very, very badly.