Design 101: Stop Yelling

How do you make yourself heard in a loud room? BY YELLING! And when it comes to design, that’s often the approach used for drawing attention to elements. LOUDER! BIGGER! FASTER!

But there’s a better way.

Imagine yourself in that loud room again. Now imagine that instead of yelling to get above the noise, you could just turn down everyone else. Instead of shouting at the person you’re talking to and ending up with a strained voice, you’ll be able to have a nice, thoughtful conversation with them.

While it’s hard to turn down the volume of a room, it’s easy to quiet the background noise in your design and let the important parts speak clearly. Let’s take a closer look at this idea.

Below is an example of a composition where everything is shouting at you. The big red headline at the top is trying to assert itself, but so is everything else, which means, in the end, nothing stands out.

So let’s turn down the volume. You have to decide what you’re trying to communicate and how to say it in a clear and concise way. This will drive your design decisions. In the example below, we’ve established a clear hierarchy between each bit of text. The headline still dominates, but we’ve toned down the other text so that your eye moves comfortably and naturally from headline, to subhead, to body text.

Let’s try another iteration that makes more dramatic use of white space. I tell students in my workshop that white space is the secret ingredient in design. Effective use of white space can transform a mundane design into something that feels elegant and timeless.

In this example, I’ve made the headline and subhead the same size as the body copy. I’m relying on white space to create the hierarchy, isolating the elements within the composition so they can establish their presence without competing with surrounding elements. Think of that loud room again. Not only have we quieted the voices in the room, we’ve moved everyone to their own corner so they can talk without distraction.

When thinking about how to create emphasis, don’t be so quick to turn up the volume. Think about how to use hierarchy and white space to communicate your message without shouting it at your audience. You’ll create something more elegant and respectful that still accomplishes your communication goal.

I’ll be teaching more visual design principles and strategy in my workshop, Design for Developers, which is running Feb 27–28 in our Boston office.

Showing off

Over the last few months we have been looking for another designer to join our team. We’ve seen a bunch of portfolios ranging in experience and style. I’ve found it intriguing to see how other designers present themselves and their work through their portfolio.

When it comes down to it you want your portfolio to show your work in the best light possible. You want to make the person hiring to be looking for more and eager to talk to you. Here are a few things that I am always looking for in portfolios.

Master the basics

I can’t put enough emphasis on design basics in both your portfolio and the work that you decide to put into it. There are in particular two things that I am really looking for: a proper grid and outstanding typography. You should have a solid understanding of both and be able to show it in your portfolio.

A grid is something no design should be without and there is no excuse not to use one for your portfolio. Its benefits are well documented and accepted; it adds form structure and flow. If you think you need help in this area pick up Grid Systems: Principles of Organizing Type by Kimberly Elam.

Choose a solid typeface and set it perfectly. Pay close attention to line-height, letter-spacing and the hierarchy in your type. I feel like every designer should have a copy of Robert Bringhurst’s Elements of Typographic Style, and have read it at least twice.

Best work and only the best

Don’t show anything less than your very best work. If that means that you can only have one portfolio piece then you only have one. Don’t just put in a bunch of work that doesn’t show your full capabilities. The work in your portfolio site should be shown well. It seems obvious but don’t have lots of distractions and useless ornaments around it unless it serves to better show your work.

Client work proves that you’ve done it before. It indicates that you can handle clients, handle project timelines and everything that comes with being a designer on a team.

If you don’t have this kind of work look for projects that you have done that might fill that gap. They can range from a goofy tumblr account, to contributing to open source, to maintaining a blog. They show that you have a passion for this thing you want to do, that you are eager to learn and that you eat, drink and breathe this stuff. Even if you have a bunch of great client work it’s still great to see projects that you have started or contributed to showing your passion for your work.

Play to your strengths

All in all, you want to play to your strengths. If you are right out of school you won’t have much client/in-house experience so play up those projects you take on in your free time. If you have a bunch of solid work select the few you consider the very best and switch out pieces depending on the job you are looking to get.  Make sure that who you are and your core design principles are reflected in the design of your portfolio and the pieces that you have chosen for the portfolio.

Need a review?

I’d like to start giving portfolio reviews if there is an interest in it. It’s something that I wish I had the opportunity to have when I built my first portfolio (it was pretty bad). So if you are in the Boston area, come to the next Design with Boston. Just ask me and we can sit down and go over it sometime during the night.

Font Battle 2011

A recent straw poll of text editor fonts at thoughtbot found these results. Not all thoughtbot precincts have reported in. Perhaps you’d like to explore some new font options for those walls of text you stare at for 8+ hours daily.

Some links to these fonts:

• Mensch
• Bitstream Vera Mono
• Monaco
• Consolas
• Inconsolata

Get your type back in shape with these simple tricks

Type looking a little flabby? Overweight? Want to give it a kick in the pants? Take a look at some of these tricks to really give your web type a workout.

Refine the Windows physique

