Design for Developers

Tab Basics

Tue, 19 Jul 2011 12:52:47 -0400

Tabs is a basic building block of any UI, but they can be greatly varied in appearance. The key to creating tabs that are usable and fun to use are:

Layout

The general use case for tabs can be described as allowing users to switch between panes of information. The design of the tabs should therefore be heavily influences by the kind of content your users is going to switch between.

The horizontal layout is my goto layout for tabs. They are a poor choice if you have more than 5ish options to show as they can’t be scanned over as easily as a vertical tab list, but they have the added benefit of doubling as a header/divider for a section if used correctly.

In the example above the tabs form a nice header for the dialog and the user’s eyes is naturally pulled from reading the dialog titlebar to reading the tab labels.

The vertical layout on the other hand is great when you have a ton of content to display. Vertical tabs are very easy further to subdivide into sections which in turn makes them more digestible by the user.

I would avoid a collapsible tree of tabs. They are lazy design and just because you can fit dozens of tabs into a vertical layout doesn’t mean you should. Even with vertical tabs going past 15 options is not advisable. In you do need that many tabs you are doing something wrong and you need to re-examine your information architecture the group things better.

Angled tabs is a variant of the horizontal layout that works really well with guided content. Because they are used to indicate progress through a series of choices, they aren’t normally clickable. Instead buttons are used to navigate through them.

The buttons used in the above example is based on the buttons used in my previous blog post. The only change I made was to angle one side of the buttons to match the forward and backward flow of the tabs. Not strictly necessary (positioning left and right is enough), but adds a nice little touch of flair that will be appreciated by users. You will probably not be able to use pure CSS to obtain this visual look.

Upside down tabs is another variant of the horizontal tabs. I don’t see this very often, but i think if you give pagination the tab treatment they become much more visually interesting and make a lot more sense behaviorally.

In this example I simply stick the current page’s tab out slightly further to make it stand out. For the :hover state you can either copy that style, or do a a half-way step between the two. It is quite satisfying moving your mouse of the row of tabs and having them pop out.

Aesthetic

Designing the aesthetic of tabs is quite a bit different than that of buttons. Whereas buttons have a very real presence in the real world, user interface tabs are slightly abstracted from their real world counterparts making the more tricky to emulate. Their aesthetic also varies greatly with their layout and usage.

The key to making any tab aesthetic work is to make it really simple, and then add a little but of visual flair. The bare minimum would be something similar to what 37signals does: a solid colored box behind the active tab, and something which that box connects to. It looks like a tab and the user will understand how to use it, but it is ugly and unpleasant to look at.

The flair is there to add visual interest. As much as web 2.0 is mocked for the excess gradient usage, gradients are more visually interesting than flat colors. Subtlety is the key. Hard edges and hard colors are, well, hard. Throw a gradient on it and round the edges and suddenly you have a much softer and more pleasant object to look at.

Adding some extra visual flair to the active tab will help make it move obvious which tab is selected. The stronger that distinction is the better. In the example I gave for the pagination the distinction isn’t ideal. It is about as subtle as you can go.

Animations

The thing that makes tabs fun to use is speed. It is often tempting to add some sort of animation to tab switching in the form of a slide-in. If you are designing an interface to be used multiple times by the same user it is safer to just avoid them. After a while animations will start to feel slow and the fun will be sucked out of it. Soon it will start becoming frustrating to use and a detriment to your user’s experience.

The only example where animations might be ok is on marketing sites such as the Coda website. Their primary purpose is to convince viewers to buy the software. It would be rare that anybody would be using such a site multiple times.

Basic buttons using CSS 3

Wed, 06 Jul 2011 07:59:00 -0400

In my last blog post people expressed interest in seeing the image based buttons next to CSS versions. Interestingly enough these doesn’t look nearly as bad as the sample I used for the original post, most likely because these buttons are larger and because I avoided using css borders.

These buttons use CSS 3 properties and will only render on modern browsers. They are going to look pretty terrible in Internet Explorer, Camino, and older versions of Chrome and Firefox.

Image Based

White Button Blue Button

CSS 3

In order to improve rendering quality I stayed away from using CSS borders. Instead I used a container with 1px padding and set a background color to it. This greatly improved the drawing quality of the lines.

