Design in Norway

Leave a comment

A couple of weeks ago I had the pleasure of attending ndcoslo in Oslo Norway and was pleased to see how deeply the Norwegians think and care about design.

Take this hotel room key for instance. No need to insert your key into any slot (or use a key). Just hold it near your door and your in. Very nice.

Inside if you need the lights on, simply insert your card into the key holder and the lights come on (they do this in Japan too).

What? It’s dark and you can’t see where to insert your key? No problem. We will light it up with an orange light so you can see in the dark.

Here is the soap dispenser in the bathroom. One big simple push and you’ve got soap.

Here’s the heated towel rack.

Here’s the dead simple shower controls.

Configured to an optimal heat setting (38C). Nice.

With one simple soap dispenser (All Over Shampoo).

Here is what you will see on a bus when your stop is coming up.

And they’ve got beautiful churches like these built centuries ago

And their own opera house to boot!

Of course not everything is perfect (I am not a fan of these milk dispensers).

But I like the affordances and thoughts to give to people (of every culture).

Over all I have to say I was very impressed with Norway.

It reminded me a lot of Japan.
Beautiful design.
Generous people.

And you can just tell over there they still give a darn about how things work.


How to create background color gradient using adobe illustrator


To create a repeating background for your website using a gradient affect that looks something like this:

do the following.

Adobe illustrator CS5

Draw a square.

Open the gradient window (Window -> Gradient)

Click the gradient box (will apply black to white gradient).

Open the color pallette (Window -> Color) and get both the color and gradient window on screen at the same time (tricky because Adobe UI is terrible).

Once you’ve got them both up, click and drag the colors you want for your gradient from the color palette down to the ends of the gradient.

Transform and slim the gradient until your happy. Save this image somewhere you can access from your website. Remember to reduce the size of your canvas (Shift -O) to make sure your image is slim when you export it.


Now apply the following CSS to the body of your website:

body {
		background-image: url('../images/bg_body.png');
		background-repeat: repeat-x;
		background-color: #c9efed;
		height: 100%;

This takes the gradient we just created, and repeats it across the screen and applies a default color to anything below your gradient image where is runs out.

Voila! That’s it. You’ve now got a nice background to build off of.

Refactoring css

1 Comment

css is one of those things I am desperately trying to get good at, and a big part of that is knowing how to structure and refactor your css files.

Here’s a good example of some ugly css from Christian Heilman’s design chapter in Smashing Book#2.

#pagetitle {
  color: black;
  text-align: left;
  border-top-width: 2px;
  border-top-color: black;
  border-top-style: solid;
  border-width-bottom: 2px;

The first thing you can do to clean this up is logically order elements and use the shortcut notation.

#pagetitle {
  color: black;
  text-align: left;
  line-height: 1.3em;
  border: 2px solid white;
  border-color: black white white black;
  padding: 1em 2em;

The next thing you can do is move common denominators out of their specific selectors and collate them. For example you could refactor this:

h1  {
  font-family: helvetica, arial, sans-serif;
  color: #000;
  margin: 0.5em;
  padding: 1em;
  font-size: 150%;
  background: #ccc;

h1  {
  font-family: helvetica, arial, sans-serif;
  color: #000;
  margin: 0.5em 0;
  padding: 1em;
  font-size: 120%;
  background: #999;

Into this:

h1, h2, h3, h4 {
  font-family: helvetica, arial, sans-serif;
  color: #000;
  margin: 0.5em 0;
  padding: 1em;

h1 {
  font-size: 150%;
  background: #ccc;

h2 {
  font-size: 120%;
  background: #999;

See the difference? All the common stuff is up top, and only the difference are showing below. Way better.

How not to name your css classes and id’s


Continuing on with Christian Heilmann’s excellent chapter ‘Red flags in web design’ I loved this section about how not to name your css class and ids.

Here are some examples of really bad class and id names:


Basically anything that describes what the element looks like, and not what is it doing.

Here would be some better names:

greenMessage -> confirmation
largeBoxRight -> leanSideBar
redIntroText -> warning

See the difference? Applying this simple check will make your code a lot more readable and easier to maintain and understand. Thx Chris!

For more good tips on design and development checkout Smashing Book#2.

How and when to use a css class


The Smashing Book #2 has a great section by Christian Heilmann on how and when to use css classes.

“Classitis” as Christian calls it is when classes are used everywhere. Instead of just using classes selectively to make certain elements standout, people add classes to everything and then let jQuery do it’s magic.

This can quickly turn into a maintenance nightmare because as soon as a class name changes, you’ll have to search your entire code base for all changes.

Here’s an example Christian gives on how NOT to use css classes:

<ul class="shopping-list first">
  <li class="list-item">Cucumber</li>
  <li class="list-item important">Apple</li>
  <li class="list-item">Orange</li>

Christian’s main rule for applying css classes is:

add a class to mark the odd one out and to group elements not already grouped.

Here is how to do it right:

<ul class="shopping-list first">
  <li class="important">Apple</li>

Instead of using .shopping-list .list-item to style, all you need is .shopping-list li.

You modify the important one with .shopping-list li.important, and then you don’t have to worry about the class specificity of .important versus list-item.

For more good examples of does and don’t about web and design, be sure to check out the excellent Smashing #1 and #2 books.

How to design stuff that matters fast – Eewei Chen


Great session this afternoon with Eewei Chen as he walked us through some great rapid prototyping techniques for ideation.

Step 1: Create an empathy map / persona

Fill in the various sections creating a persona for the person you are building the app for.

The categories are:
– Behavior
– See (motivations)
– Do (features)
– Say
– Feel

Step 2: Map features – what do I want to do?

Take the features you mapped from step 1, and start flushing them out down here.

Step 3: Can I use it?

Now walk the use through using your app made up of your highest priority most valuable features.

Step 4: Elevator pitch

Step 5: Pitch it!

Special thanks to Eewei Chen for hosting such a great session. Eewei was prepared, he had the materials, all the personas were nicely laid our around the room, and you even pre-filled in our elevator pitch butcher paper.

Great session.

Thanks to Ariadna Font and Adrian Smith for being awesome partners.

I am already thinking about how we are going to spend our millions once we build it 🙂

Create great looking mock-ups with Balsamiq

1 Comment

Several people have asked me what tool I used to create the screen shots used in the YAGNI vs Usability post.

The tool is called Balsamiq. And if you are looking for a simple, quick, easy way to create great looking screen mockups, it is a tool I highly recommend.

Dead easy to use

One of the things I like most about the tool is how easy it is to use.

With its easy drag-and-drop interface, designers could learn a lot from just studying how Balsamiq was built and designed.


Good plugin community

And because Balsamiq is so open and configurable, there is a decent plugin community for Outlook, Facebook, and iPhone apps.


Making mock-ups is just fun

For no other reason, I like this tool because it’s funky, fun, and actually makes the creation of paper based looking mock-ups really cool and fun.

So if you are in the market for a tool like this, check out Balsamiq. It is well work the low price of $79.

YAGNI vs Usability

Leave a comment

YAGNI (You Aint Gonna Need It) is a reminder to all who write software not to over engineer your designs, keep things simple, and add complexity only when necessary.

Usability, on the other hand, is about improving the users’ experience with the software—additional architectural complexity be damned!

YAGNI vs. usability are two forces that sometimes bump on agile projects.

This post looks at a simple example of how these forces can conflict, and how teams can help find the right balance for their project.

Keeping it simple

My last project was a web based application that showed users at a construction site which roads were closed on any given day.

One of the stories was called display road closures and the first version of the story looked something like this.


With a simple date based search at the top of the screen, the user simply enters the day they are interested in seeing road closures. They hit the search button, and the map refreshes showing which roads are closed, along with the search results at the bottom.

Delighting your customer

During development, my partner came up with a better way to visualize which roads were associated with which permits. Instead of simply displaying road closures in red, why not give each road closure a different color. And while we are at it, why not make the search results selectable—so that when the user clicks on a road closure at the bottom of the page, the associated road on the map becomes more bold and visible to the user?


I thought his idea was great. It required a fair bit of custom JavaScript, which would add some complexity to the UI. When asked how long he thought it would take, he said about an hour. Thirty minutes later it was done and integrated into the code base much to the delight of our customer.

Playing the YAGNI card

Deciding whether or not to implement this feature was a no-brainer. My partner had the necessary JavaScript chops, the cost was minimal, and our customers loved it.

But what if the trade-off wasn’t quite so black and white?

What if we didn’t know JavaScript?
What if the improvement, compelling as it was, was expensive to implement?
What if making the necessary change did require some heavy architectural lifting?

How should teams balance the desire of keeping things architecturally simple, with a desire to delight their customers?

See how you are tracking

Before getting all hot and bothered about whether to invest in an enhancement, or add a new feature, check and see how your project is tracking.


If your team is struggling to deliver stripped down, spartan versions of your customer stories as is, spending additional time on UI improvements is a luxury your project can’t afford.

On the other hand, if the team is on track, and the customer is happy with what they are getting, there may be a little wiggle room to make a few usability enhancements here or there.

And if your team is delivering ahead of schedule, all options are open. Go ahead and try the 13 shades of blue.

Know your project context


Every project is different. And not all have the same requirements around things like usability.

For some projects, a few fields and a submit button are more than enough. For others, nothing less than an aspirational experience will do.

Knowing ahead of time what your project requires, and how your customers feel about stories being ‘good enough’ will tell you whether you need to spend more or less on usability and the experience of the user. Putting working software into your customers’ hands sooner rather than later will serve you well.

Don’t be dogmatic

While YAGNI is certainly a sound architectural principle, like any sound principle it can be taken too far. When YAGNI is repeatedly used as a trump card to prevent improvements to user experience, it can upset team members, and cost the team an opportunity to better serve their customers. Not all usability enhancements need to be expensive, and sometimes the smallest of changes can make the biggest of impacts.

Like most things in life, it comes down to striking the right balance. The only way you’ll find out is if you build something, show your customers, and get some good solid feedback along the way.

Until then, you’re just guessing.

%d bloggers like this: