Don’t Design Websites. Design Systems.

This morning, I received an email that was forwarded from a colleague at Domain7, where I used to work as Senior Designer. I have been forwarding a reasonable amount of traffic to Domain7 from a project I had experimented with on my own time: 960 Fluid Grid System, based on Nathan Smith’s 960 Grid System.

The request went something like this:

I’m on a project where the client just wants us to deliver responsive templates CSS/JS/HTML and not actually build it as Drupal templates.

I recommended that they use the Omega theme, but I’m worried that using a grid system outside of Omega wouldn’t match easily. I’d like to use your fluid 16-column grid system for my templates, but I’m really hoping to get your opinion on this.

Should I push the idea of delivering a Drupal theme or should I use your fluid grid system and let the client deal with the conversion?

The request apparently touched a nerve with me, because this was my reply:

Grid Systems

I am assuming that you are referring to the 960 Fluid Grid System. To be honest, I haven’t used that grid system for a very long time. It can probably be easily adapted to work with a responsive web design approach. I have since worked on other grid systems as well, to experiment with different approaches:

But there are other more flexible systems that are available now.

You might want to look at the grid system used by Zurb Foundation, which allows for nesting.

My biggest issue with the 960 Grid System has to do with baking in the width of the gutters. For this, the 960gs doesn’t seem to be as flexible as I would like. That’s why I started to look at Nicole Sullivan’s OOCSS grid system as an alternative and used that as the basis for experimenting with FluidGrids, then later with the Markup Library templates

With the Markup Library templates, I really like the way I can set margins that remain consistent regardless of the width of the viewport. Modifying the margin width is really simple, since it just means changing the value for the padding of the .content container. This is the main reason I abandoned the 960 Fluid Grid System.

Nathan Smith has recently released Unsemantic which is the successor to the 960 Grid System.

He is able to reduce the markup necessary by relying on the box-sizing: border-box property to be able to apply the padding directly to the grid container without impacting the width of the box. This technique won’t be backward compatible for older browsers unless you add a polyfill for the box-sizing property.

Update from the Inquirer

Doing more research with Drupal in mind it seems that “Zen Grids” might be the most friendly. The Drupal Omega theme actually has a zen grids sub-theme with a good amount of documentation.

Integrating Designs into a CMS

I actually don’t know much about Drupal, other than that Domain7 uses it for most of their CMS implementation projects. What I have experienced when working on projects for implementation into Drupal, is that designers don’t have as much control over the code, since the modules often define the output. Some Drupal developers I have worked with insist that the markup should be created in Drupal to avoid the headaches that arise when markup does not align with what Drupal expects. Other Drupal developers say otherwise, that, while it might take more time and care to accomplish, it is possible for Drupal to output very clean markup. This approach might require avoiding certain modules that dictate the markup structures.

I’m more of a Symphony enthusiast, where designers and developers use W3C standards to build page templates. This is far more flexible and places much more control into the hands of the designers to structure the markup as they see fit. There is then a contract between the developers and the designers to maintain a strict separation between the data layer (XML) and the presentation layer (XSLT).

I think the answer to your question about the deliverables for your project should take into account the needs of the developers who will be integrating your design into the system. You will need to determine the approach that they are comfortable with, unless you are able to encourage a more progressive approach and they are open to stretching themselves to allow better control over the markup.

In an ideal world, I would deliver HTML/CSS/JS, similar to a project I worked on at Domain7 for Claremont McKenna College. It was the client’s responsibility to integrate the markup into their proprietary CMS. I documented parts of the process on my blog:

However, in the context of a Drupal implementation, you may have to compromise your standards somewhat.

Giving Back Control of Markup to Designers

