Cloud Four Blog

Technical notes, War stories and anecdotes

The Pitfalls of UI Kits and Pattern Libraries

When I wrote Common Patterns in Styleguides, Boilerplates and Pattern Libraries back in May, I honestly didn’t know if anyone would find something as pedestrian as a spreadsheet that interesting. It was great to discover I’d at least partially solved a problem for a lot of people. But I was surprised to hear from a handful of designers and developers who interpreted it as a score card… the more patterns a library contained, the better.

Yikes! Totally not my intention.

Here’s the thing: These frameworks are terrific resources. I think it’s really helpful to see how other teams craft (and document) scalable and modular interface elements. They are excellent points of reference.

But I tend not to use them for more than that. For two big reasons.

Complexity

It’s a rare project that launches with less complexity than anticipated. So why front-load your project with the totality of another team’s interface needs?

.net magazine recently published an interview with six RWD experts. Here’s a gem of a quote from Tim Kadlec:

I think that our industry in general has it a little backwards: instead of the default being a framework or all these other little plugins and polyfills, the default should be just simple HTML and CSS. Then, as the project needs, you can start including things. But everything you add to a page or project adds something — be that weight, maintenance or complexity — and therefore everything needs to be justified before it gets thrown into play. Start light and vanilla and only add things in if they’re necessary.

And from Aaron Gustafson:

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 you users. I also think you need to work twice as hard to break out of the theme of the framework. There are a ton of Bootstrap sites out there that look like Bootstrap sites. Your design should be as unique as your product, not some off the shelf thing you just changed some colors on.

Opaque design thinking

Many of these frameworks are incredibly well-designed and executed. But how, and why? Why that corner radius? Why that font size? Why three button sizes… why not four, or five? How can we competently extend this design thinking without knowledge of its history or principles?

Trek Glowacki wrote a wonderful gist that describes this problem in detail:

Every design is like a little language with its own correct grammar and syntax nearly as specific as a programming language. It contains primitives but instead of concepts like maps, arrays, integers, and functions the primitives include size, weight, color, proportion, and texture.

Without first understanding that language it’s impossible to correctly express anything new. And that’s where the problems start for most people using these libraries. If they stay safely within the provided components they can make an application that looks designed (because it is) but no UI kit provides every possible component or even has guidance about all the ways existing components can be combined.

So why care about common patterns at all?

Our own responsive deliverables benefit from seeing what patterns emerge from those who’ve solved similar problems before. We can learn from their techniques while crafting new ones.

In the immortal words of Emil Faber, “Knowledge is Good.”

