The Haystack. » Design

Learn You a Flexbox for Great Good!

Stephen — Wed, 04 Jan 2012 21:48:59 +0000

So you want to learn Flexbox? Perhaps you’ve heard about it. Perhaps you’ve read a tutorial or two about it. Perhaps you’ve even played around with it already.

If you’ve never heard of Flexbox, or if it’s been awhile since you’ve used it, forget what you know. We’re starting over! The spec has been rewritten; the last version at the time of this writing is dated 29 November 2011!

What you’ll need

Currently, Chrome Canary has a partial implementation of the spec. If you’d like to follow along, you’ll need nothing more than Chrome Canary and your favorite text editor.

Chrome Canary: http://tools.google.com/dlpage/chromesxs;
Your favorite text editor: http://www.vim.org/ (Relax, relax)

Ready? Let’s get to it!

What is Flexbox?

Flexbox is a nickname for CSS Flexible Box Layout Module. It’s one of a few CSS Working Drafts having to do with visual layout. Flexbox offers us a new box model which has been optimized for laying out user interfaces. In short: the children of a “box” can be ordered either vertically or horizontally within their parent, and we can control what happens to any remaining space. It is possible to nest these boxes, allowing for very complex layouts.

Caution!

There are other CSS layout modules in development which, in my opinion, are much more suited to general page layout than Flexbox. Flexbox is fairly straightforward, but can become unruly when used for complex layouts. In any case it is not the best solution for all types of layout. But for UI-components like buttons, forms, toolbars or rows and columns of content/media blocks for which you’d normally use floats, Flexbox makes code simpler and is a huge time-saver. Flexbox is designed to play nicely with existing CSS properties. Thus, you are still free to use floats or other types of positioning on non-Flexbox elements.

Three Little Boxes

If you’re feeling a bit lazy, you’re welcome to simply download and edit the demo page Otherwise…

Open your editor, create a simple HTML document with a single box. In this case, we’ll use a div:

Great, But it would be nice to see something, so we’ll have to add some style:

Now we’ll put three boxes into our div. These are, of course, the first div‘s children:

Let’s style those as well:


    div>div {
        width: 100px;
        height: 100px;
        background-color: pink;
    }

Now look at this page in Canary. Nothing unusual here, just three block-level elements one under another, as block-level elements are known to do. But we’ll put a stop to that. We’ve created our own Flexbox playground, so let’s play.

Defining a flexbox

