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:

1. No more abusing floats, and no more getting abused by floats
2. 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.

<div id="products">
    <p id="phones">First child</p>
    <p id="computers">Second child</p>
    <p id="fast-cars">Third child</p>
</div>

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!

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:

1. Many don’t know what they want, and when they do, they don’t know how to communicate it
2. 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.”

Some good things past

2009 certainly wasn’t all bad. There were plenty of good things. Vacation here in Holland with the kids and having my sister over to visit was fantastic, as was our week in Portugal (it was my first time there and I loved it.

I finally started understanding that doing some nice things for myself is a good thing, not selfish, and very necessary. I still didn’t do enough it, though. This website still needs a design. At least that design is coming along nicely.

If the worst problems in life are people problems, then the opposite is also true: the best moments are people moments. People who inspire, make you laugh, people you can have fun with. (Fun. Hmmm. Need more of that this year.)

There were some great people moments in 2009. Great personal, family moments, but also new contacts and friendships. I’ve also had the pleasure of meeting, becoming friends with and even working with some of the finest minds in web development. People who inspire me and make me want to become better at what I do. You know who you are. And last but not least my team at Cinnamon; we spend almost every day together and despite ups and downs, we still worked hard to kick web ass for our clients.

I didn’t do a lot of speaking last year, but I was glad to be a part of the events where I did speak. I was honored to have been invited to speak about CSS3 layout at Fronteers in Amsterdam. Grip2009, the workshop event that Cinnamon and Eend hosted, was a success and a pleasure to do.

Some good things to come

There are so many cool things going on in web development right now, and so many things I’d like to do. That’s my problem, as those who know me well have witnessed: too many interests. Trying to whittle them down to something manageable is futile.

I won’t pretend I will have the time or inclination to do everything I want to do this year, but I’ll be happy to get any of them done. These are not New Year’s resolutions; I never finish those. These are simply some of the things I’d like to do, accomplish or work on this year (aside from the usual stuff like running a company and having a family):

• I’d like to evangelize CSS3 layout even more, through writing, screencasts and speaking engagements. As a matter of fact, I’m enjoying speaking and would like to do more of that as well.
• This website needs a design, badly.
• There are a couple of really cool projects I’m planning with really cool people which are still non-public. I’d like to work on these and make them known.
• I want to finish the book proposal I started more than five years ago.
• I’d like to start training martial arts again, so my body doesn’t always feel like I’ve been hit by a truck.
• Exotic vacations, become rich, have nice cars… oh, wait. Got carried away for a minute.
• Be as prolific and productive as Chris Heilmann. Or half. Or a third.

I could go on and on, but trust me, it would hog some serious bandwidth.

Most of all, I want to do what I love, to look on the bright side of things, to see possibilities, to enjoy my friends and family, to have some fun, and to do it all in good health.

I wish you the same.

I’m assuming that readers of this website are at least vaguely familiar with the WCAG. If not, you can read more about them on the WAI website, as there is no reason to repeat that information here.

26 organizations worked in varying capacity on this translation, including Cinnamon, represented by myself. The translation was coordinated by Stichting Accessibility, and follows the official procedure for authorized W3C translations.

After the review period, this candidate translation will be modified where necessary. It is expected that a finalized version will follow in December 2009. The current draft is not the finalized version, and may not be published as such.

Please help us review!

If you would like to review, you’ll need both the original English version as well as the candidate Dutch translation. Please send all comments to public-auth-trans-nl@w3.org.

Please note that the review is intended to ensure the correctness of the translation. The actual content of the draft will not be changed.

Please help out if you can! If you can’t review yourself, perhaps you can spread the word about it.

A Dutch-language press release is available (PDF, 72kB).

It’s for this reason that Eend and Cinnamon have spent a lot of time putting together a workshop which we feel will help clients, their project leads and/or managers to get the best out of the web shops they hire. The two-day workshop has been designed to expose clients to the potential success factors and pitfalls on their side of the project, and to give them the tools to use this knowledge to their advantage. The entire project process from bidding to post-launch evaluation will be examined. We’ve got great speakers with very high-level, client-side web project (management) expertise, as well as a few on the development side for a well-rounded whole.

Grip—or rather Grip2009, as this first workshop is called—will be held on November 17 and 18, 2009, at the very posh (no, not that POSH) Grand Hotel Karel V in Utrecht, The Netherlands.

While there are plenty of workshops and conferences for developers on building better sites, there is little practical information for clients on how to ensure a successful web project. We’re excited about Grip2009. We hope it will give clients the tools they need to engage with their web contractors like never before.

Unfortunately, this first edition of Grip will be completely in Dutch. We haven’t ruled out an international (English) event for the near future.

For any Dutch readers, here’s the press release (feel free to distribute):

BEGIN PERSBERICHT —

Grip2009 – Tweedaagse workshop voor webprojectleiders

Op 17 en 18 november 2009 wordt in Grand Hotel Karel V te Utrecht een tweedaagse workshop voor opdrachtgevers van webprojecten gegeven: Grip2009. Het programma is samengesteld door ervaren internetprofessionals en levert, naast nuttige tips, bruikbare kennis en vaardigheden uit de praktijk om grip te krijgen op webprojecten. De nieuwe workshop, die dit jaar voor het eerst wordt gegeven, richt zich op opdrachtgevers die hun internetprojecten beter willen begeleiden.

Voor opdrachtgevers van webprojecten bij het bedrijfsleven, not-for-profit-organisaties en de overheid is er momenteel weinig concrete en in de praktijk bewezen informatie beschikbaar hoe deze projecten tot een succes zijn te maken. Dat verandert met de komst van Grip2009. De workshop is bij uitstek geschikt voor mensen die aan klantzijde betrokken zijn bij de inkoop, de ontwikkeling en het beheer van internetprojecten, of mensen die een carrièrestap overwegen in deze richting.

Er zijn maximaal 60 plaatsen beschikbaar voor dit unieke evenement. Snelle beslissers kunnen tot 16 oktober profiteren van een flinke korting. Meer informatie vindt u op: www.grip2009.nl

EINDE PERSBERICHT —

css_color.vim in action: hex values are underlayed with the corresponding color.

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 <aside>.
• 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.

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.