Responsive frameworks have taken off in the last few years, and there is no sign of that abating anytime soon. There are the big players such as Zurb’s Foundation and Twitter’s Bootstrap, but there are also a plethora of “smaller” frameworks (see examples like Base and Flexbox Grid) that all seek to solve the same problem: make repeatable tasks easy and streamlined.
When you look at responsive frameworks, while they vary in size, scope, and intent, they all generally have the following things going for them:
- They are well-tested, open-source solutions with many talented developers working on them.
- Responsive frameworks are a great learning tool into patterns and practices for responsive web design.
- They allow developers to get a jumpstart on productivity and not rehash the same tasks for every project.
- These frameworks introduce standardization on many levels from naming to interaction design that many developers lack the ability to do well.
So with all these benefits you have to ask the question: Why wouldn’t you want to use a responsive framework? After all, it seems to solve some of the most pressing problems. Well, the case is not as open and shut as it would seem, and for the remainder of this article I will outline the reasons I personally forgo the use of responsive frameworks.
Before I get into the negatives of using responsive frameworks I should mention that at the time of this article both Zurb and Twitter are about to release new versions of their responsive frameworks. I will do the best I can to ensure my critiques take into account their newest versions.
Debugging and Code Familiarity
This is a common criticism of responsive frameworks and justifiably so. The problem with these frameworks is that you have to include a lot unless you want to spend the time pruning away the unnecessary CSS. Well known web developer Aaron Gustafson (and author of a book on progressive enhancement) has this to say:
Thankfully, you can pick and choose which code to bring in through opting out of partials in both Bootstrap and Foundation, and both Bootstrap and Zurb’s Foundation for Sites have customizable downloads to choose what to download. However, that does not solve the problem of code bloat.
Let’s look at Zurb’s Foundation for Sites grid system (version 5 since version 6 is not available for public viewing at this time). Even if all I wanted was to just include the grid system, you are looking at 1,146 lines of CSS when un-minified (and in a semi-expanded format no less). That is a dizzying amount of CSS that no one is going to prune for unneeded CSS. As a counterpoint, my custom SASS mixin to generate a grid generates only a few dozen lines of CSS. We live in a world dominated by 3G networks not fiber ones, and this amount of code also contributes to the problem of page size and load time where SharePoint already struggles with out of the gate.
Presentational Class Names
This is a small one, but it is one that bothers me to no end. Let us look at two examples of using the grid system for Bootstrap and Foundation for Apps respectively.
<div class="row"> <div class="col-xs-12 col-md-8"></div> <div class="col-xs-6 col-md-4"></div> </div>
<div class="grid-block"> <div class="small-6 grid-block"></div> <div class="small-2 small-offset-2 grid-block"></div> </div>
That actually makes my head hurt. I agree with Rachel Andrews who says: “Recently CSS frameworks have blossomed, many of which allow the creation of complex grids, at a cost of embedding a description of the layout into the markup itself”. Granted the idea of “semantic class names” is a bit of a misnomer, but this embedding of presentation into markup makes me cringe.
Stunted Developer Growth
Opinionated Interaction Design
This of all the negatives is for me the deal breaker. Let me open this section with a quote by Steven Bradley in his cons list for responsive frameworks:
The framework can become an arbitrary design constraint. You may find yourself designing to the framework instead of selecting the best framework for your design.
This exactly spells out what I see as the worst trait of these frameworks. As a proud interaction designer (I choose that carefully over “web designer”), I pride myself on knowing trends, options, and practices for interaction design models for all kinds of needs and problems.
SharePoint and Framework Specifics
Each of these criticisms can apply generally to frameworks in general and using them with SharePoint specifically. I honestly did not think anyone would suggest using Bootstrap or Foundation with SharePoint due to these reasons until I read Pro SharePoint 2013 Branding and Responsive Web Development. I should say at the outset I do not mean to demean the authors nor have this be a full review like I did for SharePoint 2013 Branding and User Interface Design. I simply want to point out some things I noticed while reading the book as an example of using SharePoint and something like Bootstrap.
What I felt most frustrated reading this book, and why I would not give it to a new designer (who I think the book is intended for), is because the book teaches to a framework not the underlying how and why of how it actually works. This to me is not a good pedagogical approach to teaching someone responsive web design. I want to know the ins and outs of media query creation, choosing units in my breakpoints (and the associated content strategy implications), and more.
I also got more frustrated when I saw the section entitled: “Fix Common Responsive Issues with SharePoint” (pg. 146ff), which should have been titled “Fixing SharePoint Now That You Have Wholesale Included Bootstrap.” Fixes include some awful hacks around the box model being set to border-box (pg. 147, which the proper fix is to scope it carefully not undo and redo), managing span floats from Bootstrap (pg. 149), and writing device-specific values for media queries such as max-width: 767px to target an iPad (pg. 156).
One of the authors, Eric Overfield, manages a Bootstrap/SharePoint starter package entitled “Responsive SharePoint” on Codeplex. In the book one of the authors makes the point that you do not have to include every component from Bootstrap, but this solution does not do that and has over 7,000 lines of CSS (unminified) that includes the framework plus their additional styles on top!
So what is our alternative if we do not use a large responsive framework? That is why I built and maintain Archetype for SharePoint on Github. It seeks to be an unopinionated and minimal approach to starting to use SASS, responsive mixins, and starter layout/master page (it is due for some upgrades which are forthcoming). It certainly does not include modules like off-canvas or modals, but it provides me the minimum I need to use to start a UI project in SharePoint that allows me to go find the best interaction design options.