We would like to apply the magic of Flexbox to the children of our parent div. We do so with the display property. By applying display: flexbox; to our parent div, we tell it to use the Flexbox box model. If we wanted our parent div to be inline instead of block-level, we’d use display: inline-flexbox;.


    body>div {
        display: -webkit-flexbox; /* We need the prefix for now, unfortunately. */
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Our three child divs, which we’ll call flexbox items from now on, now live according to the Flexbox box model. Beware: there are rules that determine what a flexbox item is. For example, if we were to use position: absolute; on one of the three boxes, it would no longer be a flexbox item since we’ve applied a different positioning model. Read more about flexbox items in the spec.

Back to our little exercise. Take a look at the page in your browser. The flexbox items look a bit as if we had applied inline, inline-block or float to them. This is because the Flexbox default is to position flexbox items horizontally. The main difference so far is that we have only added a rule to the parent and not to the items themselves.

Source-order independence

Flexible Box Layout Module gets its name from the fact that it allows us to create flexible boxes. In other words, boxes can become flexible by utilizing available space. We’ll get to that in a minute. But Flexbox offers something at least equally important to us, especially in this Age of Mobile: source-order independence. Let’s play around and see how we can change the order of flexbox items.


    body>div {
        display: -webkit-flexbox; 
        -webkit-flex-flow: row-reverse;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

OMG. Our flexbox items are now right-aligned and the order is reversed! We do this with the flex-flow property, for which row is the default value. row-reverse flips this around. You might have already guessed that when you want to position flexbox items vertically, you would use column or column-reverse. At the time of this writing, Canary does not support column-reverse, but try out column and see what happens! When you’re done playing around, set the value back to row and we’re ready for our next step.

By the way, flex-flow also takes a value for wrapping flexbox items to new rows (or columns, depending on which you’re using). The values wrap and wrap-reverse serve this purpose, as the default is a single row (or column) of flexbox items which overflows the parent. wrap and wrap-reverse still haven’t been implemented at the time of this writing (I’m saying that a lot). But let’s say, just for fun, that we could use wrap today:


    body>div {
        display: -webkit-flexbox; 
        -webkit-flex-flow: row wrap; /* `wrap` gives us a multi-line flexbox. */
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Mirror, mirror…

All the properties dealing with order, direction or alignment of flexbox items are influenced by the current writing mode. The writing mode is the original direction of the text. Many of us are used to top-to-bottom, left-to-right. But as soon as these are changed, the output of the directional Flexbox properties will also change. You’ve already seen what row-reverse does. But what if your writing mode isn’t the default (top-to-bottom, left-to-right) but top-to-bottom, right-to-left? Your flexbox items would be laid out from right-to-left in the first place, and row-reverse would flip things so they’re left-to-right.

Try it out:


    body>div {
        display: -webkit-flexbox; 
        direction: rtl; /* The `writing-mode` property currently has no visual effect in Canary. The `direction` property will suffice for our example. */
        -webkit-flex-flow: row;
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Look at the page in your browser. Now replace row with row-reverse. See what happens?

Confusing? Perhaps a little at first, but the properties all work logically based on the current writing mode. As most of us usually work with the same writing mode most of the time, it shouldn’t be much of a problem.

In order to understand the effect many Flexbox properties have on flexbox items, it is important to understand what the main axis and the cross axis are. The main axis is the axis along which the flexbox items are placed. In other words, if the flexbox items have been placed horizontally (flex-flow: row;), then the main axis is horizontal. The cross axis is perpendicular to the main axis. In our example, that would be vertical. When using flex-flow: column;, this is switched: the main axis is vertical and the cross axis is horizontal.

That’s a pain to explain well. Just to be sure we’re clear, here’s an illustration:

Remember main axis and cross axis, because we’ll need them in a bit.

Order! Order in the court!

Let’s look at another property which helps the cause for source-order independence: flex-order.

In your example code, make sure you’ve set flex-flow to row and have removed direction: rtl;. If things are as they should be, you’ll have three flexbox items: A, B and C, in the top left of body>div. Imagine that although our code contains these items in that order, that we want to display them in the order A-C-B. To do this, we’ll use flex-order:


    div:nth-child(2) { /* Yes, I could have used an ID or a class. But, hey, whatever. */
        -webkit-flex-order: 1;
    }

Check things out in your browser. The order of the flexbox items should be A-C-B.

flex-order places flexbox items into ordered groups. Boxes without an explicit flex-order are in group 0 and remain in source order. In our example, the second flexbox item (B) is placed in group 1. A and C remain in group 0 and in source order (A before C). Since group 1 comes after group 0, the B comes last. If we had wanted the order B-A-C, we could have left B in group 0 and put A and C into group 1:


    div>div:first-child,
    div>div:last-child {
        -webkit-flex-order: 1;
    }

Flexibility

One of the nicest aspects of Flexbox is the ability to create flexible elements. We can decide what to do with any remaining space in our body>div (in this example). We can divide this space up between the flexbox items, or we can make the widths or heights of one or more of these items flexible, alotting a certain amount of available space to each.

We’ll look at flexibility first and then come back to distributing available space.

Imagine that our three flexbox items are buttons in a web application which might also be used on mobile devices. Sometimes we have three, but sometimes we only have two (just nod and go along with it). We’d like to say, “No matter how many of these buttons there are, I want them all to generally be the same width, and these widths should be such that the row of buttons takes up all the available width of the parent.” We’d normally resort to Javascript for these types of layout problems, but Flexbox might put an end to that. See what happens when we make our flexbox items flexible with the flex() function:


    div>div {
        /* width: 100px; */
        width: -webkit-flex(1 0 100px);
        height: 100px;
        background-color: pink;
    }

The flex() function can be used as a value for width or height. flex() takes three values: positive flex, negative flex and preferred size. The last two parameters are optional; the default for negative flex is 0 and the default for preferred size is 0px. Here’s how flex() works in a nutshell:

The preferred width is applied to the flexbox items.
If there is any space left over in the parent, this space is divided up into parts and added to the widths of the flexbox items according to the positive flex value.
If the flexbox items overflow the parent (e.g. together they are wider than the parent), then the negative flex value is used for determining the widths of the items. Please note that negative flex is a positive value (e.g. 2 and not -2).

A positive flex value of 1 basically means “one equal part of the available space”. A value of two would mean something like “twice the amount of available space as the items that have flex(1)”. So it’s nothing like “two parts whiskey, one part cola”. The easiest way to learn it is to try it out. Type the following code under your rules for div>div:


    div>div:first-child,
    div>div:last-child {
        width: -webkit-flex(2);
        background-color: magenta; /* This allows us to see the difference clearly. Plus, it hurts your eyes. */
    }

If you check your browser, you’ll see that the first and the last flexbox items don’t each have 2 parts of the available space. Rather, they have two times as much available space as the middle box, which has flex(1). I know, I know. Just be glad you’re not a browser maker. Unless you are, in which case: have fun and please get this implemented ASAP!

Also, please note that this does not mean that the two outermost boxes are two times as wide as the center box. We’re only dealing with how the available space in the parent is being distributed.

Remove the declaration you just added. Remove one of the divs and look at the result in your browser. Once you’ve seen what happens, put the div back in again.

There’s plenty more about flex() and any other gory details you might want to know about Flexbox; these can all be found in the spec.

Alignment of flexbox items

Did you remember everything about main axis and cross axis? Excellent. Because the flex-pack property determines how flexbox items are aligned along the main axis. In our example file, the main axis is horizontal. In order to study the effect of flex-pack, remove flex() and change the width back to 100px:


    div>div {
        width: 100px;
        height: 100px;
        background-color: pink;
    }

flex-pack accepts one of four possible values: start, end, justify and center. Pretty clear. Let’s center our flexbox items. We do this on the parent:


    body>div {
        display: -webkit-flexbox; 
        -webkit-flex-flow: row;
        -webkit-flex-pack: center; /* <-- */
        height: 500px;
        padding: 1em;
        background-color: gray;
    }

Go ahead and play with the other values until you like it.

Of course, there is a property for aligning flexbox items along the cross axis: flex-align. The possible values differ slightly from flex-pack. The most important thing to remember is that while flex-pack is applied to the parent of the flexbox items, flex-align is applied to the flexbox items themselves.


    div>div {
        width: 100px;
        height: 100px;
        background-color: pink;
        -webkit-flex-align: center; /* Also: start | end | baseline | stretch  <-- Try these vales as well! */
    }

Not all the values are supported yet, but I don’t think we’ll need to wait very long. As the spec solidifies, implementation should come fairly quickly. The browser makers are quite interested in Flexbox.

Enough! Time to play

There are a couple of other properties having to do with multi-line flexboxes, but since we can’t try those out yet, we’ll stop here for now. Hopefully we’ve handled enough material to get you started playing around with the “new” Flexbox. Try and consider practical applications. How could Flexbox help within the context of “responsive design” and mobile? What possibilities open up for form styling? Navigation?

You don’t need to be able to use this today in actual projects to learn and experiment with the possibilities. Implementation might come quicker than you think, and you’ll already have a head start.

Have fun!

Note: This article first appeared in the Dutch language for the Fronteers Advent Calendar. Payment for the article was a modest donation to ICCF Holland.

It’s okay to do adaptive layout. Really.

Stephen — Tue, 22 Feb 2011 21:31:28 +0000

Vasilis wrote yesterday about how he altered the layout of the Tropenmuseum website (English homepage) to adapt to different screen sizes.

Then came the comments. Nothing really wrong with any of them, but the whole “layout is not the only thing that should concern you; performance/context/content/blah is also (maybe even more important)” thing is getting very tired. Why? Because nobody is saying those things aren’t important.

Here’s a fact: If the homepage of site [x] is 100kB, then it’s 100kB. If I make that page look decent on several devices via adaptive layout—unless I go overboard—it is still going to be 100kB. Okay, maybe 101kB. It’s either zoom hell or not. So people can complain about that, but unless they’re willing to add to the client’s budget, the extra layout flexibility is (often, not always) a relatively quick readability and usability win. Device-agnosticism should be baked into the design approach anyway. There’s absolutely no harm in it.

So no, do not ignore content strategy and performance. And if you do content strategy, then you’d do well to be thinking about design. Device-agnostic design applies here as well.

Don’t feel bad about doing adaptive layout just because these other things are also important. It’s okay. Really.

Are flashy HTML5/CSS3 “demos” helping?

Stephen — Sat, 07 Aug 2010 07:41:39 +0000

The lack of forward movement in front-end web development by government agencies may be our own fault, says Chris Heilmann. And I agree. Completely.

I’ve been increasingly biting in my reactions to many admittedly fun but practically useless “demos”, “experiments” and other assorted HTML5 and CSS3 nonsense like CSS3 icons. I always get flack for this, and I probably will now.

While these experiments are easily defended—“just wanted to see what was possible”—they are generally non-complex (though they can be tedious; take one look at a CSS3 icon or font). They are, put bluntly, simply a way to show off. And as long as that works, it will continue. But what are these experiments helping, aside from the reputations of those who make them(!)?

Please note that many of these experiments utilize a technique that I and many other art directors and designers have used for ages, which greatly enhances product appeal. It involves simply combining two things you wouldn’t ordinarily expect to be together: CSS and fonts. CSS and icons. HTML and games. Peanut butter and chocolate—Hershey/Reese’s Peanut Butter Cups have used this to their advantage for years. And so forth. The first person to build real beer from Javascript will be speaking at conferences for years to come.

I could say more, but Chris Heilmann said it so well, there is no need:

Right now, we are happily thinking we innovate and push the envelope where in reality we are making each other go “Oooohhhh” while a large chunk of the audience that could benefit from our knowledge is stuck with really poor experiences on the web.

If you haven’t, please take a moment to read his article.

What we can learn from the Defiant Dog

Stephen — Sat, 13 Mar 2010 12:50:20 +0000

Ian Broyles‘ amusing one-page site Defiantdog.com features a photo of a dog, and a button containing the word “sit”. This is fabulously funny, considering that nothing (visible) happens when one clicks the button.

I didn’t think much about it until Vasilis van Gemert posted about it and Ian published some stats; at that point in time visitors clicked an average of 23 times per visit. 23 times is a lot of clicking, which means some conditioning and expectation are at work.

As pattern-seeking beings, we tend to follow our conditioning. A button must be there for a reason—let’s click it. It says “sit”, therefore the dog will probably sit, won’t it? 23 clicks on average indicates to me that the average user is not considering whether this is just an image or instead some type of interactive movie. 23 clicks indicates bell/salivate. Button/action-expectation.

Let’s say you have javascript disabled, for whatever reason. You fill out a form. You click the submit button, not knowing that in this case the developer has made a javascript-dependent button (this is common). You might say you have encountered a Defiant Dog: something which doesn’t do as it’s told, or doesn’t react according to expectations.

Ian’s fun experiment confirms two things which many of us know but are always worth repeating:

When users expect things to happen on our websites, it’s most likely that we have done something to trigger those expectations
Users will almost always think it’s their own fault (and may even click 23 times before deciding it’s not)

It’s been said that without expectation, there is no disappointment. While not a new idea, this take-away from the Defiant Dog is still timely, as you’ll notice anytime you see something you think should be clickable but isn’t. Or when a relationship is falsely implied between multiple UI elements.

Managing expectations is a design problem. It’s up to us as web designers to find the defiant dogs in our websites and applications, and get them to sit.

A gentle introduction to CSS3 Flexible Box Module (Part 1)

Stephen — Sat, 23 Jan 2010 09:11:25 +0000

Note: There is no Part 2 to this introduction, as the Flexbox spec has been changed significantly since this post was written. I did, however, write up an introduction to the newer version of the spec, though I couldn’t really call it Part 2.

A portion of what we do as web designers involves arranging elements horizontally or vertically on the screen. As of yet, CSS lacks a suitable mechanism for this task. Enter CSS3 Flexible Box Module (“Flexbox” for short).

Flexbox is one of three W3C draft specs (as of this writing) dealing with general layout issues and has its strengths and weaknesses compared to the other two. But as it has already been implemented in Firefox (and I predict there is a good chance it will be implemented in Safari in some form), you might want to play around with it. Even if it doesn’t get implemented in anything other than Firefox, some of the principles regarding flexible available space have already been injected into the other modules. Plus, it’s pretty fun.

The draft describes Flexbox as:

[...] a CSS box model optimized for interface design. It provides an additional layout system alongside the ones already in CSS. [CSS21] In this new box model, the children of a box are laid out either horizontally or vertically, and unused space can be assigned to a particular child or distributed among the children by assignment of “flex” to the children that should expand. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions. This model is based on the box model in the XUL user-interface language used for the user interface of many Mozilla-based applications (such as Firefox).

This is pretty clear. It implies two important things:

No more abusing floats, and no more getting abused by floats
We can create true flexible layouts, and the browser will do the calculations for us

Basically, Flexbox is a small part of XUL ported to CSS. Cool as it may be, I remain of the opinion that the power of Flexbox is in the layout of things like UI components (think forms and toolbars and such) rather than in general page layout. So let’s not get carried away and make Flexbox the new float. For general page layout, we need a true grid-based model; I’ll come back to that in the near future. For now, let’s dive in.

Flexbox gives us a new value for the display property (the box value), and eight new properties:

box-orient
box-flex
box-align
box-direction
box-flex-group
box-lines
box-ordinal-group
box-pack

Today, we’ll ease into this and just focus on box-orient and box-flex, and tackle the other properties in Part 2.

Let’s say we have three paragraphs, each of which introduces one of three product lines for a client website. Our designer has determined that these teaser paragraphs are to be placed adjacent to one another along a horizontal axis, essentially forming three columns.



    First child
    Second child
    Third child

How would you currently tackle this? Most, without thinking, would simply float these paragraphs, perhaps adding overflow:hidden; to the parent in order to clear the floats. Nothing very special. But we could also do it quite easily with Flexbox:


#products { 
    display: box;
    box-orient: horizontal;
    }

In the above code, we’re simply telling the parent to behave according to this (flex)box model, and to lay out all its children along the horizontal axis. No floats. Yay.

box-orient accepts four values, but two of them are important for all intents and purposes: horizontal and vertical. Self-explanatory.

The widths of the children remain as specified (or their inherent width if not specified). This means that if the total widths of all the children is less than the total width of the parent, we’ll get something like this:

But what if you wanted paragraphs one and two to have specific widths and paragraph three to adjust itself depending on the available space within the parent? Flexbox to the rescue:


#products { 
    display: box;
    box-orient: horizontal;
    }
    #fast-cars {
        box-flex: 1;
        }

Here, we’re telling the last child to become flexible, and to take up available space. Since we’ve only allocated space to one element, it will take up all of the available space:

Note that the element only becomes flexible along the orientation axis of the box; in this case the element becomes flexible horizontally.

The value for box-flex is relative. So if we were to make the second and third children flexible:


#products { 
    display: box;
    box-orient: horizontal;
    }
    #computers {
        box-flex: 1;
        }
    #fast-cars {
        box-flex: 1;
        }