7 Comments on “The Pitfalls of UI Kits and Pattern Libraries”

  1. Jason Grigsby says:

    Great stuff Tyler. Thanks for following up on the topic.

    Because the idea of looking at these libraries was my suggestion, I think I should explain what I was thinking.

    I often find that when clients are writing content for their own site, or even when I’m writing something for our own blog, that the styles will have failed to anticipate something and all of a sudden writing content became a design issue instead of simply writing what you want to say.

    For example, when we originally launched our new design, the styles didn’t include styles for handling code elements. The first time I wrote something that needed to include a code snippet, my writing was interrupted by a need to go define the styles for that element.

    I can do that, but our clients usually don’t know CSS well enough to make that happen.

    What I observe happening is that when we’re defining styles for a design, that we design for what we know right now which is great, but if we only do that, we’ll miss the mark. If we don’t define a style for an h5 because none of the content we’re currently working with have five levels of headers doesn’t mean that the next piece of content that someone posts won’t have five layers and the fact that the h5 isn’t defined will become problematic.

    So my idea was that if we had a comprehensive list of things that are being used in these libraries, that we could pick a subset of them for a given client that we could reasonable expect that people might need to use.

    To my mind, this is not so different than defining a print style guide for large publications. Those style guides often include elements that are rarely used, but are defined in advance so that someone doesn’t have to think when they need to add a pull quote to a page. The pull quote style has been defined ahead of time.

    Like you, I’m much more interested in using the spreadsheet to help inform our own style guides than I am using it as a scorecard to compare the frameworks.

  2. John Keith says:

    This post reminds me of the following text from the LM style guide:

    “Lucid makes wanton with many front-end frameworks. Elements from all the below contribute to the front-end code. This page documents the frameworks and versions used to inform the current code. Original source files can be found in the framework-source directory.”

    A big part of me wants to “just know what I’m supposed to do,” which drives me toward some kind of standard. In this case, we ended up with a documented style guide that serves as a specific standard for how to go about building within this hand sewn framework.

  3. As someone who’s been working for a startup for 2 years, let me chime in and say front-end frameworks make rapid development possible. I’ve worked with Bootstrap (corporate site) and Foundation (coming soon open-source web app). In both cases, we’ve used an outside UI designer for a few base 960-grid PSDs and my job has been to adapt & expand the designs for all browser sizes.

    Having a framework where I edit the variables & mixins to suit the design, rather than build them from scratch is a huge timesaver. Foundation’s block grid is essential to a page on our app. Mobile-portrait display? Easy–2 grid units. Landscape? 4. Large screen? 8. Does the app look like Foundation out-of-box? Heck, no! But it works great and gets us from prototype to production fast.

    Foundation (my fav) can be used in totality (SASS & Rails install) or you can pick & choose the modules you’ll need, thus lightening the load. We’re currently using Foundation 4 w/Bourbon. We’ve just migrated from v.3 w/Compass. I’m loving v.4 and Bourbon mixins.
    As for all those ‘lookalike’ sites out there…no problem! They’ve got vertical rhythm and structured space. Visually bland, but not fugly! ;-)

    • Tyler Sticka says:

      For the record, I SASS and Compass. I also agree that Foundation’s grid is awesome… a lot of Bootstrap, Foundation, Topcoat, etc. are awesome. I steal borrow from them regularly.

      I run across quite a few Bootstrap sites with poor rhythm and whitespace due to wayward customizations or a poor understanding of the framework. I guess I’m just lucky that way.

  4. I think you make some very valid points, Tyler. It’s one of the reasons I’ve moved to Foundation. Mostly because it’s much less opinionated, makes use of SASS (my preferred syntax), and it is very modular. Easy to drop the cruft.

    We are heavily considering Foundation for our production environment. One of the primary motivators is the documentation. I am one designer serving 9 or so developers for our product. None of them are very comfortable with CSS or front-end creation. We do however need them to be able to create mockups or edit something in prod with confidence.

    To that end, the documentation within Foundation is a fantastic resource. I’m not sure I could provide that level of guidance without using a framework, even though I am confident I could build a lighter solution on my own.

    Ideally I would write the CSS and document all of it, with examples. I just don’t think that’s feasible for our small team. Add a few more designers/front-end people to the mix and I think that changes.

    A big drawback that you didn’t touch on is the hell of trying to keep up on releases. Foundation has a huge variety of bugs and poorly realized styles. It’s constantly in flux. This is very powerful but also makes maintenance a huge chore.

    If I want to fix something I have to keep track of it, keeping it separate from the base Foundation styles, as modifying those would make maintenance a nightmare. That means my fix and the original bug are both being loaded into the browser. If I have time I can contribute it back to GitHub with a pull request. Then when it does make it into Foundation core I have to undo my fix file.

    Its not terrible but it is a chore. It also makes certain parts of the documentation inaccurate.

    So, like anything, there is no one-size fits all solution. :)

  5. And this why we use Sassaparilla…

    But in all honesty, this is exactly why we created sassaparilla, its a starting point, no grid, no javascript and no presumptions. Just great typography off the bat and some cool mixins to make life easy.

    We use different versions of this for prototyping where we have foundation bundled in and gridset and this makes things much quicker to start designing.