Viget Inspire : The Design Lab

Picking the Perfect Palette

2012-01-23T15:45:00Z

I recently visited a friend who was having some rooms painted. The walls of the living room looked like a patchwork quilt with daubs of various paint colors all over the wall. "I can't make up my mind," my friend said in response to the giant grin on my face.

My friend's dilemma is typical when starting a new project. Whether you're painting a room or designing a website, it can be a challenge to select the perfect color combination. Rather than getting into the process of color selection, I'm going to focus on some resources and techniques that can help make the job a little easier.

kuler

Kuler is an amazing tool by Adobe that allows you to explore, create, and share color palettes. The growing community of designers that have embraced kuler has made it a rich resource for inspiration.

Take some time to dig into the Create section. It takes a little practice to use the interface, but it's worth the effort. There's also an option to upload an image and select five individual points in the photo to generate your palette. Then you can then save, tag, and share your palette with the entire community.

Both Photoshop and Fireworks include kuler as an extension. You can perform many of the same functions in the panel, including searching by keyword. It can be found in both applications under Window > Extensions.

COLOURlovers

This is also a great community site that has expanded beyond just color palettes. It now covers patterns, pattern templates, trends, and shapes, and it has lots of discussions and articles to fuel your creativity. The site says there are over 1.9 million user-created palettes in its database. That ought to keep you busy for a while.

I like searching palettes by keyword because I can quickly narrow down a few that fit my project. Sign up for an account, and there are great tools that allow you to interact with the community by creating and sharing your own color explorations.

Okay, hang with me here. Pinterest is a little trendy, yes. And yes, there's a chance that you'll see a lot that you're not the least bit interested in. But in terms of finding a large variety of inspiration that is precisely related to a keyword or topic, I haven't found anything else that matches it. Trying doing a search for "warm color," and you'll end up with a menagerie of images like crayons, clothing, paintings, rooms, wedding cakes, wallpaper, flowers, and even some pre-defined color palettes. You may leave the site with more inspiration than just colors.

Photoshop + The Mosaic Filter

After pulling some photo inspiration, I might click around using the eye dropper in Photoshop in an attempt to create a winning combination. Sometimes that works, but using the eye dropper tool, even set to 101 by 101 average, can sometimes be difficult. I like to see the colors side-by-side, so there has to be an easier way.

The Mosaic filter in Photoshop is the key. Open your image and adjust the pixel dimensions based on the number of color options you want to see. The larger the pixel dimensions, the greater the number of color swatches you'll get. I like to keep the largest measurement (height or width) between 500-1000 pixels. Any more than that, and you might as well just use the eye dropper tool. Now go to Filter > Pixelate > Mosaic and adjust the cell size. Remember that the larger the blocks are, the less color detail you'll get. (Sometimes this is a good thing.)

Note: I looked for a way to replicate this effect in Fireworks, but the filter options are limited. If anyone knows of a way to do it, please leave a comment.

These are just a few of the many tools and techniques at our disposal. I'd love to hear what works for you.

-webkit-transform: kill-the-flash

2012-01-19T16:24:00Z

This issue has been popping up all over the place lately. When hovering over elements with certain css3 transform properties set on the hover state, Chrome and Safari sporadically flash. Unless you're into causing seizures, this effect is probably not what you're going for.

To prevent the infamous black flash in Chrome and white flash in Safari, you need to set any element you plan on transforming in the future (like on :hover or with an added class) in 3d space from the start.

For Example:

.item {
  -webkit-transform: translateZ(0);
}

.item:hover {
  -webkit-transform: scale(1.5);
}

-webkit-transform: translate3d(0, 0, 0) will accomplish the same thing. The flash seems to occur when the browser switches to gpu accelerated rendering for an element. Thus, by giving the element a gpu accellerated property from the get-go, the browser does not have to switch in and out of rendering modes, and the flash is prevented.

There is a downside.

In Chrome, without this fix, if there is text inside of the element you are transforming, the text nicely re-renders when the transformation is done. With the translateZ(0) fix, the text is rasterized and stretched, causing things to get fuzzy. So say you scale some text up to 1.5 percent — you'll get something like this:

-webkit-transform: scale(1.5) WITH the fix.

-webkit-transform: scale(1.5) WITHOUT the fix.

As you can see in the second image, the text properly re-renders when the transform is complete (in Chrome), where as the second image with the translateZ fix does not. Ultimately, translateZ does seem to be the lesser of 2 evils for now. ~~The good news is, that as of Chrome 17.0.963.26 dev, I'm not seeing the flashing issue at all. Hopefully that means it's been addressed, and that the public release and Safari will soon follow suit.~~

Background-clip, Text-shadow, & Gradients; Oh My!

2011-12-29T13:00:00Z

I’ve had a couple of designs recently where I have been able to play around with background-clip: text in combination with text-shadow and gradients, and I wanted to share my experience.

Before we get too far, background-clip: text is not supported in all browsers. I believe it is still only supported in Webkit browsers, so make sure you have sufficient fallbacks. The demos on this page will also only show up with all the fanciness in webkit, so I’ll wait for you to switch over.

Okay, ready?

First example: background-clip + text-shadow

The image above is an example of the heading I needed to create. It has a gradient over the text and a box shadow behind it. Since these headings were going to be custom controlled by the CMS, we didn't want them to be images. CSS3 to the rescue!

First, we start by adding a CSS3 gradient as the background.