These would each take up the same amount of available space, in fact dividing the available space equally between them.

Should we give the last child box-flex: 3;, then it would take three times as much available space as the second child.

Check out the demo ~~(this will only work in Firefox)~~ or download the demo source code (.zip-file, 1kB).

Without even considering the other six properties, there are lots of possibilities here. Although I am not in favor of using this module for page layout, it can be done, as you can see in the demo.

We’ll get back to the other properties at a later date. In the meantime, if you want to play around with this, why not? It will ~~only work in Firefox~~ work in Firefox and (newer) webkit browsers; just prefix the display value and properties with -moz- or -webkit- respectively:

display: -moz-box;
-moz-box-orient
-moz-box-flex
display: -webkit-box;
-webkit-box-orient
-webkit-box-flex

Please be advised: this is meant to be a surface-level introduction to a draft spec. At the time of this writing, most people won’t find this applicable to anything outside of experimentation. There is, however, value in learning about the content of somewhat lesser-known working drafts, if only to be able to compare one to another.

Enjoy!

A Gentle Introduction to CSS3 Flexible Box Module (Part 1) by Stephen Hay is licensed under a Creative Commons Attribution 3.0 Unported License.

Never Mind the Process, Here’s the Finished Website

Stephen — Sat, 16 Jan 2010 00:02:52 +0000

Praise be to Karen McGrane, who dared to defend Lorem Ipsum. Her article couldn’t be more timely, as the festering sore that is the Cult of Content-is-King-and-Design-is-Just-a-Decorative-Sauce-on-the-Content-Entree has started to bleed profusely. And it’s pissing me off. As is the alarming thought trend that all deliverables should mimic the final product.

On content

Content is important. After all, it’s content people who come up with job titles like Content Strategist, which pretty much means One Who Thinks About Content. Which content, for whom, when, where, why, how… It’s absolutely necessary, because clients don’t do it. Not at the level that it should be done.

Paul Rand, one of the most well-respected designers this world has seen, called design “a method of putting form and content together”. If you would agree with this statement (as I do), you can infer the role of the designer as the one who must successfully combine two components: form and content (the designer will first busy herself with the form component). These two are not mutually exclusive. They are separate components which share a common goal and should be developed on a parallel track to one another. This, however, does not mean that they should be reviewed by the client together at every stage.

On clients

Two quick facts about clients:

Many don’t know what they want, and when they do, they don’t know how to communicate it
Many lack the imagination to “see through” design sketches

These are the reasons we are hired in the first place. But these two facts have paved a dangerous path across the lawn of the creative process. An alarming number of web professionals today seem to advocate making preliminary deliverables mimic the finished product– the more accurate, the better.

This is, well, stupid.

It’s not stupid if don’t track your hours. It’s not stupid if you don’t care if or how much you are paid for your work. It isn’t stupid if you don’t mind doing twice as much work for nothing. Your clients will love you for it, and you’ll be doomed to continue doing it for the rest of your career.

On designing in the browser

When Andy Clarke first started talking about “designing in the browser”, I thought it was a great idea. Then people started misinterpreting this to mean “executing the creative process in the browser”. If Andy really designed in the browser, his designs would be shit. What he was of course referring to was the execution of a design idea in the browser as opposed to a tool like Photoshop, which doesn’t communicate Web Things the way a browser does. He strives for more realism in his deliverables. He’s simply working based on the two Client Truths listed above. And if you’ve ever done designs in Photoshop, you’ll know that applying client changes to those documents is akin to cutting off your own fingers one knuckle at at time. HTML is much easier.

That said, there is certainly a place for Photoshop sketches. It’s possible to put together a quick visual impression of a website in far less time than it would take to work out in HTML. I’m referring to the basic idea of a website, an impression of the design language, intended to gauge if we are on the write track before spending many more hours mocking things up in HTML, which is, in fact, templating. I am not referring to creating finished static design visuals. These are the bane of the web designer’s existence, and should be avoided at all costs. If you really understand your client’s needs, that means you’ve done your homework, and you’ve actually designed before the browser. Otherwise: baby steps.

On communication

Imagine that your job was to drive your client somewhere. They aren’t quite sure where they want to go, but a lot of sun would be nice. And perhaps water. You could drive them to California, but once they hear about Florida, they might prefer that and demand that you drive them there (at your cost, because you’re the one who chose to go ahead and drive to California).

A better way would be to communicate with the client, asking them if they prefer dry heat or humidity, surfing or Spring Break parties, earthquakes or hurricanes. Based on this information, you could show and tell about both places, help them weigh the pros and cons, and help them in their decision. Then drive. Only then.

Making websites is a process. Creativity is a process. Pacing and leading clients is a process. You’re not going to eliminate frustration by trying to come up with real content, a polished design and working browser functionality on the first go. You will lose money, though, and perhaps your sanity.

There’s a reason for storyboards. But wait, shouldn’t Pixar just go ahead and build and render the complete movie so that the studio execs can see how it will really look?. Then, if they like it, it’s done! Yeah, right. Good luck with that.

There’s a reason that advertising teams consist of an art director and a copywriter: design and content. They’re bed buddies. But these teams pitch ideas, and then work them out. That’s why we have wireframes. That’s why we have Photoshop. That’s why we have Lorem Ipsum. And that’s why we have, most importantly, good old pencil and paper.

On balance

Here’s what I think: some web professionals want to focus more on deliverables than on people. But guess what: it’s all about people. We need to help our clients along and communicate with them. If you want good deliverables the first time around, the answer is not to use “real” content and a design which is in fact finished HTML/CSS/Javascript in a real browser. The answer is to ask focused questions, discover the pressing problems, to introduce your client to your potential solutions to those problems. Give them tidbits: here’s an impression of how the site could look visually. Here are some things you might want to consider concerning your content. Work your way up to real content in a real browser. When done right, that point can come quickly.

It’s too much to show a client all these things at once in the very beginning. There are too many factors, and it’s impossible to tell which factors will influence their opinions at that moment, which makes revision a nightmare at best. Of course content and form should each be developed with the other in mind. But consider presenting separately at first. Yes, that could mean that Lorem Ipsum is an option. That could mean that Photoshop is an option. That could mean that a sketch on a napkin, with a good, old-fashioned explanation of how things work, is an option. When you know enough, put form and content together.

On bed buddies

And forget the content versus design war. They need each other. In the words of Paul Rand, “when form predominates, meaning is blunted. but when content predominates, interest lags.”

Designing this site, part 2: Values, goals and requirements

Stephen — Fri, 24 Jul 2009 07:26:45 +0000

A week of hard client work behind me and it’s time to be my own client. And just as my clients would tell you when I badger them with the questions I’ll be asking myself, the first part of good design is not necessarily the fun part. It’s about asking questions, sometimes difficult, but always meant to encourage focus. Focus on what the website needs to be, and for whom.

As I mentioned last week, I’m redesigning this website, which for non-colorblind visitors is the pukey–green monstrosity before you. The color combination has been a joy to me, watching people dry–heave and reach for their feed readers while they still had the chance. But those days are numbered. I consider it quite unacceptable to be creative director of a reputable web design firm and not have a personal site which shows the same amount of thought and effort that goes into client work.

I’ll be putting my money where my mouth is, and using the same process I’ve evangelized for years and use for clients all the time. The Design Funnel is nothing new; many designers follow similar processes. I claim no patented process. It’s simply a (traditional?) process which I’d like to see more designers utilize, especially in this age of jumping–right–into–Photoshop, but also for those who don’t sketch before designing in the browser. It’s about thinking through before doing. It’s about design instead of decoration, which is so prevalent on today’s Web. This site is an example of decoration, and that shows. And that’s a pity.

Step one is defining values and goals. Defining the problem isn’t enough (and defining possible solutions at this point borders on evil—if you’re a designer, you know that a lot of clients tend to do this). My problem is pretty much stated in the second paragraph. But what’s important to me? Let’s not worry about formulating at this stage. This stage is about aggregation. To do this, I’ll answer some of the questions I ask my own clients.

What do I want (the site) to communicate, show, tell or do?

I work hard, with a talented team, for some awesome clients, many of whom are very happy with our work. Client work is nevertheless sprinkled with compromise and factors such as existing brain–dead branding by brain–dead design firms. This is actually the hallmark of good designers: working within constraints. But that doesn’t mean it’s easy. It also doesn’t mean the end result will fit your personal taste.

The Haystack should fit my personal taste. It should be what I feel is appropriate design, and I want to design it myself. It should demonstrate my ability as a designer and art director, and should adapt to the content I choose to publish. It should not overpower the content, nor should it be mere decoration for the content. It should be pleasurable to visit and read (okay, calmly, slowly, place the feed reader on the ground and kick it over to me).

It should be an online repository for all thoughts, ideas, discoveries, code, images, sketches and anything else I’d like to share publicly. It should be technically adaptable to my usual flurries of endless ideas, re-evaluation and mind–changing. It’s a bird, it’s a plane, it’s…

For whom?

I’ll be writing and posting about things for which I have a passion, and that means mostly design and web development, art, technology and any combination thereof. Therefore the audience will be (and is) industry creatives, developers and perhaps a few societal misfits and some very nice people. Oh yeah—some family and friends who will get here by clicking on the little blue E.

Any branding guidelines or creative considerations?

No brand. But the site should make a mark by being recognizable. Creatively, I’d like to be able to tailor the design of posts and pages to the content. Being able to art direct my own posts will be one of the biggest advantages to the redesign. Jason Santa Maria does this fantastically; he’s chosen not to let his CMS determine his design possibilities. The new site should allow me to art direct the full design of a post: type, color, layout and imagery.

It should be standards–compliant. It should be accessible. It should uphold basic usability principles, but I’m giving myself some space on that one. Usability purists, simply turn off CSS completely, thank you.