White Button Blue Button

The Code

One thing that is immediately obvious is the increase in lines of code to do it through CSS. 210 lines of code compared to only 42 lines when using images. Because the code is so long and messy I have only included the CSS for the white button below.

I have updated the Github repository with these additions.

Want to use this button for your own project? Download the source files from github.

Button Basics

Sun, 03 Jul 2011 21:03:00 -0400

Buttons are one of the core UI elements in any interface. Making them feel responsive and aesthetically pleasing will go a long way to making your app more fun to use.

First up, a sneak peak of the final result:

White Button Blue Button

CSS vs. Images

CSS has come a long way, and now with support for border radius, shadows, and gradients you can create some pretty awesome looking buttons without using a single image. Unfortunately the rendering quality is not nearly as good as that of Photoshop. Edges are pixelated when using border radius, and you do not have nearly the fine graphical control that you can get out of Photoshop. For example, while box shadow supports x/y offsets and a blur radius, it does not support a contour property.

Performance is also not that great. On mobile devices using a ton of gradients and shadows will noticeably reduce the snappiness of the app. You may argue that eliminating the images will reduce http requests, but through image sprites you can combine the button graphics into your main app image sprites and not have any additional http requests.

Designing the Aesthetic

Great usability requires a clear visual hierarchy. To that extent we have two buttons: a white one and a blue one. The blue one stands out more and is intended to be used as the primary action such as Save Changes and Continue. The white one blends into the background and should be used for secondary actions such as Cancel and Back.

A button is made up of four states, though two of them can be combined into one.

The key to making a good button is subtlety. If your users can readily identify the techniques and filters you used to achieve the effect you aren’t subtle enough. To achieve a graphical complexity where the effects blend together and become inseparable we will layer them on top of each other.

Base Button This layer provides the base look of the button. For this example we picked a light source sitting above and to the top of the button. Thus the gradient will start lighter at the top and end darker towards the bottom.

We apply a drop shadow below it to make it pop off the page a little bit and a few other effects to add a bit of visual complexity.

Bottom Border The base gradient makes having a solid color border problematic. Using a solid color the border will either be too dark at the top or too light at the bottom. So we use a gradient mask to blend a darker border onto the button which lifts the bottom of the button even further off the page

Glossy Highlight We apply a glossy shine to the button at the top since that is where the light is sitting. The gloss has to be very subtle. If it is too obvious it can greatly detract from the aesthetic and look too slick.

Label The label has a drop shadow from below to give the impression that the text is etched into the button.

To truly reflect how buttons behave in the real work we need to tweak the aesthetic slightly for each state. For the hovering state the white button gets darker while the blue one gets lighter.

For the active state things get a little bit more involved. We do several things:

Since the button is recessed and getting less light we remove the gloss and replace it with a inner shadow and darken the base gradient slightly.
We change the drop shadow of the button to be a 1 pixel pure white shadow. The white shadow emulates light catching off the edge of the button as it is pressed down below the surface of the page.
To emulate the button going down the label is shifted down by 1 pixel.

You can optionally add an icon to the white button to draw more attention to it, add visual interest, and move it up in the page hierarchy. The most complete and visually stunning icon set out there is the Fugue icon set.

If you do add an icon remember that the icon should match the label behaviour with movement.

The Code

The markup for the buttons is pretty simple:

For browser compatibility we use a span inside the a tag. You could replicate the same behaviour using multiple background images if you wanted, but only IE9+ would be supported.

The CSS uses a standard sliding-door technique to create scalable buttons. You could use border-image as well to make the markup simpler, but again browser support is spotty.

This code will provide a button that scales horizontally. While you could make it scale vertically as well (given a few changes to the aesthetic), I don’t think that is good design. It is best to stick to as few button configurations as possible.

It is important to also style the :focus selector. It is triggered when the user tabs through the page and very useful for keyboard navigation. I used the same graphics for both :focus and :active, but ideally you would create a style that stands out a bit more.

Disabling the user’s ability to select the text of the buttons via user-select: none; will make them feel more solid. If you are building a true webapp you may want to disable text selection across the board and selectively enable it on appropriate elements.

Want to use this button for your own project? Download the source files from github.