Looking to make your type render a bit better for your Windows and Linux users? Try text-rendering: optimizeLegibility;. It will enable ligatures and kerning tables in the font file making the type look extra nice. It takes the text a little longer to load which could be a problem. It’s best to use it on headers, especially on those @font-face fonts, and refrain from using it on really large blocks of text.

Shed some Webkit weight

Everyone’s reversed Webkit type has a little extra weight in the hips. -webkit-font-smoothing: antialiased; will help you lose a little of that weight around the middle by using antialias rendering instead of the default subpixel rendering. It will make type just a hairline thiner when using light type on a dark background. Read -webkit-font-smoothing reloaded and check out the test page for more information.

Remove those pesky widows

Have a problem with widows? Use jQWidont to zap those problem spots away. It will remove all those pesky widows for you by inserting a non-breaking space right before the last word.

Get some rhythm in your step

Create rhythm the easy way. Try using tools like typograph and Modular Scale to create a nice flow within your type. Both use traditional type scales to calculate sizes to help with your vertical spacing.

Feel Justified

Using justified type on the web can sometimes be a disaster. Hyphenator and text-justify: newspaper; (Only in IE - WHAT?) will help make sure that you’re shaping up the word-spacing and not letting it get too big. Hyphenator adds in semantic soft hyphens for you but it could be dangerous leaving your hyphenating up to a script. text-justify: newspaper; will adjust the spacing between letters and words instead of relaying solely on word-spacing.

DIY @font-face web service

Phil recently designed Developers Developers Developers Developers, an event we’re running for Boston-area high school and college students:

It looks awesome in part because of liberal use of @font-face.

These days, it’s simple to use @font-face. Just use a stylesheet referencing a web service like Google Font Directory:

<link href='http://fonts.googleapis.com/css?family=Lobster&subset=latin' rel='stylesheet' type='text/css'> 

… then use the font as part of a normal CSS font stack:

#schedule .event-time {
  font-family: 'Lobster', arial, sans-serif;
}

What if the font isn’t on an @font-face web service?

There are plenty of commercial @font-face web services, which Kyle has covered in detail.

However, there are cases where the font you want to use isn’t on an existing service. Or, the font you want to use requires explicit permission from the font’s creator before you can use it.

We ran into this problem on Developers Developers Developers Developers.

First attempt: serve fonts from the app

To solve it, we included the font files in our git repository. This worked, but wasn’t ideal:

• Unnecessarily adds large files to the repo.
• No HTTP caching by default, downloading font files on subsequent requests.
• Repetition. Soon after, I wanted to use League Gothic again on another app.

Second attempt: serve fonts directly from Amazon S3

So our next attempt was to upload the @font-face stylesheet and font files to S3 and serve them directly from there like:

<link href='http://our-bucket.s3.amazonaws.com' type='text/css'>

At first, this seemed to work well. We could set some HTTP headers to handle caching and everything seemed like it was in the right place:

• application code in version control
• assets in an asset host (S3)

However, Firefox (and probably some versions of IE), balks at this technique because of the same origin policy.

On S3, you’re not allowed to tweak the Access-Control-Allow-Origin HTTP header to allow Firefox to serve your font from S3. There’s a long Amazon thread where S3 customers are asking for this ability.

However, even if you could set the Access-Control-Allow-Origin header on S3, you also want the Content-Type, Cache-Control, and Expires to all also be set in a standard way. It’s a pain to have to do that manually.

Solution: serve fonts from a DIY web service

Our final solution was a small Sinatra app called Fist Face. It is now open source under the MIT License and it solves all the problems we experienced.

Fist Face

It works exactly the same way as Google Font Directory, Typekit, or any other @font-face web service, except that you have full control over it:

<link href='http://your-font-face-service.com/league-gothic.css' rel='stylesheet' type='text/css'>

To use Fist Face, this is all you have to write:

# Gemfile
source "http://rubygems.org"
gem "sinatra",  "~> 1.1"
gem "fistface", "~> 1.0"

# config.ru
require 'rubygems'
require 'bundler'
Bundler.require
run FistFace

Then deploy it. Follow a few conventions in the README regarding your asset host (ex: S3) and a few minutes later, you’ll be serving fonts via your own @font-face web service.

Why would I want to do it myself?

If you’ve run into the same issues that we did, have you solved this problem differently?

Among the weaknesses of this approach are:

• No CDN. (patches welcome!)
• Up to you to write a decent cross-browser CSS file.
• The font files you use might be old-school (not “hinted” for computer screens).
• Requires deeper knowledge of typefaces.

With an open mind, the last weakness is actually a strength. Typography is pretty interesting. You’ve got all these independent type foundries doing beautiful work and some release their fonts for free under permissive licensing.

In that way, hunting great typefaces for your @font-face web service is like building your own art collection. It can differentiate your work.

So, when your friends ask you, “whoa, what font is that?”, you can tell them, “you’ve probably never heard of it” … which I’ve heard is hip.