The ZURBlog is where we discuss interaction design and strategy.

At ZURB we're fans of what we call the ZURB framework — really just a lightweight global CSS file containing a global reset, some basic typography styles, structural elements like a body container, and the grid. The way we say the grid is no accident — it's an evolving entity that we use frequently and that generally makes prototype and site construction quite a bit faster and easier on us. However: there's a catch.

The grid is a 940/960 grid; 940 pixels of usable space with 10px padding on both sides, broken up into 16 columns. Each columns is 40px wide with 20px of gutter space, and we can break the content up into any subset of those columns. What we've found, however, is that our designs don't always map to the grid. Sometimes we need less space, sometimes we need an alternate column count. Modifying the grid isn't rocket science but it's time consuming, so we often work around it — which of course is almost the exact opposite of why we have a grid! I know. Fail.

Meet the ZURB CSS Grid Builder

To help ourselves out (and by association, help you out) we've created another addition to the ZURB playground: the ZURB CSS Grid Builder. This playground page lets you enter in the number of columns, column size, and gutter spacing to generate the CSS you need to quickly implement our grid system. You can even check the grid you've created against common screen sizes to make sure you're designing for likely use cases.

Well, go build something!

The grid isn't everything — it's nothing as robust (or heavy handed) as YUI and it won't solve all your problems, but it can be a big help when it comes to rapid prototyping and implementing on a grid based layout. Feel free to grab the grid you need, use it where you want, modify it as you need to. And hey if you want to tell everyone how great the grid is and how awesome ZURB is well, we won't stop you or anything.

Check out the ZURB CSS Grid Builder »

---

P.S. While you're out there gridding up a storm, don't forget that there's great value in breaking the grid. Compelling designs, moments of interest, sweet interactions and psychological motivators can all rely on breaking the grid and doing what you need to with your design. Here's a great article on techniques to break the grid, and why you should use them.

Go Directly to the Demo and Code →

We've all seen the basic file upload form for uploading avatars, images, memes, etc. The problem with these is that once you upload your image it's hidden from you. It's the same issue with masked passwords, you enter some data and then poof, it's gone. And not gone like sexy was gone, this is the kind of gone that not even Justin Timberlake can fix.

The file input is going to look something like this:

Did I upload a new picture of my face? Or maybe something less professional. It's like buying food at the grocery store, except you can't see what you have in your cart. Wait, did I just buy the diapers or the case of Tantrum (read highly caffeinated beverage)?

The solution is to use a little bit of JavaScript to upload the image as soon as it's selected and display a thumbnail so we can easily review the form before we submit it.

Head on over to the ZURB code playground to see a complete demo and breakdown of the JavaScript we use to accomplish this. The code playground is where we do crazy awesome stuff with JavaScript, HTML, and CSS.

Looking for the plugin? Skip the article and go straight to the plugin page. For everyone else...

Like it or not, JavaScript has become the heaviest asset on modern webpages. Long gone are the days of waiting for large images to load, now we wait for fancy effects libraries, re-tweet counters, and cornification.

When you load Twitter, Yahoo, or Google docs, almost half the data you load will be JavaScript. Below is an asset breakdown for docs.google.com.

Users Hate to Wait

After download JavaScript files need to be evaluated as well. The greater the complexity and size of the JavaScript the greater the load time and frustration of your users.

Users hate waiting for pages to load, and if most of that time is spent loading JavaScript then reducing the amount of JavaScript is the easiest way to turn that hate into love.

You probably already know this, but you haven't done it yet because it can be a major pain. Odds are most of your JavaScript weight (file size) is in large libraries that need to be included on any page that uses a single function from that library. You could try and split them into smaller libraries but then you would have to manage all the dependencies.

Less JavaScript Without the Hassle

What if there was an application that could automatically determine what functions you don't need and removed them for you? It turns out that Google released just such an application last week.

The Google Closure Compiler goes a step beyond minification. Rather then just remove spaces, comments and line feeds, it renames variables and functions to use less characters and will completely remove functions that you don't need.

Even if you are not using unobtrusive JavaScript (shame on you), you can add a bit of code to tell the compiler not to rename certain functions that are referenced from your XHTML files.

Effortless Work Flow Integration

We got so excited about the Compiler here at ZURB that we wrote a Rails plugin that integrates it with the standard Rails deployment work flow.

There were two issues we needed to resolve:

• Once you compile a JavaScript file it becomes damn near impossible to read and edit.
• Compiling all your JavaScript files together so the the compiler can properly determine what functions to remove.

