Better grids: Lessons learned from Design for Developers

After our first Design for Developers workshop in December, we shared a few examples of student work we especially liked.

The next Design for Developers workshop is just a few weeks away, and I thought it would be interesting to highlight some common problems our first group of students had while working on their projects, specifically around grids.

We asked all students to use the 12 column, 960 grid when designing their pages in order to focus their work. However, it was very common for students to build unnecessarily complex grids instead of taking advantage of the simplicity that the 960 grid offers. Let’s look at four examples of problematic grids, along with strategies for improving them. As you’ll see, the solutions are straightforward: make it simpler!

The uncomfortable quartet

The first two examples have a similar problem: they are confused about whether they want to be a 3 or 4 column layout.

In the first example, the three columns on the left group together nicely. But the column on the right doesn’t feel coherent with the rest of the layout.

My solution? Stick with a uniform 3 column grid. The wider, more regular columns create a better rhythm across the page, and also give you more room to work with. The student who built this page was using the small column on the right for a navigation list. But it would be better to move that elsewhere on the page, and let the content on the left fill the width of the page. Often times using the grid correctly means re-thinking the placement of elements on the page.

The second example is similar, but has even more problems. The three columns on the right stray from the grid in an attempt to fit themselves into a space that is probably too narrow. The contrast with the correctly sized column on the left is awkward.

In this case, a uniform 3 column grid would also work, as would a uniform 4 column grid. Because a 12 column grid system can be equally divided by both 3 and 4, these column sizes are the most reliable choices when working with the 12 column 960 grid. They will create equal divisions of the page that are wide enough to fit most content, and as we’ll see below, they look good when matched with each other on the same page.

Mix and (mis)match

The next two examples suffer from awkward mixing of column groups.

The first example starts with the right approach, using three equally sized columns through the center of the layout. The problem comes with the columns above and below. When mixing columns with different widths, the goal should be a harmony between all elements on the page. Unfortunately, in this example the columns clash with each other.

The solution is to use column groups that have a more harmonious relationship to each other. We achieve this by matching the 3 column group in the center with a 4 column group below it, and letting the header run the full width of the page. As we said above, 3 and 4 column groupings are often the best choice when working with the 960 grid. The intervals are more regular and we reduce the clash of irregular columns.

In our final example, the middle group of columns is again well defined, but the columns at the top and bottom again clash. The one unit of white space at the top of the page is especially troublesome, as it stops the eye and disrupts the flow of the page.

Again, the solution is to use a simpler, more consistent approach to the column groups. We want the columns to sit next to each other comfortably, and the lead the eye down the page naturally.

There are of course other solutions to the problems I’ve highlighted. But the best approach is often to remove any complex grid structure in favor of groupings of 3 or 4 columns.

If you browse through the example sites on the official 960 grid site you’ll notice that many of them are using a simple 3 or 4 column layout. A straightforward approach to the structure of your page doesn’t have to limit your design. Instead, it provides a solid base that will introduce clarity to your layout. And that’s always beautiful.

Go deeper

We encourage developers who are looking to learn more about grid systems and other fundamentals of visual design to sign up for our next Design for Developers workshop, taking place Feb 21 through 23 at our Boston office.

Make CSS3 buttons like a boss

High-quality interface elements are a great way to add that extra bit of refinement to a website. I’ve been maintaining a repo of CSS3 buttons for the past few months and I’m starting to see them slowly make their way out into the real world. This tutorial is going to give you a deeper understanding of the design thinking that goes into making these buttons and show you how to make them from scratch.

For this tutorial, we’re going to be building the button that Peter Vidani recently named 2010 Button of the Year. As you can see, we’re aiming for an almost exact reproduction of the image-based button that appears on the Apple website:

Take a look at the live button

Mind your light sources

When designing buttons and other interface elements, it’s important to be consistent about where the light source on your page is coming from. If you look at the button we’re building, you can see that the light source is coming from directly overhead. This means there is a slight highlight at the top edge of the button, the background color goes from lightest at the top to darkest at the bottom, and there is a slight shadow underneath the button. We’ll make sure to keep the light source consistent as we add the hover and active states later on.

Let’s look at the code for the normal state of the button.

First, we use CSS3 background gradients for Mozilla and WebKit, with a solid color for all other browsers.

button {
  background: #3b88d8;
  background: -moz-linear-gradient(0% 100% 90deg, #377ad0, #52a8e8);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#52a8e8), to(#377ad0));
}

Next, we add the border color. Keeping in mind the light source concerns we mentioned above, the top border is slightly lighter than the bottom edge, with the left and right edges being somewhere in between these two values.

button {
  border-top: 1px solid #4081af;
  border-right: 1px solid #2e69a3;
  border-bottom: 1px solid #20559a;
  border-left: 1px solid #2e69a3;
}

We then add two box shadows: one to create the slight highlight at the top of the button and another for the drop shadow underneath the bottom.

button {
  -moz-box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
  -webkit-box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
}

Finally, the text shadow declaration. Because we want the text to appear slightly inset into the button, we add a slight shadow at the top of the text. If we wanted the text to appear raised, our shadow would have gone at the bottom.

button {
  text-shadow: 0 -1px 1px #3275bc;
}

Next, let’s look at the hover state of the button

For the hover state, we want to imagine that as we move our mouse over the button, we cast a slight shadow on it, causing it to get darker. This means that we need to make the background, border, box shadow and text shadow all a bit darker. We also want to change the cursor style to what you normally see when hovering over a link, to reinforce the clickability of the button.

button:hover {
  background: #2a81d7;
  background: -moz-linear-gradient(0% 100% 90deg, #206bcb, #3e9ee5);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#3e9ee5), to(#206bcb));
  border-top: 1px solid #2a73a6;
  border-right: 1px solid #165899;
  border-bottom: 1px solid #07428f;
  border-left: 1px solid #165899;
  -moz-box-shadow: inset 0 1px 0 0 #62b1e9;
  -webkit-box-shadow: inset 0 1px 0 0 #62b1e9;
  cursor: pointer;
  text-shadow: 0 -1px 1px #1d62ab;
}

Now, the active state

For the active state, we want to imagine that we’re depressing the button into the page. This means that the button will darken and have a shadow cast over it. We achieve this affect by adding a darker, larger inset box shadow to the button, along with making other elements of the button darker.

button:active {
  background: #3282d3;
  border: 1px solid #154c8c;
  border-bottom: 1px solid #0e408e;
  -moz-box-shadow: inset 0 0 6px 3px #1657b5, 0 1px 0 0 #fff;
  -webkit-box-shadow: inset 0 0 6px 3px #1657b5, 0 1px 0 0 #fff;
  text-shadow: 0 -1px 1px #2361a4;
}

Finally, the disabled state

You make a disabled button like this:

<button disabled="disabled">Download iTunes</button>

We add the disabled style to the normal, hover and active states of the button to ensure that it appears fully disabled. We also changed the cursor style to reinforce that no action can be taken. (I tweaked my version a bit to remove the white bottom border found in the original.)

button[disabled],
button[disabled]:hover,
button[disabled]:active {
  background: #999;
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#dadada), to(#f3f3f3));
  border-top: 1px solid #c5c5c5;
  border-right: 1px solid #cecece;
  border-bottom: 1px solid #d9d9d9;
  border-left: 1px solid #cecece;
  color: #8f8f8f;
  box-shadow: none;
  -moz-box-shadow: none;
  -webkit-box-shadow: none;
  cursor: not-allowed;
  text-shadow: 0 -1px 1px #ebebeb;
}

Extra credit

Rounded corners in CSS can sometimes look a bit jagged. In WebKit browsers, you can use this line to improve their appearance:

-webkit-background-clip: padding-box;

You’ll want to add this line after you declare the background, as described in this post.

In Firefox, the button element gets a bit of extra height that you can partially eliminate using this declaration:

button::-moz-focus-inner {
  border: 0;
}

In my experience, buttons in Firefox still end up a bit taller than in WebKit browsers, however.

And now the caveats

This almost exact reproduction of the Photoshop button is possible in Chrome and Safari on the Mac, with Firefox being almost there. Chrome on Win/Linux currently has a bug that affects buttons that use both rounded corners and an inset box-shadow. A fix should be coming soon. As expected, in Internet Explorer these buttons will fall back to a lesser-styled, but still functional look.

Design Driven Development

Most of my thoughts about design spawn from asking myself what makes a project successful. Well, what does? Most will agree that good design does. This is not speaking exclusively about the graphic design or implying that everything rests solely upon the shoulders of the Designer. Everyone is a designer. Design is a fundamental part of everything. Keep this philosophy in mind for the entirety of the project.

How we guide projects

thoughtbot has always been known primarily for its Rails expertise and as such the projects have been driven majorly by the development, headed by a Lead Developer.

Over the last year or so, with the addition of new designers to the team, we were able to focus much more on design. We’ve started with design first, as we should, and this has been quite successful. The general practice was to do our research, form our wireframes, and move onto the visual design. The problem is, once we got past the initial design steps our process would splinter a little. Design would still be important and never forgotten but a detachment formed between the design and the development.

Now, we want to fix this. We need to make sure that whatever we’re working on is the most beneficial thing to the end user. We work off user stories and shouldn’t pick ones to work on because they’re easy or need to get done eventually. The user stories should be prioritized with good design in mind. We must stay vigilant in creating the best possible product for the target audience. A great way to accomplish this is to keep the design of all things at the forefront of our thought processes. Keeping a project driven by design will help this happen.

The improved way

As of late we’re beginning to drive projects with design from start to finish. As I hinted at already, this does not mean a project should revolve around the graphic design or visual aspects. This means the design of everything should be well thought out. From things as simple as structuring the meetings well, to things as complex as building the code properly, to things as crucial as wireframing the flow of the app. Design should be at the forefront of our thoughts in every step of the building process.

Things to help improve

We’ve had great success with a few things lately. None of them are new ideas but sometimes we just forget about them. They are all things that both a designer and/or a developer can accomplish.

For early prototypes, faster and simpler is better than slower and more polished

Recently on one of our projects we wanted to test out a proposed flow for a new app. In a day or two we were able to bust out some very unsexy but very understandable HTML wireframes. They were clickable, buttons did what you expected them too, and you could navigate between pages. The app didn’t have any real functionality but it helped both the client and us easily identify trouble spots and conversely figure out what was working best. This was immensely helpful and saved quite a bit of time in the long run.

User test early, refine, user test again

On another recent project we wanted to get something in front of people as early as possible. Similar to the wireframes in the last section, the app did not work. It was a little more polished but really just a pretty wireframe. The difference between this and the previous method was the people running through the app were not part of the team. Even having a few people unfamiliar with the app click through and share immediate thoughts let us rapidly modify the app and only a week later, test again. Over the course of 5 weeks we did this 3 times. The client is pleased (and enjoyed listening to the feedback) and the app is undoubtedly in better shape than it would have been if we waited longer to user test.

Keeping designers, developers, and clients connected

One of the biggest problems, in my opinion, is having the design and development relationship splinter as the project grows, both roles will just work on what they feel is best without consulting one another.

There are a few things you can do to help avoid this. The biggest aid, in my opinion, is designers, developers, and clients work physically close to each other. Members of teams at thoughtbot all sit together, and we’ve undeniably had our best results when the client was able to work with us in person. We can easily verbally communicate at a moments notice. We’ve found that asking user and goal related questions, discussing as a team, and coming up with the best solutions really helps to keep us on track and work as one unit. Questions like:

• Who are the users?
• What are the primary goals for the users to accomplish?
• What things need to happen in order for the users to perform these actions?

Try it out

To facilitate these ideas, whoever is best fitted and most comfortable to fill a role that focuses on designing for the user experience should be the project lead. This can be a designer or a developer. Everyone is a designer. Everyone helps the design process. So, if you haven’t tried this process yet, give it a shot on your next project. Embrace well thought out design in all aspects of your project, and see if you don’t feel better about the end result.

Recap: Design for Developers

We ran our first Design for Developers workshop this week. Kyle and I had a great time teaching it and were really pleased with the quality of the work the students were able to produce by the end of the workshop.

The main project the students worked on was a page for a fictional furniture company. We gave them a completely unstyled page and asked them to slowly transform it using grid systems, refined typography, and effective color schemes. The students sketched out their ideas on paper, then worked directly in HTML and CSS to implement their ideas. At the end of the last night, we had a group presentation of all the pages, where the students talked through their approach and we offered our critique.

We asked a few students to let us share their work with you.

This page was designed by Javan Makhmali (click for full-size image):

And this page was designed by Chuck Vose (click for full-size image):

At the end of the workshop, students walked away with a solid grasp of some fundamental principles of design along with practice building a well-structured, good looking web page.

If you’re a developer who wants to improve your design skills, consider taking our next Design for Developers workshop, which we’ve scheduled for Feb 21-23.