Thinking inside the box

While doing my routine check of the latest user experience and design blogs I ran across this gem from Smashing Magazine. It breaks down the inner workings of the new flexbox model provided by the latest CSS3 specifications. This is definitely a must read if you care at all about the flexible box model

Some of the key features worth keeping an eye on include

• Automatically adjusting relative widths of children elements
• Controlling the presentation of elements purely with CSS
• Borders that span entire columns without ugly hacks

Like most of you I have done my fair share of battles with CSS floats, trying to get proportional formatting right, and doing complex mathematical gymnastics to get to a final goal. While this is still under development and I am certain subject to many iterations before it is properly supported at least it is a move in the right direction. I know that I for one will be playing around with it this weekend so I can add it to my toolkit.

Common sense defaults

Over the years I have read a large number of pieces advocating the use of sensible defaults. Stephen Anderson's book Seductive Interaction Design devotes two pages to the topic with proof about the why and how (one of many reasons to order a copy as soon as you can).

Today Jared Spool provides even more validation. By performing a simple experiment with Microsoft Word he found that less than 5% of users change any settings. In other words 95% of people touching your product will assume there is a reason that the default settings are configured the way they are. Rather than fix them they'll go with the status quo.

I highly recommend reading the piece when you get a minute. The questions it asks apply not just to those of us trying to design the experience but the people actually writing the code. You may be surprised at all the assumptions that sneak through into the final design.

Design is intentional

Recently this argument about the dangers of premature design optimization came across my stream. There was a point a few years ago where I used to think the same thing - you write your data models, your business logic, and other pieces before focusing on the 'V' in MVC.

Experience these last few years has shown me this is a very bad idea. Waiting to address the user experience until the last part of the project means that it gets bolted on. Instead of discovering usability issues when they are relatively cost effective to fix they end up being potential showstoppers. Sadly this attitude that 'design is just a phase' seems to persist today.

My advice to anyone looking to start a project is to get in contact with someone as soon as possible. Figure out what types of user interactions work before it becomes impossible to correct them. Not only will you have an easier time with the visual design and information architecture but you may find yourself avoiding developmental dead ends as well.