Technical considerations?

Write it in HTML5, just for the challenge of getting the design I want using a moving target. I will, however, think twice about using vague so-called “semantic” elements like
.
Use as much CSS3 as possible. Not necessarily the decorative stuff like border-radius et. al., but really cool stuff like media queries and the tastier selectors.
Use Drupal, because I’ve got 2+ years experience with it, and it will allow me the flexibility I want in implementing a design. Plus, it is quite awesome.

Next steps

Reading through this, I realize that if a client had sent this to me as their wish list, I would’ve had a conniption fit at the office. It’s a good thing I know what I mean by all of the above. Now that I’ve got it typed out, though, it’s enough to get the ideas flowing. We’ll cover it and let it simmer for a while.

And then it will be time to start sketching.

Designing this site: prologue

Stephen — Thu, 16 Jul 2009 09:29:19 +0000

I don’t blog much. Which is weird, because I have plenty of things I’d love to just get down “on paper”, so to speak. But I’m a designer. I love beautiful things. This blog in its current form doesn’t fall into that category. That makes it less enticing to deal with.

Fact is, client work comes first during work time. And family comes first during personal time (and work creeps in all too often). So when to blog? When to play around with stuff I can’t play around with (yet) in client work?

In one of our recent conversations on the highs and woes :) of web work, ppk suggested that I kill two birds with one stone: design my blog and write about the process. So I can actually do my own blog design (the current one is a third-party WP theme) and write on the blog at the same time, instead of waiting until the design is “finished”, which all of you designers out there know is never the case.

It made me think about what Mark Boulton and Leisa Reichelt did for Drupal, and what Andy did with New Internationalist. Not necessarily the part about inviting feedback (which was a key factor in Mark’s process), but the part about publishing the process. Being open about this process will allow me to “think out loud”. And I’m sure some of my talented friends will give helpful and critical feedback along the way.

So my thoughts at this point are basically:

Create the design I want, which should at least hint at the fact that I am an experienced designer.
Switch from WordPress to Drupal. While I like WordPress, I love Drupal and know much more about using it.
Use HTML5. Like it or not, HTML5 is coming, and now’s the time to start playing with it. Some problems with HTML5 are obvious, but others will only see light in practice.
Although I’m not a fan of the mainly decorative parts of CSS3 which browsers have been quick to implement, there are some parts of CSS3 I’d already like to take advantage of.

That’s a start. I’ll be posting my thoughts, sketches and experiences here, documenting what I can for myself and whoever might be interested.

We’ll see where it goes.

Paul Boag exposes web designer secrets

Stephen — Thu, 05 Feb 2009 20:37:27 +0000

The unholy and disgraceful Bad Boy of the Web, Paul Boag, has tarnished the good names of all web designers worldwide by exposing our deepest, darkest secrets (we have ten of them, BTW) in masked-magician fashion. This blasphemy was brought to our attention by an obviously saddened and shocked Andy Clarke, who also informed us that Paul was not the first one to let the cat out of the bag.

There’s no more hiding for us now, so go ahead clients: read all about how to get the upper hand.

The Design Funnel: A Manifesto for Meaningful Design

Stephen — Mon, 14 Jul 2008 18:02:17 +0000

It seems to me that in the past 20 years, design creativity has become increasingly driven and limited by design tools, rather than the brains using them. This leads to a high level of design sameness and general lack of creativity. Many (web) design curricula are now tool-based, and I notice many designers skipping or drastically shortening the thinking process behind a design, preferring to dive into Photoshop or (insert tool here).

If what Paul Rand once said is true, that design is a method of putting form and content together, then one of the fundamental tasks of a designer is to understand this content, and funnel the abstract wishes and values of the client into a usable design language (which can then be implemented using tools). Only then will the design have more meaning and creative depth.

I’ve advocated the large-to-small, abstract-to-specific process for years, and we utilize it at Cinnamon whenever possible. I’m happy to have had the opportunity to write a manifesto for ChangeThis describing this philosophy.

If you’re interested in a design process which encourages effective creative thinking (and therefore yields effective design), please check it out and give it away. And feel free to post your thoughts.

While you’re at it, go ahead and check out Hugh MacLeod’s famous and excellent manifesto on being more creative.