It turns out Rails has built in functionality to combine and cache JavaScript files to minimize the number of http requests and improve the effectiveness of gzip compression. Our plugin hooks into that functionality and runs the combined files through the compiler before caching them. This allows us to mix and match our JavaScript libraries and have a single compiled file containing only the functions we need.

In our development environments the JavaScript files are linked individually allowing us to debug using the original source code.

So What are you Waiting for?

The complete documentation and source code are available on GitHub. Run script/plugin install git://github.com/mkelly12/google_closure_compiler.git and your all set with some sensible default settings. Configuration options are provided for the obsessive compulsive types.

Yesterday Google announced their Javascript Closure Library is available for public use. You may think you need another Javascript toolkit like you need another browser, but this library offers the experience of the Google collective which means speed, stability and cross browser support.

It also means we now have access to the libraries used to implement all the nutty things Google does in their most popular apps. Take this toolbar for example, used in Gmail and Google Docs, now available for you to do even cooler things with.

They also provide even higher level functionality, like this rich text editor used in Gmail and Google Docs which makes use of the toolbar shown above.

The library also includes a vast number of complex (and possibly obscure) JavaScript elements you would never want to code yourself, like this two thumb slider.

OK, I know what you're saying, there are already lots of JavaScript widgets like this at scriptkiddies.com and icantcodemywayoutofajsbag.net, but the key difference is this library has been battle tested in Gmail, Google Docs and Google Maps.

This is industrial strength stuff that will run fast, and is organized in a way that minimizes the amount of JavaScript you need to attach to each page. This reduces both the size of the scripts that need to be downloaded and the time the browser takes to evaluate them.

Want to see more? Browse over 70 demos on the Closure Library documentation page (click the demo tab). Ready to ditch the pickup and gas up the earth mover? Hop on over to the getting started pages.

In part 1 of this post we talked about why we needed to redesign the Notable visual annotations, and how we went about framing the problem. Now we'll show how we actually implemented the design, including some cool CSS techniques we picked up along the way.

Creating an Overlay with Layers

Our solution was not technically too complex. With Notable (as well as most of our projects) we've embraced the concept of graceful degradation: we take advantage of new CSS techniques that degrade cleanly to older browsers.

Our note overlays are composed of two main elements, an outer border div and an inner overlay div.

The overlay was the easy part. As Notable doesn't currently support IE6 (though it does support 7 and 8) we were able to use a PNG overlay to create the glass shine effect. It stays pinned to the top-left of the div so we don't have to worry about it scaling out to something enormous.

The border div has as its background a 1x1px white PNG, which creates the overlay itself. Combined with the shine overlay we had our glass effect. The border div also has a border-radius applied to it to round the edges in any newer browser. We gave the active state a -box-shadow property so that notes being created or edited would jump off the page.

Fun with border-image

The trickiest piece, and most fun, was actually the gradient on the border. As you can see in the mockups or below in the live code, the notes have a 4px border that fades from bright orange to a darker shade as you go from top to bottom. We didn't want to use a canvas knockout so instead we used border-image, which is a really versatile but slightly tricky CSS property.

The basic gist of border-image is that you can set an image of your choosing as the overlay for the border of an object, but the truth is quite a bit more complicated.

What happens is that the web browser takes your image and divides it into 9 equal section, a 3x3 grid. It then takes the top left section and makes that the top left border corner, then takes the top middle and stretches it across the top border, and so on around the object. What's tricky is it does the same for the center of your image, stretching it across the entire object.

As you can imagine even just like that border-image has some really cool applications for making a complex object out of a fairly simple image file. However we needed to cut out the middle, or it would obscure our glassy overlay. So, we cut it out.

Our border image is created with a 15x15 image with:

• The middle 5x5 square removed (or completely transparent)
• The top 5 and and bottom 5 pixels as solid colors (they are such a small part of the overlay they don't need to be a gradient)
• The left center and right center 5x5px sections contain the actual gradient we stretch across the left and right hand borders.

1. div.border {
2. border: 5px solid #feb515;
3. -moz-border-radius: 3px;
4. -webkit-border-radius: 3px;
5. -moz-border-image: url(border-image.png) 5 5 5 5 stretch;
6. -webkit-border-image: url(border-image.png) 5 5 5 5 stretch;
7. }

The border-image property only has a few values: image source, width (on all sides) and the method of applying the image.

Awesome, huh? These little lessons in implementation are pretty exciting for us; it's always fun to learn new tools to make awesome stuff happen. You can see our new note style by checking out this public Notable post.

More Behind the Scenes

These short sprints happen all the time at ZURB, not only for Notable but for clients as well. Our process has worked out well for us so far, and we hope you enjoyed this little window into it. We'll keep our eyes peeled for another opportunity to share our process and how we get things done.