This is one of the reasons I would like to write a book about XSLT for Designers. The web standards community has ignored an important standard, and designers are facing the challenges that arise with the lack of a standard for templating systems across web development systems, frameworks and scripting languages. Developers have taken control of the markup with systems that ease their processes but make the work of a designer much more difficult. I would challenge the popular misconception that XSLT is too difficult and not widely supported. XSLT is available on any UNIX-based system, such as Mac OS X and Linux as xsltproc on the command line. PHP supports XSLT with the libxslt library. Ruby has several gems that are able to process XSLT (Nokogiri, ruby-xslt, libxslt-ruby). Nokia is currently working on an XSLT 2.0 implementation in C++. It would actually make the work of developers and designers much easier to be working with the standard that the World Wide Web Consortium has recommended and is actively improving as there would be a true separation of concerns, and each could focus on what they do best.

XSLT is to proprietary templating systems what CSS is to tables-based design.

I don’t think your problem is an isolated one. Designers are handcuffed by systems that favour a particular developer methodology and philosophy rather than the need for machine-readable, semantic data in the form of XHTML. The lazy coding practices that HTML5 has encouraged have been a huge compromise and a step backwards because the cowpaths insist that the web is just a series of strings rather than well-structured XML that can be easily processed into a myriad of output formats. The crowd has run down this path with little thought regarding the long-term consequences.

The Content Management Problem

Karen McGrane’s talk at BDConf 2012 is an excellent resource for gaining some understanding of the mess in which we find ourselves.

Some of her main points involve the changing technology landscape that has been centred on optimizing experiences on desktop screens but has been completely ignoring the user experience on mobile devices, leaving that to device-specific applications. In contrast, she advocates a different approach:

  • COPE: Create Once, Publish Everywhere.
  • Launch an API

Quotes from Karen McGrane’s Presentation

  • A semantic content publishing system creates well-defined chunks of content that can be combined in whatever way is most appropriate for a particular platform. All display issues are addressed by delivery applications, rather than by a content management system earlier in the process.
  • Content Authoring != Content Management != Content Publishing
  • Thinking about content that will ‘live’ on a ‘web page’ is pretty 1999.
  • We are making the exact same mistakes that these print dinosaurs are making.
  • We are not in the web page publishing business. We are in the content publishing business.
  • “Truncation is not a content strate…”
  • We have content management systems that create blobs of content with WYZIWYG editors that allow people to design their content for the only display format they can think of: the desktop web. “I want it to work like Microsoft Word.”
  • We are in a war between giant unstructured blobs of content and clean well-structured fields of content with meta data attached.
  • Metadata is the new art direction.
  • Use business rules to decide what content to display, so the robots will know how to construct a page.
  • Beautiful software, even for back-end users, is becoming an expectation. We’re moving in this direction because we now understand that better content management systems foster better content. — Matt Thompson
  • It’s time to start separating content from form.

Take a look at the system created for NPR using the principle of COPE: Create Once, Publish Everywhere. What is the foundation of the API? An XML Repository. This structure allows for content modularity.

We Design Systems

As you think about the grid system for the site design, be sure that you are thinking in terms of building a modular system.

I don’t think we design web pages. I think we design systems. The concept of systems in industrial design has been around for a long time, but it took web designers a while to catch up and realize. We design these modular systems that expand and grow in a site’s lifetime. We have this wonderful thing where we don’t do print design, where there is a deadline and we send it on a CD to a printer and then it’s done. We build these things that evolve and grow within an organization, and it’s our responsibility as good designers and developers to put in place really strong systems that can cope with whatever is thrown at that website through its lifetime.

Take, for example, the advent of new devices. Not many people really saw the iPad coming. But if we built sites in a good way, we build them where they can cope with the different realms of viewing. TVs now, all manner of different things, projectors, printing—all the wonderful, different things we’ve got with our websites and how they’re used. We should build systems that effectively cope with what this crazy industry’s going to throw at them.

— Simon Collison, A Philosophy of Restraint

I found a couple more resources about designing web systems. The second resource is a presentation focused on designing and developing a web system with Drupal.

These are some of the reasons I would choose different technologies than those that are considered popular, because there are more flexible systems available for building web systems that will better serve the needs of web content creators and their audiences.