SharePoint and Responsive Frameworks Chris Poteet, October 28, 2015January 27, 2016 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 Responsive frameworks seem all well and good on the surface: use these classes, or include this bit of JavaScript and you have yourself a component. The problem starts when you run into something that does not work as expected. I remember the first time I had to debug another developer’s use of Foundation on a SharePoint web part, and I found myself agonizing on how to debug this code that I simply was not familiar with. This is also something that happens quite a bit when you add the complexity of a framework on top of the already present complexity of SharePoint’s out-of-the-box styles and interactions. I simply do not want to have to include code that I am not intimately familiar with, and even if you as a “normal” developer got to the point of understanding all of Bootstrap’s CSS, JavaScript, and other APIs a new version would come out. It simply is too much to ask. The 4.0 Alpha of Bootstrap has over 40 SASS partials that spits out enormous amounts of CSS when compiled. Code Bloat 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: “I find Foundation, Bootstrap, and similar frameworks interesting from an educational standpoint, but I would never use one when building a production site. For prototyping a concept, sure, but to take one of these into production you need to be rigorous in your removal of unused CSS and JavaScript or you end up creating a heavy, slow experience for your users.” 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 When a developer continually uses something like a responsive framework it could greatly impede their ability to understand how to actually code responsively by themselves. This limits their overall ability to grow as a developer, and we have seen this with a generation of jQuery developers who don’t know JavaScript. I fear the same could happen with responsive web design. If you want to learn patterns and practices from a responsive framework then that’s fine, but don’t let it be the end of learning how to do responsive development. 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. For one example let us examine the off-canvas menu for Foundation for Apps. As you look at its rather plain interaction design and decide you would rather handle your multi-level taxonomy in a different way. What are you to do? Change the underlying JavaScript? It simply “satisfices” the off-canvas need whereas something like jQuery.mmenu is a significantly better plugin with nearly limitless options for extensibility and interaction choices. This is just one example of when you try and develop a component for everybody it ends up satisfying no one. 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! An Alternative 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. Related Posts Design Development User Interface frameworkrwd
Chris: As always, your thoughts are valid and well articulated. I think where you miss the mark is in assuming that most designers or interaction developers – or whomever gets saddled with wrestling SharePoint into shape – have the skills to implement an original and responsive design themselves. Heck, even just getting simple design changes into SharePoint is generally a challenge, even for those of us who do it repeatedly. What the frameworks do is give people a leg up so that it’s even possible to make SharePoint reponsive. I’d venture that most times they aren’t starting with a framework itself, either, but one of the bespoke adaptations like those from Eric Overfield, Kyle Schaeffer, or Randy Drisgill. The majority of people simply don’t have the magic intersection of skills, time, and money to do it any other way. That said, yes it’s unfortunate to see the proliferation of Bootstrap’s design artifacts, just as it is to see jQueryUI components – unstyled even! But so it is. We can count on great designers like you (no sarcasm intended) to set a higher bar, but there just aren’t enough of you to go around. Until adding responsive – and attractive – design to SharePoint is easier (and let’s hope the Product Group gets off their high horse on these issues), canned frameworks will continue to save the day. M. Reply
Thanks Marc. I always appreciate your thoughts. As I mentioned RWD frameworks can be good for some initial learning, but continually using them is analogous to remaining an infant. Another analogy is jQuery, which you are obviously very familiar with. Sure you can indefinitely only use jQuery, but jQuery is an abstraction on top of “real” JavaScript. It keeps developers from understanding situations where writing vanilla JavaScript is more optimal, performant, etc. This is why things like the site You Might Not Need jQuery have popped up. I appreciate the compliment, but I didn’t get to where I am using these RWD frameworks. I think it is telling that I have yet to meet a really good/well known UI developer (outside of Twitter or Zurb of course) that actually uses these frameworks. Reply