In which we discuss our ideas about software development & technology consulting.

Visual Languages & CSS Frameworks

We had an apprentice last fall whose favorite joke among the MICA set was a quip about interfaces being "couched in a dominant visual language."

To me, the joke pokes fun at design professors who say stuff like that instead of just saying what they meant (namely, "that's trendy right now").

Nevertheless, two recent conversations with Rails developers brought this turn of phrase to mind again, albeit in a different context.

So. CSS frameworks are super trendy right now. Love 'em or don't, Bootstrap and Foundation have become de rigueur for new web projects.

Ever a technology skeptic, I have some concerns related to extensibility and the forced trade-offs we make with CSS frameworks, but I have to admit, they tend to make sense. Stylized widgets and a semi-standardized set of rules for responsive interfaces could really help bring consistency to the web.

And to be sure, both of these options (but more so Bootstrap) instantly provide users with the "dominant visual language" of the web as it stands today: flat interfaces, popping colors, slight corner radii, and subtle animations.

But leaving out my worries about the longevity of these solutions, or the way they co-opt a designer's technological choices, or the basic dilemma with everyone's buttons looking the same, the concern I'd like to put forth is this:

CSS frameworks have begun to convince developers that designers are secondary to building great software.

I say this because the two aforementioned conversations went something like this:

Rails Developer: I need you to build the interface in Bootstrap.

Me: Why?

Rails Developer: It gives me a common set of CSS classes I can re-use to build interfaces later.


Before Bootstrap, the most a developer would ever interfere with these kinds of design choices would be to question whether LESS or SASS was a better technical investment. Nowadays, however, developers can insist the designer "select" from a narrow set of technological options because they believe it will enable them to design without a designer.

My guess is that developers have recognized a shortcut to forms that look okay and have decided that the "visual language" CSS frameworks afford them have made designers irrelevant. This makes a certain amount of sense, given the common and long-standing fear of CSS I've observed in many developers (not to mention the mostly-outdated fear of widespread browser compatibility problems).

The problem is, you can't build an interface with widgets. That's a fundamental misconception about what user experience ("UX") and interface design really are. "Design" with Bootstrap is not design at all; it's snapping LEGOs together. I mean, LEGOs are awesome but there's a limit on the creativity and ingenuity you can achieve when you're just using blocks of plastic built at 90º angles. Similarly, relying on a CSS framework allows a non-designer to, at most, group widgets together into a semi-decent looking form.

An interface, on the other hand, is something larger than a form; it's a fluid, tangible, and intuitive representation of an abstract process the user must move through in order to accomplish a task. And it can't be achieved with shiny widgets alone.

So yes, these frameworks have their place, and they certainly give you shortcuts to widgets like everyone else's widgets. But the misconception that pretty buttons are reason enough to skip the design process is entirely missing the point of building an interface to your software in the first place.

I realize the dream of not having to press pause to wait for the designer's input is attractive to developers, but I still think it's a foolish one. Because regardless of whether or not you'd like to skip the designer, without them you're just building the same old LEGO boat with 90º hulls.


Flip Sasser

Flip is a principal and lead designer at Back Forty.