Create attractive (site) diagrams with Graphviz

Though powerful, AT&T Research’s open source graph visualization tool suite might lean too heavily into geek territory to have captured the interest of the visually-inclined OmniGraffle-ish crowd. Nevertheless, Graphviz and the surprisingly simple DOT language it uses makes it possible for creative types to generate attractive and visually consistent graphs by spending only a few minutes listing objects and their relationships. Graphviz will do the rest, laying out the graph according to magical and undoubtedly geeky algorithms. Sounds fun, doesn’t it?

DOT is easy to learn. The syntax is simple and straightforward. But wait: syntax? I want to make a site diagram. Why use some plain text graph description language like DOT?

Don’t get me wrong. As a designer, I love visual tools. OmniGraffle is awesome, and I use it often (especially when applying Jesse James Garrett’s IA Visual Vocabulary). But I love trying old things for new things, and the idea of typing in some labels and relationships and then having a graph generated for me based on my pre-defined (visual) parameters, seems fantastic. Since most of our basic/simple site diagrams use the same style, pushing boxes around the screen isn’t always the best use of my time. Plus, I love plain text (highly portable, as is Graphviz, which runs on Linux, Windows and Mac OS X) and I love the separation of content and layout which Graphviz provides.

Let’s take a look at a very simple site diagram, which I’ve generated using Graphviz:

Simple site diagram generated with Graphviz

This was created using the following code:


digraph test {
    home [label = "Home"];
    prod [label = "Products"];
    news [label = "News"];
    cont [label = "Contact"];

    home -> {prod news cont} 
}

Of course, I could’ve opened OmniGraffle, dragged a box, copied it several times, changed the labels, dragged some arrows from box to box, selected them all and clicked an Align button. But, what if the client adds some new items, or new relationships between items, or both? It’s back to box-pushing. Let’s continue with my first example. Now, my very demanding client has added a few things, which force me to change the diagram. Since I’m using Graphviz, I don’t have to think about the layout, only the items and relationships:


digraph test {
    home [label = "Home"];
    about [label = "About us"];
    prod [label = "Products"];
        wid [label = "Widgets"];
        twd [label = "Twidgets"];
    news [label = "News"];
    cont [label = "Contact"];

    home -> {about prod news cont}
    prod -> {wid twd} 
}

Done. From these changes, Graphviz generates the following image:

Graphviz example

In a visual layout application, I would’ve had to move things around myself. I would have to consider all relationships, and try and figure out how to best visualize them. Granted, this is not the most complex example. The exciting thing about a tool like Graphviz is that it handles relationships objectively (algorithmically). This will not always produce the very best or most aesthetically logical graphs, but it can help one to look at these relationships in new ways. And if all is clearly communicated and looks nice, nothing’s lacking. Plus, even default settings make for great-looking graphs.

We can tweak the settings a bit to get the graph looking a bit nicer:

Graphviz example with tweaked settings

You can get pretty wicked with your styles; there are tons of possible parameters to set, and advanced users can add their own shapes. Transparency is also supported. Since Graphviz is essentially a command-line tool, you can send other processes to it to automate the creation of graphs.

What are you waiting for?

To get started on your own Graphviz adventures you’ll need some tools:

If you’re interested in a high-level tutorial, let me know in the comments. If enough people want one, I’ll post a walkthrough of the DOT syntax and how to style graphs. For the impatient, a few minutes in Google should yield some decent resources.

Enjoy!

Semantic markup and CSS frameworks

The very talented Jeff Croft posts on CSS frameworks and the supposed myth of content and presentation separation, coming to the conclusion that it’s all a pipedream. I both agree and disagree.

Jeff says that *never having to touch the markup*, and only having to adjust the CSS for a redesign, is a myth. With this, I agree. If I’ve said it once, I’ve said it a million times: *design* is not *decoration*. So while I agree that most redesigns will involve changing markup, I disagree with the underlying premise that a redesign is a purely visual undertaking, and I disagree with the whole idea that one *should never have to touch* the markup. Which law is that? I would encourage anyone thinking that content/presentation separation or semantic markup (two completely different things) means that you’ll only need to change the CSS, to challenge this thought. They’re missing the point. This type of thinking reduces design to simply mean decoration. I didn’t study decoration for four years. My clients’ websites aren’t MySpace. We’re not *skinning* here. Since markup is *structural*, changing the structure of a design will certainly demand markup changes, and there’s nothing wrong with that.

Which brings me to CSS frameworks. Hmmm. Building a site so that you “only” need to change the CSS. This is pretty neat from a geek standpoint: can it be done? Is my framework better than your framework? But in reality, these CSS frameworks dictate to a certain extent how you’ll set up your structure. But shouldn’t the content dictate that?

Structure and meaning

*The separation of structure/content and presentation is meant to manifest itself to the end user, not to the developer.* When a site is stripped of all visual elements, the structured content of the site should still be accessible to the end user. There are two kinds of structure: document structure and visual structure. Document structure is the structure of the content itself. Visual structure is the physical structure of a page. We can distinguish these elements from each other through the use of semantic markup.

Semantic markup is all about meaning. When I say something is an “attention block”, I know what that means. Most importantly, fellow or future developers can figure out what an attention block is fairly quickly, even *sans* documentation. I can distinguish an attention block from an “urgent block” semantically, as opposed to only visually. But with all due respect to Jeff and others, what the hell is a *span-4* or a *pull-2*? And how does this help future developers? Colleagues when I move to another company? Or portability, when the client wants a DocBook PDF of the entire site?

The new WYSIWYG

CSS frameworks are a nice idea, but they introduce the same problems the JavaScript frameworks or app/CMS frameworks introduce: they try to make things easier for the current developer, and in doing so make it terribly easy for less-experienced developers to create terribly scary, unruly HTML and CSS, while they don’t yet fully understand the basics. Sound familiar? Isn’t this the exact reason we hate WYSIWYG editors? Could CSS frameworks perhaps be the geek equivalent of WYSIWYG? With most frameworks, you must first get to know the framework if you want to work with it effectively. But we *already* know HTML and CSS. So what happens when client X asks me to do a redesign of site X, which uses CSS framework X? I either have to learn how framework X works and rework the site *that* way (focusing on implementing new elements using the framework, which will translate into costs for the client), or I’ll have to rebuild the whole thing. Rebuilding the whole thing is very tempting, because restrictions will be removed, and I can approach the site based on content, structure and visual design using the very basic tools of semantic HTML and CSS. The site will be portable and maintainable: anyone knowledgeable in HTML and CSS can maintain it; semantic markup is understandable markup. The site will be fairly future-proof, independent of framework version changes.

I’m not saying that frameworks are bad, but I challenge the *reasons* often given for using them. I consider them mainly beneficial to the initial developers. I also challenge any excuses designed to defend the discarding of semantic markup. I just don’t buy that *span-4* and *pull-2* are necessary. You have to use class names anyway, why not make them meaningful?

Use CSS frameworks if you will, but really consider your reasons for using them. Weigh the pros and cons. Not only for yourself, but for the site, the end users and your client, which also means future developers. Think about portability. Think about the fact that visual design is not simply decoration. Consider that visual design and document structure, although separated for portability/durability and the accessibility to the end user, are in fact inseparable.

As designer Paul Rand once said, “Design is a method of putting form and content together”. Our methods should involve embracing and strengthening this relationship, instead of working against it.

Company X violates Cinnamon copyright

This post has been edited since first publication. See my lengthy explanation.

Update: Company X have changed their site as of May 22, 2007. They seem to have removed our material.

Note: This is my personal reaction to Company X’s violation of Cinnamon’s copyright, and is not necessarily the reaction of our company. Cinnamon’s post can be found at the Cinnamon Blog (in Dutch).

I hate it when people call themselves designers and then blatantly steal the work of other designers and imply that it’s their own. And that seems to be what Company X Design (“Design” is perhaps an overstatement) has done with elements of the Cinnamon design. It’s so blatantly done, it’s laughable. I mean, at least *tweak* the damn design—change the color or something—like any self-respecting talentless hack would. Once again, we seem to support my theory that most copycats are complete idiots. As opposed to the last time, I’m now armed with screenshots.

[screenshot removed]

This is not a debatable point. It’s not a question of *if* copyright has been violated, but in how many ways. Three, from my first observations. All in the header. Let’s examine this using some comment overlays.

First, the type image. [screenshot removed]

Secondly, the tagline under that image. [screenshot removed]

Thirdly, the small images used to lead to our portfolio. [screenshot removed]

I wrote a polite but firm e-mail to these people requesting that they remove the offending elements within 24 hours. They did not. (Update (2007.05.20): I did receive an e-mail from them today, dated May 18, in which they ask me to specify exactly which images and text I am referring to. No contact information and no name was given. I promptly sent a non-sarcastic version of the above screenshots.) I threatened appropriate action if they did not. Obviously this made no impression. Now I’ve posted this. Company X, it’s your own fault. This was the appropriate action I was going to take. A simple blog post. Everything I know about search engines tells me that when people search for you, there’s a decent chance they’ll see this post. Since every time someone comes to your site they see elements of our work passed off as yours, it seems a fair trade. Enjoy the free publicity.

Now I’m willing to bet a few things, and I’ll update this post as they happen, just to increase my Nostradamus-factor:

1. Company X have at least one very good reason to have not answered my e-mail (beware: I *will* post your sorry excuse here). I have received an e-mail response. See above.
2. They will indicate that someone else did the design for them, or they bought it, or some such worthless bullshit, and that they had no idea that copyright infringement had taken place.
3. Who? What? Huh?

I don’t mind if people allow themselves to be inspired by my work and the work of my team, but don’t steal it and pass it off as your own.

Have a nice day.