h1 {
  background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(100%, #91a9cb));
  background-image: -webkit-linear-gradient(#ffffff,#91a9cb);
}

Next, we add background-clip and a text fill color. This is also a good opportunity to add a fallback text color for browsers that don’t support background-clip: text.

h1 {
  background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(100%, #91a9cb));
  background-image: -webkit-linear-gradient(#ffffff,#91a9cb);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  color: #fff;
}

We are looking pretty good so far, now we just needed to add a text-shadow.

h1 {
  background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(100%, #91a9cb));
  background-image: -webkit-linear-gradient(#ffffff,#91a9cb);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  color: #fff;
  text-shadow: 6px 6px 9px rgba(0, 0, 0, 0.33);
}

Doesn’t look exactly as we wanted. It might be hard to tell, but since we set the text to have a transparent fill-color, the text-shadow bleeds through. I then decided that this would be a good opportunity to use a data attribute & generated content to duplicate the text and position it behind the gradiated text.

<h1 data-text="Oh heeey!">Oh heeey!</h1>

h1 {
  background-image: -webkit-gradient(linear, 50% 0%, 50% 100%, color-stop(0%, #ffffff), color-stop(100%, #91a9cb));
  background-image: -webkit-linear-gradient(#ffffff,#91a9cb);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  color: #fff;
  position: relative;
}
h1:after {
  background: none;
  content: attr(data-text);
  left: 0;
  position: absolute;
  text-shadow: 6px 6px 9px rgba(0, 0, 0, 0.33);
  top: 0;
  z-index: -1;
}

That looks pretty great and has fallback for other browsers. Success!

Second example: background-clip + generated content

In this example, we flip what we did in the first and use background-clip on the generated content. This image above shows what we need the end result to look like.

First, we just style how we want the heading to look.

h1 {
  color: #fff;
  font: 52px/52px Georgia, Times, serif;
  text-transform: uppercase;
}

Next, let’s use generated content and add a background image.

<h1 data-text="Hey buddy!">Hey buddy</h1>

h1 {
  color: #fff;
  font: 52px/52px Georgia, Times, serif;
  position: relative;
  text-transform: uppercase;
}
h1:after {
  background: url(images/structure/bg-heading-diag.png);
  content: attr(data-text);
  color: transparent;
  left: 4px;
  position: absolute;
  top: 4px;
  z-index: -1;
}

Then, let’s add background-clip to that bro.

h1 {
  color: #fff;
  font: 52px/52px Georgia, Times, serif;
  position: relative;
  text-transform: uppercase;
}
h1:after {
  background: url(images/structure/bg-heading-diag.png);
  -webkit-background-clip: text;
  content: attr(data-text);
  color: transparent;
  left: 4px;
  position: absolute;
  top: 4px;
  z-index: -1;
}

Finally, since background-clip: text doesn’t work in non-webkit browsers, we will need to add some sort of check to test if it’s webkit or not. When I previously checked, there was no way of testing if a certain value was supported for a property, so I just rolled with the jQuery browser object.

if($.browser.webkit) {
  $('html').addClass('webkit');
}

Then, we just need to modify the styling of our generated content a bit to have a solid color for non-webkit browsers.

h1 {
  color: #fff;
  font: 52px/52px Georgia, Times, serif;
  position: relative;
  text-transform: uppercase;
}
h1:after {
  color: #948972;
  content: attr(data-text);
  left: 2px;
  position: absolute;
  top: 2px;
  z-index: -1;
}
.webkit h1:after {
  background: url(images/structure/bg-heading-diag.png);
  -webkit-background-clip: text;
  color: transparent;
  left: 4px;
  top: 4px;
}

And that’s it! Just a few tricks I’ve come across while playing with this stuff on some projects. Let me know if you all have any other tricks with background-clip.

Some Lesser Known Features of LESS

2011-12-08T13:09:00Z

For the last year or so, LESS has gained a lot of traction in the front-end development community, particularly among designers. LESS extends CSS with dynamic functionality and organizational features, which provide a lot of power and efficiency to designers and developers. However, it's not the only CSS pre-processor player out there. The other major one is Sass, which is very similar, and both are solid options to consider.

Many of the review articles out there do a good job of providing an in-depth look at syntax and general usage, but I'd like to take a different angle—highlight one difference that isn't written about all that much, and present a few features of LESS that have have proved very valuable on recent projects.

No Barriers

One difference that isn't discussed much is that the barrier of entry is very low for LESS. Sass requires Ruby, and the Sass gem must be installed to get up and running. While not a huge list of requirements (especially for Mac users, since Ruby is already installed), this can potentially put off those who are not comfortable with the command line. With LESS, there are no dependencies, and there is nothing to install. To get LESS up and running, just download less.js from lesscss.org, and add two lines of code to your markup:

<link rel="stylesheet/less" type="text/css" href="styles.less">
<script src="less.js" type="text/javascript"></script>

* Note the rel attribute of the link tag.

BOOM! You're all set. Write regular CSS in your .less file(s), start using variables and mixins, and you are good to go. Once your site is ready for deployment, compile to CSS¹, and replace the above lines with a reference to the compiled CSS file.

Live Browser Updates

LESS has a built-in “watch” feature that auto-reloads the CSS in the browser without reloading the entire browser window². There's no need to install any third-party directory watcher apps for this to work. To enable this while developing, add the following lines to your markup:

<script type="text/javascript" charset="utf-8">
  less.env = "development";
  less.watch();
</script>

Implicit Mixins FTW

In other words, any class defined in your .less files can be used as a mixin. Combine this with LESS's already super-simple mixin syntax, and you've got a winner! Using HTML5 Boilerplate's .ir class as an example, you can reference the .ir class as if it were a mixin, instead of adding the classes to your markup.

.ir { display: block; border: 0; text-indent: -999em; overflow: hidden; background-color: transparent; background-repeat: no-repeat; text-align: left; direction: ltr; }
.heading {
  .ir;
  background-image: url(image.png);
  height: 50px;
  width: 150px;
}

Note: While implicit mixins are super simple to use, if you decide to use them, do so with caution! This can lead to property/value duplication and code bloat.

Namespaces

Namespaces allow for bundling groups of mixins together for organizational purposes. The example on the LESS site isn't a great one, so here's an example for CSS3 gradients.

#gradient {
  .horizontal (@startColor: #555, @endColor: #333) {
    background-color: @endColor;
    background-repeat: repeat-x;
    /* browser prefixed gradients here */
    background-image: linear-gradient(left, @startColor, @endColor);
  }
  .vertical (@startColor: #555, @endColor: #333) {
    background-color: @endColor;
    background-repeat: repeat-x;
    /* browser prefixed gradients here */
    background-image: linear-gradient(@startColor, @endColor);
  }
  .directional (@startColor: #555, @endColor: #333, @deg: 45deg) {
    background-color: @endColor;
    background-repeat: repeat-x;
    /* browser prefixed gradients here */
    background-image: linear-gradient(@deg, @startColor, @endColor);
  }
}
.box1 {
  #gradient > .horiontal;
}
.box2 {
  #gradient > .vertical(#ccc,#aaa);
}

Continuing From Here

So, how have you used LESS recently? Which features or techniques have been valuable to you? If you want to check out some other resources, be sure to look at Preboot, Twitter Bootstrap, and Less.app.

¹ The easiest way to compile to CSS is via the command line or with Less.app. You can also compile with node.js.

² This only works when browsing files on the local filesystem, and in a browser other than Chrome (because of a known issue in Chrome with loading local JavaScript files).

Design Share: Dinner Party Edition

2011-11-17T15:30:00Z

For the past two years we’ve hosted an event series we call Design Share at our Falls Church location. It’s proven to do everything and more that we set out to do. Namely:

Connect with the local design community.
Learn from each other by sharing behind-the-scenes looks at design and process.
Provide a forum for people who are new to speaking to get experience in front of a low pressure audience.

Over the two year period we hosted 4 events in which 17 talented designers graciously shared their stories. Among them:

Brian Talbot, National Geographic
Jay Moore, AOL
Eric Lohman, AKQA
Rob Soulé, Viget
Ari Kushimoto, CaviarFrenchFries
Jason Garber, Ficly
Elliott Muñoz, Edge Media
Corey Greeneltch, Ironworks
Ali Felski, Sunlight Foundation
Dawn Sword, Serendipity Creative
Owen Shifflett, Viget
Stefan Poulos, Pappas Group
Phil Gossier, Threespot
Lee Costic, Lee Costic Design & Creative
Gregg Glaviano, Grafik
Katie O’Brien, Fleishman Hillard
Sarah Sampsel, Washington Post

The format was simple. Share a short 5 to 15 minute presentation about a project and discuss further with a live audience. We archived many of these presentations at designshare.org.

Along the way, we learned a great deal about the DC design community. More than anything we learned that we all have our struggles and that good design takes great effort and a little perseverance. We also learned that the format isn’t anything substantially new; our favorite local design organizations (Refresh, AIGA, and ADCMW) are already hosting similar events and doing them better. This is one of the main reasons that we’re now thinking of something different.

At this time, we’re considering taking the idea to a new level. One that:

Allows us to take a deeper look into the design universe.
Allows for more meaningful connections to the local design community.
Is unplugged. No videos. No fancy presentations. Straight talk about design creativity and craft. The good, the bad, AND the ugly sides of our craft.
Adds a little more fun with a gaming element.

The idea: a dinner party.

In the near future, we’ll invite select area design studios over to our place (or your place if you prefer).
We’ll play games and share behind-the-scenes looks at recent launches.
We’ll ask questions and learn from each other’s failures and successes.
We’ll make connections in new, meaningful ways.
We’ll complement, not compete against, local organizations like Refresh, AIGA, and ADCMW.
We’ll tour the studio to show you our working environment and learn more about yours.

Much like the tradition of American Thanksgiving, where people get together to celebrate harvest (or the slaughter of turkeys), we hope for the same kind of fellowship, nourishment, and illumination.

We’re already planning for our first dinner party in January of 2012 which will give us more insight into whether or not this is an idea that has legs. If it does, we’d love to see this kind of idea sprout throughout the design community. We’re not looking for this to be an exclusively Viget idea. Heck, we’d love an invitation to share our work at your place if you’ll have us. At the very least, we hope you'll be inspired to invite someone to dinner at your place to chat about design.

Be certain to tell us of your interest in connecting with Viget. We have offices in Falls Church, VA, Durham, NC, and now Boulder, CO. Contact

tom.osborne [at] viget.com (VA),

peyton.crump [at] viget.com (NC),

or andy.montgomery [at] viget.com (CO)

to discuss more. Spread the word.

Question Your Best Practices

2011-10-25T14:00:00Z

Starting at Viget a little over a month ago inspired me to take stock of the best practices that I’d developed over the years. From whole workflows to the smallest code snippet, I decided it was time to upend everything that I thought was perfect and bomb–proof to see what still made sense. The result was that I uncovered a few IE6 cockroaches hiding in the corners as well as a few other things that I had lazily relied on, without question, for years.

What did I find?

I discovered one surprising, and embarrassing, theme: forward–compatibility can make us, as front–end developers, complacent.

Tried and true techniques that worked in IE6 will, not surprisingly, still work in IE9 (and every other modern browser) — and that’s not necessarily a good thing. As browser development marches on and we stop supporting older versions we also need to re–evaluate the techniques we had been using to support those browsers.

Dropping support shouldn’t just mean not firing it up in a virtual machine to see how things look and work. It gives us the opportunity to clear out the cruft and move forward.

For Example

Look at the good old Suckerfish dropdown menu technique. I’ve been thoughtlessly, but successfully, using JavaScript to aid dropdown navigation and other hover interactions for years. Why? Because IE6 didn’t recognize the :hover pseudo class on elements other than links and JavaScript intervention was necessary. When you take IE6 out of the equation (and we all should) things get much simpler and you can use pure CSS.

So why was I still using this antiquated technique? Because browsers happily run whatever error–free code we give them — even when it could be better, or more modern. Quite simply: it worked. It has always worked and always will work and no browser is ever going to complain about it. Talk about a smooth–running bomber technique — and a perfect example of something that had to go.

We’ve all done it

By now you’re thinking “duh, Jeremy, I haven’t used JavaScript in my dropdowns for years”. Good for you! But I bet you’ve got something else hiding in the attic. Care to share one?

Moving Forward

So where’s the impetus to change when there’s virtually no friction? Refactoring code and removing unnecessary parts makes it simpler, smaller, more easily maintainable and less error prone. I think we can all agree that those are good things.

But there’s something more — it’s about being actively engaged in our craft. The speed of progress can cause us to hide behind best practices like a shelter from the storm of blog posts touting the newest thing. The key is finding a balance between stability and progression — or maybe you just need to upend everything once in a while.

Think about your favorite code snippet. If you had to rebuild it today, wouldn’t it be better? What’s your technique for keeping things current while still maintaining standards that speed up your day–to–day work?

CSS Strategy Square-off

2011-10-14T12:50:00Z

It’s an exciting time for CSS. On top of the advances being made both in what to write (CSS3) and what to write with (SASS+Compass, Less), CSS is enjoying a spate of serious discussion over how it should be written.

This might come as a suprise to some (and did to me). After all, CSS seems pretty straightforward — without many of the complexities of programming, CSS has long been seen as something you just write. After all, it’s not particularly hard to write good CSS and markup; so long as your definition of “good” means “looks right, seems consistent, has semantic value”, you’ve generally gotten a pass.

The question recently posed is: is this definition of good, originating from the dark ages of table layouts, good enough to deal with the problems CSS encounters in 2011?

The answer might depend on a few things: first, whether you observe such problems, and second, whether you see them as sufficiently difficult to work with. As I see them:

What Goes Wrong With CSS

CSS grows with site size. Depending on your site, this can be a serious issue — not just for performance, but because CSS is code. More code tends to lead to more problems — maintaining code size is a serious concern.
CSS best practices encourage what would otherwise be bad programming: repetition, bad grouping, loose coupling. Again, if you treat CSS as code that needs to be maintained, reviewed, and refactored, these are negatives.
CSS is often contextually unreadable. For example, .about .main ul li li a might be very clever CSS, using a nesting in the markup to trigger a style, but it’s very bad code — without a strong understanding of the HTML, this code can be ambiguous, and its HTML target hard to pinpoint.
CSS encourages overrides, which are the death toll for maintainability. The more styles you override, the more styles you will eventually have to override again.
CSS encourages bad coupling and distant dependencies — for example, let’s say all LIs inherit a margin-bottom we set early in the CSS, and the features we code design with this spacing in mind. Despite the fact that the art director says a particular feature MUST look the way the comp looks, said feature now depends on a very remote line of code, a line that anyone might change without realizing the consequences.

If your response to #4 was “well, don’t let them change it”, it's a valid one and probably puts you into the “current CSS thought is alright as-is” camp. And that‘s okay! IMHO, your mileage with these complaints is a factor of your experience with large sites and with others’ CSS, but most importantly, with your tolerance for workflow friction.

Personally, my friction tolerance is pretty low — untangling overrides, for example, is something I tend to avoid at all cost, even when that cost involves burning more time finding a stricter naming solution. So, the approaches of SMACSS and OOCSS have a certain appeal to me. They both propose to add a little work (and sometimes a lot of classes) onto the front of the buildout process, but supposedly pay off with cleaner, shorter, more explicit CSS.

Big props to Sullivan and Snook for tackling this issue and facing a new age of CSS challenges with their work. You should definitely consider both proposals for yourself (SMACSS, OOCSS), but to sum up my thoughts on the value of each (alongside the traditional CSS/markup methods), here’s a big ol’ comparison table.

CSS Systems, Compared

	Classical	SMACSS	OOCSS
Markup:	Superclean. Classes are only added when completely necessary for styling.	Many elements with classes. (Elements inside distinct modules, however, can remain classless.)	Start classing, and don't stop until you run out of classes. Some elements will have 4, 5, 8 classes.
Markup semantics:	Straightforward. Write the markup you want, style it the way you want. In my experience, classical HTML/CSS will encourage you to reuse particular elements to achieve particular styles — for example, setting an H3 as a page header because of inconsistencies found in a later comp.	Flexible. By relying on classes, not elements, SMACCS allows you to use the appropriate markup for the job without worrying about existng styles.	Very flexible. You won't be styling any elements in OOCSS, and you might find that it allows you to pick much more appropriate tags in some cases.
Class semantics:	Great. Classic CSS books have example like “.entry”, and its friends “.entry p”, “.entry .byline”, etc. The markup reads well, and the classes are highly descriptive of their content.	Starts to wobble. Now that you're classing for two — meaning and style — you’ll be forced to make a few concessions. There will be some new classes that don't really reflect content, but provide valuable hooks for your CSS.	Pretty rough. In OOCSS projects I commonly find myself writing <li class='highlighted-news-listitem news-listitem listitem'>, when in a perfect world, I would just write “<ul class='news'><li class='highlighted'>...
HTML size:	Teeny. The teeniest!	Classing more explicitly will increase your pagesize.	Classing VERY explicitly, and using multiple classes to apply styles, can add a good chunk to your HTML. A recent project of mine had a 20% increase in HTML filesize.
CSS size:	Big and getting bigger. Once you pass a certain project size threshhold, CSS begins to increase 1-to-1 with new layouts.	Small.	Also small. Writing explicit selectors allows you to whip out new designs in no time using a rich palette of existing classes. It’s actually really surprising the first time it works, and really cool.
Stuff that makes a programmer grimace:	Gross overrides, low readability, bad coupling, repetition, writing more code to fix problems that result from too much code.	Not too much. Some less-than-readable classnames.	All those damned classes! Having 5+ classes on an element is a guarantee that a few will get botched in integration.
Stuff that makes an FED grimace:	Overrides. Using longer selectors to cancel out previous styles is, and has always been, unpleasant business.	Child selectors = IE6 problems. I know that I just need to get over IE6, but it burned me so bad — I’m nervous about adopting a system that fails so hard in IE6.	<h1 class="h2"> Nicole's abandonment of fully descriptive classnames is backed by good reasons, but it's a hard pill to swallow. I end up compromising with classes like "subtle-header" and "pronounced-tight-header", which are slighly less vague but also, somehow, more ridiculous.
Misc. performance:	Longer selectors are generally slower in CSS, but not to a degree that users would notice.	Has lots of classes and the occasional ID, which make for great JavaScript hooks.	Selecting by class is pretty efficient. No IDs can mean no good, fast place to start a DOM query. (Of course, you can just add IDs for JS purposes if needed)

This is just a list of quick impressions, but I wanted to get it out there and get some thoughts from other CSS devs. In my reviews, OOCSS provides a more explicit pattern, while the SMACSS proposal has a deeper, yet more interpretive style. OOCSS is suited for seriously huge sites, while SMACSS provides a middle ground suitable for mid-sized projects. Both are excellent and worth your time to read.

Does CSS need fixing? Do SMACSS or OOCSS do it for you? Do you have more ideas for the table, or do you think I mis-represented anything? Are you Jonathan Snook or Nicole Sullivan, and if so, will you sign my yearbook? Let me know in the comments!

Misinterpreting Minimalism

2011-10-12T13:02:00Z

As of late, I've noticed there are quite a few websites popping up that are designed in a minimalist aesthetic. I believe designing in this style requires more attention to typography and grid systems to be effective. Unfortunately, this is not the case with many examples I've seen. I find there are too many concepts, ideas and products in this world that would benefit from a stronger visual aesthetic. With poorly executed minimalism, designers lose the chance of communicating a visual message. My concern is similar to a post of Owen's a little while back and how some people are overly inspired by visual trends, which leads to the demise of content and creativity.

I will admit that I am on a journey towards living my life in a minimalistic manner, which leads me to believe that there is a lot of commonalities between minimalism in art, lifestyle, and design.

A generalized definition of minimalism could be when something, an object or idea, is stripped down to its essential elements. In minimalistic art in the 1960s, furniture and objects were stripped down to the elements that made them structurally sound. These were parts which defined the furniture and was translated into different objects and structure oriented art. Living minimalistically is similar in the ideas of focusing on the elements that are what define us and re-evaluating what is important. Our job as designers is the same. Our job is to craft, refine, and communicate the message of our clients through design, regardless if it is in a minimalist or maximalist style. There should be no erroneous design elements that take away from the focus of your project or message.

Some strong examples of minimal designs utilizing strong typography and grid systems:

Content reigns with any website, and minimalism is an effective way of highlighting it. The caveat with minimalism is to remember that there are less design elements for a reason. We should treat grids or typography with extra care and not simply craft a design for the sake of making it look "clean" or "modern."

Designers: Are You Asking Questions About UX?

2011-10-07T15:55:00Z

A few weeks ago I posted a tweet to designers saying, "If you're not asking questions about the UX that gets handed to you, you're not doing your job." Responses varied from general agreement to my favorite sarcastic remark, "If you're not asking questions about the UX handed 2 u, you're not doing your job MY BEST FRIEND" (by UXer @malhinha)," and "If you get handed UX at all, you're luckier than most designers" (by @simonmeek).

The Case for UX

If you don't have wireframes and other UX deliverables to work with, I empathize with you, because I've been in your shoes. It's not fun! It's time-consuming and limits your ability to do your best work. Many designers are often left wearing the UX hat because UX is the new design...anybody can do it, right? I was guilty of thinking this until I started working with great UXers who are incredibly skilled at their craft. We don't treat our UX team as a luxury, but rather as a necessity. The value that they provide to project teams and clients can be measured in time, money, conversion rates, innovation ... The list goes on.

The wireframes that our UX team provides are always well-thought-out and robust. They focus on page layout, content examples and strategy, hierarchy, and even iconography in some cases. Though some designers feel that this level of detail limits their ability to be creative, I would argue that it helps designers understand the message and goals of the site — which is essential to creating an effective design. If you simply take a wireframe at face value, then you're not thinking critically, and it places a lot of pressure on the UXer to get everything right. Establish with the UXer how much flexibility, if any, you have to make changes in the design. Sometimes requirements from the client will limit the creativity of the UXer, and this in turn leaves the designer with the job of adding a skin to a wireframe. Many other times there is greater flexibility, and that is where asking questions comes in.

Original Wireframe

Final Result

Questions? What Questions?

Although you may not be a UXer by trade, you are a person who uses the web. This qualifies you to ask questions. If you're a web designer, you have an additional responsibility to ask more probing questions. Our UX team welcomes questions and even urges designers to propose different solutions, since we all have different ways of approaching and solving problems. Challenging the intent and purpose of the UX is equally, if not more, important than asking about layout, scale, and function.

We do our best to have impromptu UX/design collaboration sessions prior to the wireframe hand-off. This helps us address our biggest questions throughout the process and avoid big surprises later, since the final set of wireframes can be rather large and detailed. Try to look at the UX through the lens of the user, the client, and a designer. Evaluate how decisions that are made in the UX align with the message that needs to be communicated in the design. Ask questions like:

Is the appropriate information emphasized? De-emphasized?
Should anything be removed? Added?
Do I understand how the interaction works?
Is anything unclear?
Do I understand the purpose and intent of the UX?
Are there potential complications for the design?

The symbiotic relationship between UX and design is essential to effective problem solving. The line of trust needs to run in both directions for this level of collaboration to work. Turn your brain on, turn your ego off, and start asking some smart questions that will help make your next project great.

7 Simple Photoshop Typography Tips You’re Already Doing, Right?

2011-10-06T13:34:00Z

Just because you can do something in Photoshop doesn't mean you should do it, especially if you're designing web sites in Photoshop. This is most definitely true of how you handle typography in Photoshop. It's always frustrating to painstakingly craft your type, just to find out it's impossible or impractical to use it the way you envisioned in the finished product. Here's a list of little things you can do to ensure that the design you create in Photoshop will and can be perfectly translated into a built-out site. They're mostly common sense, but I know I've been guilty of just about all of them at some point, so hopefully this is a helpful refresher.

Set the anti-aliasing method to "strong". Sure, "smooth" is beautiful and delicate, but that's rarely how it's going to look when it moves into the browser. The most accurate setting is almost always going to be "strong", so if you want an accurate idea of how heavy a typeface will look, stick to strong.

Use whole numbers for font size and leading. It's easy to scale some type up or down, and then forget that the fonts are now set to 26.78px and the leading is 28.4px. But once it gets to build-out time that perfectly sized type is going to have to be tweaked. Make sure you're using whole numbers to avoid your type being rounded up or down in the buildout.

Do NOT adjust the kerning down to the letter. If the text is part of a graphic or will be used as an image, of course, go crazy. Make it perfect. But body text, copy that could be changed, anything that a client has control over, just let it go. You can set the kerning for an overall area of text with letter-spacing in CSS, but you can't get down-to-the-letter control.

Yes, there is lettering.js so you can do some specific kerning of things like headlines. But again, if the copy could be changed down the line, don't worry about it.

Be consistent with your spacing and sizing across the site. If your body text is 12px with 14px leading on one page, it should probably be 12px with 14px leading on the other pages too. Likewise, if a headline has 30px of whitespace underneath it, don't make that whitespace 50px on one page. Consistency in the design means no unpleasant surprises in the buildout.

Be cautious of how many web fonts are used. I know, you're excited about web fonts. I am too, you guys! But every weight of a font that is used generally means downloading that entire weight. If you are only using Proxima Nova Bold as a caption on one page of a site, users still have to download 50k of Proxima Nova Bold. Make sure you're being mindful of how many different webfonts you use, and that you're getting the most out of the ones you DO use.

Use the proper bold and italic versions of fonts, don't just hit "faux italic" or "faux bold" in the character toolbox. The former uses the typeface properly and gives you an accurate idea of how the type will look on a site; the latter bastardizes the type and my Typography 1 professor will come down on you with the fury of a thousand ampersands if you do it. Just sayin', you're gonna get an automatic letter grade deducted from your site; your GPA's gonna suffer.

Plan for more or less than an ideal amount of content. In the design phase, it's easy to design around a headline or a small paragraph and make the area just so, especially if you aren't working with real, working content. But that area needs to have some flexibility to it because when the real content does get it put in, it's invariably drastically different from what you were expecting. Make sure that the design won't break just because a blog title is two lines long.

Of course there are exceptions to each and every one of these rules; none of these are absolutely true 100% of the time. Just think of them as general guidelines. What about you? Have any little Photoshop tips that make a big difference?

Mood Boards: Dressing For Different Occasions

2011-10-04T15:00:00Z

For designers at Viget, Mood Boards are consistently among our favorite topics to discuss and deliverables to create. I wanted to shed a little more light on the subject to talk about some variations of the practice and how we look at them at Viget. Essentially, mood boards aren't a one-size-fits-all kind of thing and we have different approaches to them. Ultimately, we always have the same goal in mind – to start broad in efforts to get early feedback that will allow us to narrow our focus as we begin to work on the details of a design. I originally approached this subject back in 2008 looking at two variations of mood boards. Since then, our two variations have morphed into three. Here are some examples that illustrate what we mean.

Inspiration Boards

These are effectively collages of found inspiration. They don't take long and require little or no original design. We typically have one designer spend an hour or two on them. Usually only one direction is needed, though additional ones may be helpful. They are meant to establish "here's what we like", "here are some different approaches", and "here's generally the direction we'd like to go in". Inspiration boards are well-suited for small projects that move quickly. They are super easy to create, but risk having too much influence from existing sources. We often use these on our internal or pro-bono projects.

Examples of Inspiration Boards:

Summary:

Purpose: Showing found inspiration as a base to get started
Duration: 1 designer, 1 to 2 hours each
Good for: internal, pro-bono, or otherwise small projects

Style Boards

Often times you need to show original design but don't necessarily need to illustrate any deep conceptual thinking. This is where Style Boards come in. Samantha Warren wrote about these recently and dubbed them "Style Tiles" which is a nicer, catchier name. Samantha goes on in her article to equate Style Tiles to carpet samples which is a pretty good analogy, in my opinion. Essentially, Style Boards begin to play with stylistic elements like color palettes, typography, and interface elements but only explore concept and mood on a basic, surface level. They can include elements of Inspiration Boards as a means to get started and/or illustrate existing examples. We typically have one or two designers spend around 2 to 4 hours on each Style Board. We like to use these on our app designs and for clients who already have some sort of brand identity guidelines from which to work from. In our opinion, these are not as valuable when you are looking to help define a brand, brand identity, or deeper concept.

Examples of Style Boards:

Summary:

Purpose: Establishing color palettes, introducing typography, light styling of elements to illustrate a direction
Duration: 1 or 2 designers, 2 to 4 hours each
Good for: app designs or clients who already have brand identity guidelines

Concept Boards

These are the favorite of designers at Viget. Probably because they are the most fun to create. Sometimes you need to illustrate a story or concept and you need to show more than element styling to do so. Concept boards start with brainstorming concepts and ideas as a team and end with individual designers each taking one concept to explore. After anywhere from 4 to 8 hours, a designer will emerge with a rich, immersive design that's reflective of the idea they were tasked with illustrating. They also include styling like the Style Boards and inspiration like the Inspiration Boards. Essentially, this is where it all comes together. These are well-suited for small to large projects where exploring brand personality is essential to the assignment. The biggest downside to these that we've found is that clients can sometimes confuse these with compositional designs if they are not designed and explained properly. We try to show examples of existing work prior to beginning and re-state the purpose before presenting them to combat any confusion.

Examples of Concept Boards:

Summary:

Purpose: For rich, immersive designs that need storytelling and brand personality
Duration: 2 or 3 designers, 4 to 6 hours (light) / 6 to 8 hours (heavy) each
Good for: start-ups, micro-sites and brand revitalization

A final note is that we refer to all three of these variations as Mood Boards when discussing internally and with clients. It's usually only when we're trying to decide the best approach when we break down the labels to Inspiration, Style, or Concept. It's just what has worked best for us so far. Also, we've found that Mood Boards aren't always necessary. For instance, if a client insists on having multiple, fully fleshed-out designs, Mood Boards become far less valuable. We prefer to offer choices at the Mood Board level over Comp level because it helps prevent the "Frakensteining" of pieces and parts of all the designs. We refer to this as as "Frankencomping". So that's it. Go forth, have fun, and remember to dress for the occasion.

Additional Resources

Notes From Our Default ExpressionEngine Build

2011-09-28T19:28:01Z

This post is intended to build off of Doug’s Post: ExpressionEngine on Multiple Machines. So if you haven’t read that, I’ll wait for you.

All caught up? Ok, let’s go.

I’ve been lucky enough to build 3 EE sites in the past few months, so it’s given me time to look at our setup, make changes, and even to build some add-ons. I was hoping to share more about our default build, and maybe there are a few tips and tricks you might find useful.

Changes

Not that much has changed for us in our default build and process since Doug’s post, but here are the things that have:

Templates & Assets

Instead of keeping assets in the themes folder and templates in the EE system folder, we now have an assets folder at the root of the site. Here is what that folder looks like:

/assets
  - /build
  - /images
    - /structure
  - /scripts
  - /stylesheets
  - /templates

The build folder is for your raw markup before you move everything into EE. We have found out that it is super super useful to be able to go back and reference these files.

Moving the templates folder outside of the system folder makes updating EE easier, one less thing to worry about. Now if we can just get the ability to move the third_party folder…

We also have some basic listing and show templates in the template folder which makes it easy to get up and running.

Since I’ve been using Sass and Compass lately (have a look at Doug’s post about Sass and Compass), I have been adding a compile folder into assets too. So my assets folder has been looking like this:

/assets
  - /build
  - /compile
    - /pngquant
    - /sass
  - /images
    - /structure
  - /scripts
  - /stylesheets
  - /templates

Add-ons

The following are the third party add-ons that we have in our default build:

Freeform
This one is a no-brainer. Virtually every site we build has some sort of form on it.

Structure
Although we don’t use it on every site (I haven’t needed it in the three I’ve built), there is no doubt that Structure is brilliant and makes adding pages much simpler for clients.

Wygwam
In our opinion, the best WYSIWYG add-on.

Rest
Not used on every site, but anytime we need to interact with an API, Rest makes it much easier. Though it’s somewhat poorly documented, it’s still our preferred method for making REST requests.

Fix-ee
A little something something I just cooked up the other night. Ever notice that when you are adding a new text custom field, you ALWAYS set the formatting to None? This automatically selects None when you are creating a custom field in the hope that it will save you a few clicks. It also turns off the “Automatically turn URLs and email addresses into links?” setting when editing Channel Preferences.

Health Check
Gives a nice snapshot of the installation as well as any potential issues.

NSM Morphine Theme
We have slightly modified the free version of this add-on to make a few CP adjustments.

Template Variables
Makes it easy to access all custom fields, snippets, and global variables.

Direct to Structure
When we are using Structure, we like to bypass the useless “Preview"”page and go right to the Structure view.

Freebie
If we are using Structure, Doug’s add-on gives some flexibility back to your URLs.

Matrix
It’s hard to imagine building a site without Matrix.

Cache Buster
Since we took our CSS and JS out of EE templates, sometimes it’s helpful to cache bust those assets.

CE Image
Since Image Sizer (our previous image resizing add-on) fell off the face of the planet, we have been more than than happy with CE Image and all of it’s additional functionality. I LOVE being able to add configuration into the config.php instead of in the DB.

// CE Image
$config['ce_image_cache_dir'] = '/cache/images/made/';
$config['ce_image_remote_dir'] = '/cache/images/remote/';
$config['ce_image_memory_limit'] = 64;
$config['ce_image_remote_cache_time'] = 1440;
$config['ce_image_quality'] = 100;

EE Hive Hacksaw
Our preferred add-on for stripping tags and truncating text.

Switchee
Switchee supercharges your conditionals and improves performance. I have been using the nestable beta version.

Here are a few others that we have used more than once:

Stash
I have used the template partials approach on 2 of the 3 EE sites, and I have been very very happy with the way it works. This has allowed my templates to be so nice and clean, example of a news/index:

{exp:stash:set_value name="body_controller" value="news"}
{exp:switchee variable="{segment_2}" parse="inward"}
  {!-- Index and pagination request --}
  {case value="#^P(\d+)$#|''"}
    {if {exp:is_ajax} == "true"}
      {embed="news/_entries"}
    {if:else}
      {embed="_layout/base"}
      {exp:stash:set_value name="title" value="News"}
      {exp:stash:set_value name="body_action" value="index"}
      {exp:stash:set name="content"}
        {embed="news/_listing"}
      {/exp:stash:set}
    {/if}
  {/case}
  {!-- Single --}
  {case default="Yes"}
    {embed="news/_single"}
  {/case}
    
{/exp:switchee}

Hon-ee Pot Captcha
I hate captcha. Like a lot. This add-on gives you the ability to add honey-pot captcha to Freeform, Comment, and Safecracker forms.

Minimee
This is my preferred method for minimizing JS (not necessary for CSS since I’m compressing with Sass). Again, I love having settings in the config.php:

// Minimee
$config['minimee_cache_path'] = $config['base_path'] . 'cache/assets';
$config['minimee_cache_url'] = $config['site_url'] . 'cache/assets';
$config['minimee_disable'] = ($_SERVER['SERVER_NAME'] === 'site.local') ? 'y' : 'n';

Is Ajax?
Another add-on that I created to detect whether something is an AJAX request. There was already a similar add-on out there, but I didn’t like how the tags were used.

DataGrab
This has been a lifesaver for importing content from previous EE or WP installs.

CP Menu Master
Very useful for removing one-entry channels. There are plenty of times where I have created a separate homepage channel just to publish one single entry.

Snippets

Here are a couple of useful snippets in our default build:

channel_disable_most
disable="categories|category_fields|member_data|pagination|trackbacks"

channel_disable_basic
disable="category_fields|member_data|trackbacks"

The previous three snippets make it easy to include the disable parameter in the channel entries tag:

{exp:channel:entries
    channel="news"
    {channel_disable_basic}
}
    ...
{/exp:channel:entries}

date_format
%F %d, %Y

Does anyone actually remember all of the date formatting variables? Not me. Using a snippet makes it easy to have a consistently formatted date across the site:

{entry_date format="{date_format}"}

“Functional” Templates

In one instance when we were using Image Sizer on a site, we pushed the site to the live server, and for some reason, Image Sizer didn’t work on that server. So, we ended up making the switch the CE Image. But, the reason this was such an easy switch is because we had a single template for resizing images:

{if embed:src}
  {exp:ce_img:pair
    src="{embed:src}"
    max_height="{embed:height}"
    max_width="{embed:width}"
    crop="yes"
  }
    <img src="{made}" alt="{embed:alt}" class="{embed:class}" width="{width}" height="{height}" />
  {/exp:ce_img:pair}
{/if}

And then we just embed that template and pass in the image as an embed variable wherever we wanted to display it. Thinking of templates like this can be useful at times. Just think of it like a function that you pass parameters (embed variables) too.

What about you?

Are you guys using a default build? What do you have in it? Anything we can learn from yours? If you aren’t using a default built, I would put it at #1 on your todo list. We can get a new EE site ready to go locally in about 5 minutes now.

Post-Implementation, Pre-Launch: A Crucial Checkpoint

2011-09-22T15:03:00Z

There's a certain type of project we find ourselves working on every now and then that can turn me into a puddle of stress until (and often after) the site launches.

It goes something like this:

The client has an internal web team and/or budget is tight -- so UX and design get full attention, but build-out is minimal. Our front end devs might build 2-3 pages, a basic elements page, or nothing at all. The client's internal web team is tasked with absorbing a set of PSDs and deconstructing the visual system. They need to create mark-up for the comps we've given them, and they need to extend the design and mark-up considerably to cover a large site. Oh, and they also have to port all of this into some type of CMS templating system. Usually under a hard deadline. Easy-peasey, right?

On top of all that, we often don't get to meet the people that are going to carry out this work. This means there is no opportunity to explain our vision or establish trust in either direction. As Doug points out in his excellent post about planning for hand-off, this can be a scary prospect for both teams.

The Current State Of Things

At Viget we already do a lot to help make sure the client's internal team has the tools it needs to rock it out. Our PSDs are organized, our layers are named, and layer comps are put to good use. Reusability and flexibility are considered throughout the process and built-in wherever possible. We have made element list pages (a comprehensive set of reusable pieces with CSS/HTML - example) a standard deliverable. And, of course, we always leave a line of communication open, so we can answer questions when implementation actually starts.

The problem is that sometimes this is not enough. We send our hand-off deliverables out into the world, and months pass without any word. Then, suddenly, we notice that the site is up ... And it's not at all what we -- or the client -- dreamed it would be.

Common problems:

There is a need for additional layouts, but the client team doesn't have the skill/time to make something consistent with the established design. Extensions of the design (new page templates, callouts, graphic elements, etc.) look piece-meal or are left without any style at all. The site feels disjointed.
Small but important nuances have been overlooked. Often these are details we've provided in the build-out, but they just weren't noticed or prioritized. Tiny things being off -- a few pixels shifted here, or a bad sprite alignment there -- makes everything look buggy and loosey-goosey.
Design elements have been used in ways we never imagined they would be. They start to break the visual system, creating clutter and confusion.
We've neglected to style something basic that didn't show up in comps, like a blockquote. The client's version of it looks out of place with the highly styled elements around it and feels incomplete.
Content looks nothing like what we had planned for in the UX and design phases, so it feels like it has been shoehorned in. The design needs to change to better accommodate this new content.

Small things make a big difference, as we all know. When one or two of these things go wrong, the entire site begins to look jumbled and unprofessional.

How can we make it better?

Nobody wants to see this happen. Designers are sad to see their carefully crafted designs fall apart, and clients must be disappointed to launch a site without the polish they envisioned. But, a little more communication between teams and a few hours of pre-launch QA on our side can make a huge difference.

I recently had the pleasure of working on UPenn.edu, which was a great example of how we can improve/avoid these issues. The project process was similar to what I've outlined above, but with two major differences that made a big impact:

The Penn web design team was involved in all of our conversations from the very start. They were at the kick-off and followed along with our progress from wireframes to final comps. We got to know each other over the course of the project. They were familiar with us and our vision.
Shortly before UPenn.edu launched, we had the opportunity to take a look at the development site and help with QA.

Bullet point #1 was awesome, because everyone was on the same page, so we all felt comfortable asking questions. It felt like a collaboration rather than one team handing down directives to another. Big props to the Penn team; they were really fun to work with.

#2 is really big and doesn't happen as often as we might like. I jumped at the chance to help with final tweaking, as did other team members here at Viget. I cannot stress enough how great it was to have a chance to help tighten things up before launch. Though the Penn team did a great job of implementation, there were still, inevitably, a few improvements to make. We were able to provide a few extra design elements and layouts, find and knock out some bugs, and just generally support the Penn team as they raced toward their deadline. IMs and emails were flying back and forth all week. Everyone seemed to feel the excitement as the site started pulling together. We didn't have direct access to files, so we sent over code snippets and their team was extremely patient about even our (okay, my) most nit-picky requests. It was the best-case scenario with this type of project. The result is a site that everyone can be proud of.

When we're handling UX and design but minimal build-out, I'd love to see this become standard procedure. It is a crucial checkpoint. Everyone gets to take a step back and look at the big picture, to evaluate how our deliverables have stretched and grown to fit the full site, and to revisit our decisions and make sure they're still working. It's inevitable -- there will always be things that need to change between design and implementation. We should plan for a few light design, UX, and FED updates to accomodate those changes whenever possible.

Does anyone else have good suggestions for smoothing the internal/external pre-launch process?

8 Faces: Viget

2011-09-19T13:40:00Z

Why?

Typography is very central to the work we do as designers. There are many tools and techniques. There is much history. And as we all know, the world of web-type these days is developing rapidly on a day by day basis.

Recently at Viget, we decided to conduct our own internal version of 8 Faces to figure out the collective typeface preferences of our design team. There were a few reasons for this:

Curiosity: we were interested to know which typefaces would rise to the top
Simplicity: with a font library in the hundreds and thousands, it begs the question, how many are truly irreplaceable?
Efficiency: this is probably a secondary reason but it has come up before that it may be useful to have a list of solid, tried-and-true typefaces that we could use as a starter set for new hires and interns

How We Got the List

Here is how we decided which would make the cut:

We had everyone submit their top eight typefaces*, in order of importance. They did not have to be available yet on the web – this was due to time considerations and also because we wanted to see what the top choices were, period. Then afterward, we'd worry about pricing, implementation, and availability.
We developed a point system (1st place: 9 points, 2nd place: 8 points, 3rd place: 7 points... 1 point for each Honorable Mention that was listed but not in someone's official Top 8)
The team was asked to include six "workhorse" typefaces and two that had more specific uses or unique characteristics. Due to this stipulation, the results were generally swayed in the direction of being more multi-use and less eccentric or display focused.

* Disclaimer: Helvetica is not officially on the list but is certainly well-loved by our design team, especially Rob Soulé.

Our Top 8 Selections

1. Din

Sans serif, Grotesque
Designed by Johannes Erler in 1925 in Germany
FF Din was designed in 1995 by Albert-Jan Pool
Web Availability: Fontfont, MyFonts, Fontdeck, MyFonts , Typekit (Din Condensed)
Usage samples:

2. Univers

Sans serif, Transitional
Designed by Adrian Frutiger in 1957
Web Availability: Fonts.com (Professional Plan)
Usage samples:

3. Franklin Gothic

Sans serif, Grotesque
Originally designed by Morris Fuller Benton in 1902
Web Availability: Fontdeck, Typekit, My Fonts, Fontspring (Franklin Gothic FS)
Usage samples:

4. Meta

Sans serif, Humanist
Designed by Erik Spiekermann in 1986
Web Availability: Typekit, FontFont
Usage Samples:

5. Gotham

Sans serif, Geometric
Designed by Hoefler & Frere-Jones in 2000
Web Availability: Not currently available

6. Trade Gothic

Sans serif, Transitional
Designed by Jackson Burke in 1948
Web Availability Fonts.com (Trade Gothic Next)
Usage samples:

7. New Century Schoolbook

Serif, Transitional
Century Schoolbook was designed by Morris Fuller Benton in 1919, consolidating and refining the original designs done by his father Linn Boyd Benton
New Century Schoolbook was designed by David Berlow for Linotype
Web Availability: Fontdeck (Grad, a digital variant designed by Mark Simonson), MyFonts (Century Schoolbook ++URW), Fonts.com
Usage examples:

8. Bodoni

Serif, Didone Modern
Designed by Giambattista Bodoni in 1798
Web Availability: Fontdeck (Bauer Bodoni), Fontspring (Bodoni FS), Typekit (LTC Bodoni 175), MyFonts, Fonts.com

What Would Be on Your List?

These typefaces came only from the input from our team. It's likely that almost every single person would have something slightly (or even majorly) different on theirs. What about you?

Become a Photoshop Layers Ninja

2011-09-13T13:53:00Z

I'm always looking for ways to use Photoshop more efficiently. My recent obsession has been finding keyboard shortcuts to work with layers. Claiming that you'll be a layers ninja after reading this might be a stretch. But try these tricks while your fellow designers are watching, and your stealthy sleight of hand will probably blow their minds.

Duplicate Layer

The first one has been pretty well documented. Holding down Cmd + J (Mac) or Ctrl + J (PC) duplicates the current layer selected. Easy right? Let's move on.

Duplicate Layer...Below

After duplicating a layer using the shortcut above (Cmd + J), Photoshop positions the new layer above the original layer. In many cases I want the duplicated layer to appear below the original layer. Honestly, who can afford the time to be bothered with manually moving each duplicated layer to a new position in the layers palette? (Answer: Nobody) To solve the problem, I created a simple action (download it below) that both duplicates the layer and automatically positions it below the original layer by pressing F11. Did you even see what I did there? No, you didn't. Amazing!

Duplicating Layer Groups

I'm a little obsessive about organizing my layers into groups. When a layer group is selected in the layers palette, the Duplicate Group menu item appears under the Layers menu. Since there is no keyboard shortcut defined, you can define your own under Edit > Keyboard Shortcuts.

Similar to layers, the new layer group will be placed above the original group. Actions to the rescue again. Pressing F12 duplicates my layer group and automatically places it below the original group.

Reversing Layers

If you didn't use the Duplicate Layer Below action, you might have a mess of layers that are in the wrong order. You could go out and buy a latté in the time that it would take to reverse the layers one-by-one. Luckily there's a hidden menu item called Reverse under Layers > Arrange. Simply select all of the layers that need to be reversed and Photoshop will do the heavy lifting. If you do this a lot, set up a keyboard shortcut do speed up the process.

To install the Duplicate Below actions for layers and groups:

Download the actions file.
Unzip the file and copy the .atn file into the Photoshop > Presets > Actions folder.
Open the Actions palette in Photoshop and click on the contextual menu arrow in the upper right corner.
Select Load Actions and find the file on your computer.
To change the keyboard shortcut for these actions, double click on the action layer and a box will open with options.

These are just a few of the things that I use every day. If you have more ninja style tricks that help you work with layers, I'd love to hear them.

Dynamic Diagonals

2011-08-25T11:23:00Z

The team here was recently checking out the Diesel Denim site. Pretty cool, and it's diagonal.

This reminded me of a few things:

Diagonals are dynamic (said in wise professor voice).
I don't use them much. More perhaps?
Diagonals are very much in play on the web. We're way beyond Flash and background tiles.
I should see what's out there.

Here's a handful that we dug up...

Print:

Mobile:

Web:

'Diagonal' on Pinterest. A little of everything.
'Argyle Socks' on flickr. Yesss.

If You Love Fontspring So Much Why Don’t You Marry It?

2011-08-23T14:40:00Z

The following account represents one person's unabashed love for an up and coming web font service.

As many know by now, the dawn of true web type is finally upon us. Dozens of service offerings have sprung up, pricing models have become more reasonable, and @font-face usage is becoming far more ubiquitous than it was just a year ago. I couldn’t be more thrilled.

We’re so close to the typographic possibilities that web designers have always dreamed of, but there are still some roadblocks in terms of what works best for agencies and clients. I won’t weigh the pros and cons of different services and options. That’s been done elsewhere already. I'd rather explain why I love Fontspring so much for our needs at Viget. For a more technical and pragmatic view on exploring the realities of @font-face usage see Doug's post.

Pay Once

I think it’s great that subscription models exist. There are many options out there right now. The idea of renting type for use on the web has good merit, but it’s not perfect. For instance, if you rent from one service but you want to use fonts from another service, you may find yourself having to pay for multiple subscriptions. I’d much rather hop around different services to find the best fonts for my needs and then pay once and be done with it. Fontspring has many good quality fonts at affordable prices. Pay once and never worry about it again.

More Control

Downloading and installing yourself means you have control over where the files are served, how they are called, and how they are optimized. This way you are not shackled into someone else's script or a large file size when you only need the uppercase characters of a font. Also, the more control you have over the optimization, the more control you’ll have over things like “Flash of Unstyled Text” aka FOUT. That’s the flickering you see when a font changes from a system font to the one being served by the host. Some browsers won’t even serve the system font until the host font is loaded to render. If you haven’t optimized correctly, there could be an annoying delay.

Formats

While WOFF appears to be the universal web font format of the future it’s still a work in progress. Fontspring offers TrueType, WOFF, EOT and SVG so you have all your bases covered.

Desktop Use

This is a big one for us. Many services will offer access to a robust library of high-quality fonts but not allow use on the desktop. This is great if you’re doing much of the design in a text editor, but far less appealing if you use a high-end graphics program like Photoshop or Fireworks to do your design work. I don’t want to debate the merits of designing in the browser vs. not. I think there are good reasons to do either based on your variables in play. It’s just that we’re at a point at Viget where we’ve become far more specialized than we used to be and most of our projects have a considerable amount of visual story-telling that is best done with painting and illustration tools. Being able to use fonts on the desktop legally is important to us, so having legit versions for use on both web and the desktop makes sense.

Unlimited Domain Use

Having to maintain what font is used on what domains and keep track of it is a pain. I just want to have the comfort of knowing I legally own the rights to use fonts on any project that I work on.

Pageview Limits

This one makes me want to gouge my eyes out. Fontspring charges you once for unlimited pageviews. Other services want you to calculate expected pageviews on an annual basis. This is hard to do accurately and opens the door for ambiguity or even straight-up lying. Furthermore, while the pageview model can be reasonably priced at smaller levels, it can get super expensive trying to secure unlimited usage. A recent test resulted in upwards of $1K for a single weight of a font. Gah!

So What Are The Downsides?

Can nothing be perfect in this world? While I love Fontspring the biggest downside is the selection. Don’t get me wrong, there are plenty of good options but the selection is still not as wide as I’d like it to be. Many of the fonts I’d like to use are only available via subscription models or without available web licenses. My hope is that some day soon there will be more options like Fontspring where I can find good quality, reasonably-priced fonts with suitable licenses for agency use without a subscription. At the moment, I worry that there aren’t enough competitors thinking in this way.

Some Favorites

As I mentioned, FontSpring does have some excellent options. Here are a few of my favorites:

Franklin Gothic FS

Proxima Nova

Interval Sans

Brandon Grotesque

Brevia

Halvorsen

Anivers

Calluna Sans

Calluna

Clarendon Text Pro

Bodoni FS

Sommet Slab

Eksja

Kaine

Alternate Gothic

Maybe I WILL marry Fontspring.

A Design Double Dog Dare: Switch Up How Organized (or Chaotically) You Work

2011-08-10T17:20:00Z

Thinking back to childhood, there were those who lined up their crayons, organized them by color, and sharpened them in that crayon sharpener in the back of the crayon box before ever touching crayon to paper. And then there were those who had crayons flung everywhere, mixed old and new crayons together, and basically worked in total anarchy.

The former grew up to be designers who start a project with a focused plan of attack and a perfectly structured workspace from the moment they open Photoshop. All their palettes, toolboxes, and grids are in perfect position before they put a single pixel on their PSD. They've already thought through the design and know what they'll do. They are generals, armed with strategy and schematics, to face down and conquer a design. There is a benefit to working this way. As this article from Do Your Best Work states:

Organization is in part about being prepared for the moment when insight strikes. It's about creating the conditions for creativity to flourish, so that when you enter into creation mode, your physical world is set up to support you. Being organized also creates the mental order that many people need to be able to put aside mundane things and enter a creative head-space.

The latter became designers who open Photoshop and face the blank canvas head on. Perhaps with some wireframes in hand and general directions from a client, but otherwise not knowing exactly what they're going to do. Those people are hitchhikers, knowing they have a destination, but not knowing how they'll get there, or what they'll come across along the way. Mike Kus's blog post "Web Design Is A Journey" about his redesign of Carsonified illustrates this beautifully. The designs at each stage of his redesign are drastically different, with ideas going in all kinds of directions.

Malcolm Gladwell says here about working in this kind of chaos:

Anyone who is in a creative space...you have to reverse the normal human tendency, which is to edit. Creative people...their brains are messy. Their imaginations are messy. Why, because they don't want to throw anything out...they believe on some level that there is always something of interest or value in whatever they encounter. They know enough about how mysterious and serendipitous and unpredictable the creative process is that they realize that it's dangerous to kind of make too hasty a judgment about the value of anything that they come across...

Embracing of messiness and understanding its contribution to the creative process is something that writers and creative types, artists, whatever have got to cultivate, have to learn to be comfortable with. Because it goes against a lot of our kind of instincts and training as kind of educated people.

So where do you fall on the spectrum?

And here's my double dog dare. It's the same challenge an art professor once gave to my class: for your next project, work in the completely opposite way you normally would. Get outside your comfort zone and see what new and different design solutions you come up with when you approach the work from a different perspective.

And then come back and tell us how it went! :)

Stop Making Sprites (Compass, Sass, and PNG Sprite Generation)

2011-07-20T12:40:00Z

Update 01/11/12: new code at the bottom of this post.

Sass has been kicking around for a while, but I hadn’t given it a try until just recently. Sass usually goes hand-in-hand with Rails, Compass makes it so easy to run Sass on standalone projects that I’ve started using it on nearly everything. The result is faster, DRYer, more enjoyable coding. The biggest benefit for me has been Compass’s sprite generation, which — if done right — can cut down your coding time and filesize.

Sprites are an optimization best practice, but they’re no fun to work with. Making them by hand requires a lot of nudgy mechanical math, and most auto-spriting tools create more work than they save. Compass does sprites the smart, Sassy way: by compiling them from your code and filling in the CSS rules for you.

It also does things the Rails way, in that it provides conventions to follow rather than configuration to specify. I’ll walk you through my process for Compass spriting on a simple, standalone project.

Folder Structure

This is how I’m laying out the example project:

index.html
config.rb
/assets
  - /images
    - /content
    - /structure
      - common-scc61cc8905.png
      - transparent-s72a23cbe19.png
      - /common (to be sprited)
      - /transparent (to be sprited)
      - /unique
      - /icons
  - /css
    - all.css
    - print.css
/compile
  - /pngquant
    - pngquant
  - /images (PSDs)
  - /sass
    - all.scss
    - print.scss
    - /core
    - /content
    - /pages

I like to separate any compile-to stuff from the actual final output — hence “compile” and “assets”. If a client receives the buildout and doesn’t want to use Sass/Haml/Coffeescript/whatever, they can just delete the compile folder for a clean build without any leftovers.

Sass allows you to break CSS up and @import it into a single file at compile time, and I tend to go crazy with this feature. CSS feels nicer, to me, chunked up like this and navigated with something like PeepOpen. All of my Sass files are imported into all.scss, and I watch that file alone with the command:

compass watch compile/sass/all.scss

Saving Images

The key to precutting images for sprite generation is to know Compass’s restrictions:

All images in a sprite should come from the same folder.
Sprites MUST be vertical in layout — there's no grid, just a big stack.
Anything you want to offset from the top/left/right of your element, or align right/center, you’ll need to specify using Compass variables.
Because of the one-directory-one-sprite convention, you should separate images that you need to use different color depths. For example, I use “transparent” for all my 32-bit transparent PNGS, and “common” for the rest).
No JPGs.
Compiling sprites can take some time. I’ve found it’s easiest to just use image-url() until the end of a project, then do all the sprite setup in one go.

CSS Setup

First, you’ll need to import your sprites from within a Sass file.

@import "common/*.png";
@import "transparent/*.png";

Any preferences you need to set for specific images need to be set BEFORE these imports, so it might actually look like this:

$common-divider-position: 20px;
$common-divider-repeat: repeat-x;
$common-go-button-position: 100%;
@import "common/*.png";

$transparent-tabcontrols-a-position: 50%;
@import "transparent/*.png";

(Where do names like "transparent-tabcontrols-a-position" come from? These are magic variables generated by the sprite/folder name and the file name [transparent/tabcontrols-a.png])

The only times you can’t get around these config options is when you want to center, right-position, or repeat an image. Otherwise, I try to avoid setting them here if I can accomplish the same result by changing an image directly.

Later in your stylesheet, you’ll want to replace the usual background-image and background-position rulse with something like this:

@include transparent-sprite(tabcontrols-a, $offset-x: 50%);

This outputs the path to your sprite and the appropriate BG position. The offset is optional and rarely used, but important for centered/right-aligned backgrounds.

Generating the Sprites

At this point in the example project, Compass is outputting “common” and “transparent” PNGs and linking them up in the CSS. So far so good, but there’s one problem: Cramming so many PNGs into one sprite has probably increased the color count past the 8-bit 256-color limit. When this happens, Compass’s PNG engine (chunky_png) assumes you want 24-bit color depth and saves your sprite accordingly — which generally means larger files and issues with IE6 transparency. Ideally, we want to re-render our sprite at 8-bit depth after Compass finished saving the sprite.

The quickest way would be to open the resulting image in Photoshop and “Save For Web”, but this is pretty painful to do dozens of times per project, so I prefer to automate it.

To auto-downsample the sprite, you’ll need a program that can smartly choose and dither the color. I use improved Pngquant (OS X-only) and save it in the project file at /compile/pngquant/pngquant. Improved Pngquant reduces the color depth of high-color PNGs and, does a fantastic job of it — check out the original software (and some non-OS X versions) over at libpng.

Then, we’ll set up Compass’s post-sprite hook in the config file to:

Create a leaner, 8-bit version of the sprite and delete the original.
Make sure NOT to do this for images that should actually have 24-bit depth (I usually name this sprite “transparent” and just check against the filename).
Fire off a Growl notification when compiling finishes. (Note: You’ll need the ruby-growl gem and Growl for this)

config.rb
require 'ruby-growl'

css_dir = "assets/css"
sass_dir = "compile/sass"
images_dir = "assets/images/structure"
javascripts_dir = "assets/javascript"

on_sprite_saved do |filename|

  unless filename.match(/^transparent/)

    png8filename = filename.sub(/\.png/, '-fs8.png')
    %x{compile/pngquant/pngquant #{filename}}
    %x{mv -f #{png8filename} #{filename}}

  end

  g = Growl.new "localhost", "ruby-growl",
    ["ruby-growl Notification"]
  g.notify "ruby-growl Notification", "Compass sprite generation",
    "Your sprite is done:" + filename 

end

output_style = :expanded
relative_assets = true
line_comments = false

If you’re ”compass watch”ing the Sass file, the sprite should start building once you make any modifications (even a small change should do it). You’ll get a Growl notification when it’s finished (1-3 minutes in my case, depending on how many images the sprite contains).

Sometimes the sprite colors might get a little crappy — This can happen if there are too many dissimilar colors into a single sprite, and Pngquant can’t find good compromises for them all. To fix, break the images into more sprites, grouped by color palette.

That’s all I know so far — Compass is maturing quickly, so we can probably expect even more improvements to sprite-handling in the future. Check out Compass’s spriting tutorial, and let me know if you have a different sprite method you’ve enjoyed working with.

Update: 01/11/12

Since writing this post, I’ve adjusted my original compass.rb code quite a bit. You can see the revised version in my FED Starter Kit. Also, take a look at Tim Kelty’s, which fixes an issue with the original code and updates the compass growl call.

JS 201: Run a function when a stylesheet finishes loading

2011-07-19T14:30:00Z

This is the first in a series I’m calling, “JS 201.” It’s not introductory material, but is instead that helpful middle ground between the basics and pretty much anything John Resig writes. Short, practical, typically plain-ol’-JavaScript tips is what you’ll get.

I’m in the middle of working out a new feature for a project that requires JavaScript to append some markup, stylesheets, and scripts to a page. The task is fairly straightforward: JavaScript has native capability to do all of that. I’m looking at you, createElement and appendChild.

I did run into a problem, though. A piece of JavaScript required styles be applied to certain elements before it should execute. Unfortunately, the script was executing while the stylesheet was being loaded. Like most reasonable front-end developers, I figured I’d just run a function when the onload event fired on the link element. It works for images, why not for stylesheets, right? Wrong!

Currently, only Opera and Internet Explorer support the onload event and onreadystatechange respectively. Strange bedfellows, for sure, but that leaves us with the entire Gecko and WebKit landscape without anything approximating the onload event.

What are we to do? Exploit the img element's onerror event, that's what!

var head = document.getElementsByTagName( "head" )[0],
    body = document.body,
    css = document.createElement( "link" ),
    img = document.createElement( "img" ),
    cssUrl = "/path/to/a/css/file.css";

css.href = cssUrl;
css.rel = "stylesheet";
head.appendChild( css );

img.onerror = function() {
    // Code to execute when the stylesheet is loaded
    body.removeChild( img );
}

body.appendChild( img );
img.src = cssUrl;

What's happening above isn't at all complex. We first grab references to the head and body. We create our link and a dummy img and define the path to our CSS file. Next, we set some attributes on our link element and append it to the head.

The next few lines are the sneaky bits. We first set a function on the img to run when its onerror event fires. This is where we put our code that we want to execute after the stylesheet is loaded. After that, we append the img to the body and then set its source to our CSS file path. The order of operations there is important, so don't swap those lines!

What happens behind the scenes is that the browser tries to load the CSS in the img element and, because a stylesheet is not a type of image, the img element throws the onerror event and executes our function. Thankfully, browsers load the entire CSS file before determining its not an image and firing the onerror event.

It's far from pretty, but it works, and it doesn't take a lot of extra code to make happen.

For further reading (and for some different examples), check out the following posts that served as reference and inspiration for this article: