ZURBlog is where we discuss product design, business and strategy.

ZURB has, at any given time, between 12 to 15 clients. On average, we end up creating wireframes for probably ... um, 90% of those. It's a lot of wireframes, roughly 2,200 a year between the entire team, and not counting internal projects. Yeah, you could say that wireframes are important to us.

We've even written about wireframes before, including why we wireframe at all. We've also written about some of the tools we use, especially the very excellent Omnigraffle (read more about Shared Layers in Omnigraffle and Omnigraffle variables). However, we've seen a tectonic shift ocurring in how we wireframe, in large part because of Foundation, realizing that we can't wireframe the way we used to as designers.

Traditional Wireframes Are Dead

Or as close to dead, as it makes no difference. Here's the problem with traditional wireframes:

• They give no sense or insight into flow.
• They have to be created at various different screen sizes to account for how customers will actually see them.
• The client won't see them in their native element. The context is wrong.

A recent hi-fi wireframe we created for Venyu

These aren't new issues with wireframes, and there's a few ways around them. You can link wireframes together into a flow using something like Powerpoint/Keynote or just image maps in HTML. You can make wireframes for desktop and phones and hope that that's enough to get a good idea of how something will work. And you can try and make wireframes look and feel like the way they'll really be seen. But all of that is half-assed at best. We need some new hotness.

Coded Wireframes FTW

For several of our recent clients, we've been creating what we call coded wireframes. The idea of coding up your wireframes isn't terribly new, there've been rumblings about it for a long time, but with the rise of rapid prototyping frameworks (most notably Foundation, of which we're rather fond) it's feasible to do it in the kind of time constraint we typically have with our 12 to 15 clients.

Coded wireframes are possible through a few functions, most of which are in Foundation, but some of which can be pulled in:

• The responsive grid in Foundation lets us very quickly create complex layouts that work on almost any device.
• Foundation's mobile visibility classes let you tailor the interface and experience for users based on the kind of device they're on. Very handing for moving around nav, changing the order of content, etc.
• Several plugins like Orbit and Reveal help us create modal dialogs and image/content sliders without having to muck around in JS.
• Services like placehold.it give us an easy way to drop in image placeholders to block out content. Just pass in an image source like "http://placehold.it/400x300" and get back a 400x300 image. Pretty sweet.

By those powers combined, we can create coded wireframes really quickly, and with a high degree of fidelity. The downsides are fairly minimal but should be mentioned — you don't have pixel-level control without a lot of extra effort, and adding in things like icons or less common widgets is not as simple as it is with the stencil libraries in something like Omnigraffle. We haven't found this tradeoff to be a problem. Now let's talk about what we do get.

Significantly Better Feedback and Iteration

We've always been hounds for feedback, but the feedback we get on coded wireframes is quite a bit better than it is on static screen. The client can get a feel for the flow and have a much clearer picture of how the final product will work, not just what it will look like or what functions there are.

Multi-Device Testing

We live in a world where your products need to work on almost any random kind of device. Static wireframes simply can't represent that kind of world, and coded wireframes absolutely can.

See one of our first coded wireframe projects, for last year's ZURBwired event.

Correct Context

Much of our impression of a service is colored by how we see it, and, in this instance, that means the device we view it on. The feedback we want will vary greatly depending on whether the user sees our work on a phone or a 30" display, and if they see it on the actual device with the affordances and restrictions it carries. Maybe tap areas are too small, or the layout looks weird on a large monitor. All things we want to know.

Try It!

It doesn't hurt to give it a shot and, at the end of the day, wireframing in code leads to a better product. The feedback is better, the feel is truer, and the final implementation is smoother. Download Foundation (or another rapid building framework) and create some wireframes by just hacking on the provided index.html, then let us know how it goes in the comments.

You build sites for mobile devices, right? Then you might've noticed the one pesky issue with responsive sites is the loading speed, especially when there's a slow cell connection. What you may not know is that there is a likely culprit for at least part of your problem — the ever-present social media buttons.

On small devices, such as mobile phones, bandwidth and latency are at a premium. The response time from the server can compound over a cell connection and cause some serious delays. That coupled with a generally smaller bandwidth, we have to be very careful about how much weight we put on a page. Those tiny Tweet, Like, +1 buttons you see on websites are actually brutally large elements to load for these constrained devices. How brutal? Let's take a look.

The Test

To test this, we created a very simple page with the three most commonly used social media buttons, embedded using the latest code from their vendors: Facebook's "Like" button, with a small counter, Twitter's "Tweet" button with a small counter, and Google's "+1" button with a small counter.

We tested each of the three buttons by loading them individually and as a group. We also loaded them both as cached and completely uncached. Anything local for the page was directly on the testing device. To arrive at our calculations for mobile load time, we're using an average of 100ms latency, based on the average latency of an iPhone 4S on Verizon 3G with full bars. LTE might be a bit faster ... well, until your battery dies.

The Results

Let's start with the really crazy stuff. To load the Facebook, Twitter and Google social media buttons for a total of 19 requests takes 246.7k in bandwidth. For perspective's sake, that's over twice the bandwidth and 3 times the number of requests required to load a complete, minified version of the entire Foundation framework. (Foundation packs down to about 113k, including images.)

Let's take a second to just let that sink in. Holy crap. Look at this resources chart from Chrome:

The first three requests are for a local version of Foundation, and are cached.

On a desktop, over a good Wi-Fi connection, the uncached load of just those elements is about 2.3 seconds. That may seem fast, but consider that your entire Facebook stream probably loads about that fast. Now consider the latency of 19 requests over a 3G connection, maybe with a mediocre signal and a lot of dropped packets. Ouch!

The Breakdown

So who's the worst offender of the big three when it comes to loading a button? Here's the rundown of average load time, uncached and cached:

Twitter, despite gaining nothing from being cached, is still the overall fastest social media button to load. Facebook and Google+ are about the same the first time, but Facebook doesn't gain much from caching whereas Google+ becomes about twice as fast.

The Solution

Don't misread us, we not ready to say "ditch these buttons." The fact these buttons can load as fast as they do based on a complex social graph is impressive. They are optimized. However, that optimization is often not enough for limited devices.

We also don't want to downplay their utility — Facebook's "Like" button is pretty handy, Twitter's "Tweet" button fuels trends, and the Google+ "+1" button now apparently determines what we see when we search so that could turn out to be, you know…a pretty big deal.

That being said, it's worthwhile to do something faster for mobile devices. The solution is actually pretty simple: each of these services still has a simple link to do what you want. Worst case, you have three images for the buttons, and that means three requests all off your server. No additional requests, no huge JS to parse, and no massive download. It's not as sexy, sure. Users will have to load a second screen to take action, but at least you're not punishing everyone in order to have this utility.

Here's how simple the Facebook share URL is:

And here's Twitter:

And finally, Google+:

Obviously, there is utility not represented with this option — it won't add fans to your Facebook page the way the "Like" button does, or impact search like the "+1" button does, but it will create a faster, friendlier experience for the majority of your mobile visitors.

Have you seen other ubiquitous but glaring violations of mobile design? We'd love to hear about it, and what your solution is (or could be). Designing for arbitrary devices is still a bit of a minefield, but hopefully we'll all pin this down together.

Ever notice that when you shrink your browser width an embedded video doesn't always shrink with it? Or that the same video doesn't scale quite right on a mobile or tablet? We noticed the same thing when we rebuilt and launched a newer, much sexier ZURBlog this year. We wanted the blog to be 100% responsive, meaning it had to look sexy on any device. Figuring out how to properly scale video embeds was one of the hurdles we overcame.

Videos That Break Down

The problem is that we don’t know which device the video embeds will be viewed on. Will someone open up our videos on a phone? On a tablet? On a laptop? We have no control on how people are going to consume our videos.

The standard embed works nice for desktops, but breaks down on phones and tablets. Here is an example: try to shrink your browser width smaller then this video below and you'll see how it's displayed on a smaller screen.

Making Videos Look Awesome On All Devices

Since the blog was built on Foundation, we wanted a pure CSS solution to this problem. The Javascript solution is a bit more complex for folks who are trying to use Foundation. That's because a number of initializations must be fired at a specific time. Using CSS is much simpler. Check this out — try to shrink the browser and watch the video below:

The major issue with scaling is to ensure you keep the ratio of width to height constant and adjust the height appropriately. The code to embed a responsive video on your site is dead simple if you’re using Foundation, here it is:

<div class="flex-video">
    <iframe width="420" height="315" src="http://www.youtube.com/embed/9otNWTHOJi8" frameborder="0" allowfullscreen></iframe>
</div>

<div class="flex-video widescreen">
    <iframe width="560" height="315" src="http://www.youtube.com/embed/N966cATFWjI" frameborder="0" allowfullscreen></iframe>
</div>

<div class="flex-video widescreen vimeo">
    <iframe src="http://player.vimeo.com/video/21762736?title=0&amp;amp;byline=0&amp;amp;portrait=0" width="400" height="225" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
</div>

That's all! You dont need to worry about how videos are displayed on any device anymore. You can read the full documentation about this feature on the Foundation site and, of course, dig through the code to see how it’s implemented. Enjoy!

Our old and busted blog that we decided to rebuild

Things have been insanely busy around here at ZURB this past year. As you recently read, we did more open source projects than ever before. Yet we still managed to squeeze in time to make some changes to ZURBlog so that it looked freakin' awesome on any device, which you astute web surfers may have noticed. Over the course of several months, we worked vigorously to build a brand-spanking new and sexier blog with nifty features, such as the ability to comment on posts with Facebook and finding older posts faster.

The Problem

Our old blog just wasn't performing up to snuff. That's because our old system was based on Rails 2.3 and chained to the behemoth ZURB.com master repository, which several programmers had hacked over in the course of five years. As a result, our code base had grown to a gargantuan scale over the years and was all interconnected. A slight change would be enough to crash the entire application, and that would bring an engineer who deployed the latest change to tears.

We realized that making any changes to the blog would require some hacktackulous programing.

The Remedy

So the team deliberated. Briefly. Then it hit us! We needed to move everything off ZURB.com, transforming it into a static site that would become the central hub for everything ZURB. The rest of the site — the portion that required a more dynamic experience — would be deployed as individual applications thanks to a nifty feature called sub-URIs.

Our blog would be the first to adopt this new structure, ushering in a new era of blogdom.

Rails Action Caching

Besides severing the blog’s ties to ZURB.com, we wanted to boost the speed into warp. So we upgraded to Rails 3 and built the blog with action caching.

The old blog, bless its heart, had to make the trek from your computer to our server, where it plummeted into the bowels of the ZURB.com database to fetch your post — for each and every page request.

Rails action caching enabled us to halve the request time, which prevented a bunch of unnecessary trips to the database, and made for a happier reading experience.

Nix Out Third Party APIs

As part of the rehabilitation process, the dodgy and sly third party APIs — Twitter, Delicious , and Flickr — had to be quarantined and given second-rate seating. Something we wanted to avoid was making direct requests to the Twitter and Flickr APIs, which our old blogging system did continuously and without persisting any data in a database.

We know ... this was silly, but we’ve since come to our senses.

Before, if Twitter went down — which, by and large, happens almost every day — our site would take a beating. We remedied this by using the amazing wheneverize to schedule all of our processes and run them in the background. The new code fetches new Twitter updates and Flickr photos every few hours and stores them in the database.

The blog on a mobile phone.

Hot New Features

Yes, we’ve sped up the old blog, but we also added some hot new features. You can now search through our growing collection of posts, leave a comment through Facebook, and spread the word through better social interactions. You can also read the blog on your mobile phone, tablet, and desktop thanks to Foundation.

Built on Foundation

Using Foundation’s grid system, we were able to see what the blog would look like across those devices. The blog’s new layout was built nearly identical to the old one, but we gave it a more modern polish and also made it easier to search through our previous posts.

Searching with Sphinx

We’re currently somewhere around 800 post and we're posting more and more everyday. So we thought it was necessary to make it easier for our users to search for our snazzy CSS3 buttons article through the blog rather than going through Google.

The new search functionality is built on the ever popular Sphinx via the Thinking Sphinx Rails gem by Pat Allan over at Freelancing Gods.

Facebook Comments

Besides making searching easier, we've made it a snap to leave a comment through Facebook. With more and more people using Facebook to comment, we could no longer avoid building a Facebook presence. (You can also comment using Yahoo or AOL!)

We must say, it has paid off. It has allowed us to quickly engage with our Facebook contingent, syncing up with our friends and customers through another channel.

The only major concern we've had with Facebook comments is keeping our comment count in sync via the Event.Subscribe method that Facebook suggests. Sometimes that method just doesn't fire correctly, and our comment count gets out of whack and has to be manually updated.

But that shouldn’t stop you from commenting below and telling us what you think about the changes we made to the new blog.

This has been a crazy year for us here at ZURB. In between laser tag, pumpkin carving, tons of great soapbox talks and one madcap 24-hour ZURBwired, we did more open source projects than we ever have in the past. It's been tremendously fun and extremely rewarding as well as difficult, frustrating, and challenging. Here's the top 4 things we learned on our open-source escapades in 2011.

The Need for Open Source Tools is High

We don't go out of our way to broadcast our open source efforts, our marketing efforts are usually devoted to other aspects of our business. On the ZURBplayground, we post pages talking about plugins or tools we've created and made available, and we'll blog or tweet a bit, but the adoption and feedback we get on these things is incredible. With very little effort to spread the word, these things really get around.

The Bar for Quality of Open Source Tools is High

We try and ensure that the open-source code we push out is as good as we can make it — and we still need to make it better. As soon as you make something available, even when it's free, you will immediately start to hear how it could be better, or more robust, or more capable. Tools like jQuery have set a very high bar for open source (at least technically).

Open Source Requires Serious Commitment

When we released Foundation, we decided from the start that we were in it for the long haul. No matter how successful it might be out of the gate, we knew there was a degree of dedication and a show of commitment that would be required for people to trust a new tool. We were right, and our day-to-day commitment to these projects is surprisingly high.

Open Source is Full of Fascinating Challenges

Build something open source if you ever want to know if you can handle building something well, cleanly, and elegantly. You'll learn more about the edge cases, unique needs and general mindset of users than you ever will from other avenues.

Here's a recent example: Foundation lets you tag items to be shown on specific types of devices, like phones or tablets. Our implementation wasn't perfect – some laptops would appear as tablets and some tablets as desktops. After exhausting our options in CSS alone we decided we had to use Javascript — but how? Whatever we did would need to work everywhere Foundation works (which is pretty close to everywhere), and it would need to work without any new effort or a learning curve. It would need to fall back in case the user didn't include our JS, or even if JS was turned off. Every decision we made would have ramifications for thousands of users, and would cause a flurry of emails asking for support if we did it wrong (or even if we did it right).

We settled on including a version of Modernizr with a CSS fallback, but we'll no doubt hear from users soon about how that's solved their problems and created some new ones. That's the way it goes.

Bonus: It's Fun

We've had a pretty great time working on open-source projects this year. It's tough and demanding, but the payoff is great. Not in terms of dollars (although our efforts do have an impact on our consulting and product business) but in terms of community, and the joy of seeing someone use something you worked on to get great things done.

We'd love for you to chip in on our projects, including Foundation, the Sass and Rails gem versions of it, Joyride, Reveal, Orbit, Flickrbomb, or any of our other playground pieces where we always try to keep things as open as we can.

Here's to more awesome open source projects in 2012! Let us know what you're working on, we'd love to see it.

If you're interested in hearing more, we were interviewed for The Changelog podcast.

We’ve had a great response to Foundation so far (thanks everyone!) but one piece of feedback we’ve received is that the small device layout for the Grid is too limiting. Currently, everything just stacks up, and sometimes you need more. Well, we heard you!

Enter the Foundation Phone Grid, released last month. We wanted to take a few minutes and show you how it works and how to use it on your projects.

How it Works

The Foundation grid is 12-column, meaning you can have any combination of columns that add up to 12. One, seven, four; five, five, two, etc. We didn’t think it made sense to maintain that many columns on small devices, so we opted for a four-column grid.

You’ll notice that, of course, we can’t just translate the 12-column grid sizes into four by dividing them all by three or something like that. How many columns is 5/12 when you only have 4? It’s close to six, but not quite there, so do we round … up? Down?

Rather than guess, we created four special classes that can be added directly to the existing grid and give you control of how you use the phone grid. By adding classes of:

• .phone-one
• .phone-two
• .phone-three
• .phone-four

…to the existing columns you can determine how your layout adapts on a smartphone or other small mobile device. Let’s look at an example.

Example Time

We’ll use one of our existing Foundation example pages to see how this works. Consider this page:

This is a fairly simple layout for a fake social network, laid out entirely with the grid. Let’s look specifically at the block on top left, an entry from a particular CGI movie character. We’ve used the grid to set this up, and the markup looks like this:

With only the default Foundation grid, every one of these column sections will get stacked on top of each other. For things like user avatar, or images with comments on them, this sucks.

By adding in classes for the phone grid and relying on Foundation’s innate ability to nest rows, we can switch that up to something much more robust. Check it out:

The markup for this revised layout looks like this:

Notice how we simply added phone-one and phone-three classes right alongside the existing column sizes? Easy peasy.

Try it out!

The phone grid is part of Foundation 2.1 and can be downloaded from Github, or from the Foundation website. We’d love to hear what you’re using Foundation for whether you use this feature or not. Just link it up in the comments below or email us at foundation@zurb.com.

We’ve got a lot more fun in store for Foundation including video-embed scaling that works (really), source ordering, bug fixes, and refined styling. Stay tuned!

Last week we released Foundation 2.1, our fourth release in as many weeks. We're really excited about Foundation, and equally excited that so many of you share our zeal for this framework. We wanted to take a couple minutes and show you how maintaining and extending Foundation fits into our workflow, so you can draw some ideas on how you can do even more awesome stuff with your products (or maybe and open source project).

Keeping Busy

We stay very busy here at ZURB, working not only on numerous client projects but also on our own apps like Notable and Verify. In the midst of all that we also developed and now continue to work on Foundation, so we have a few tools and processes that help us out.

Git and Github

There are quite a few people working on Foundation at any given time, both inside and outside ZURB. We use Git to keep track of versions and commits (thanks in part to a pretty slick native OS X app) but we also use Github to keep on top of bug reports, feature requests, discussion and contributions.

We've found tagging to be very useful when it comes to staying on top of issues, and we're fairly disciplined about when issues get closed down.

Deploying Updates

We use a few criteria to determine when and how to release updates to the public. This relates specifically to foundation.zurb.com, not the repo — the Github repo contains the bleeding edge code at all times.

• We push a minor point release when we're confident that the bugs we ironed out are squashed, we've tested cross-device and cross-browser, and we've resolved a decent number of issues or feature requests.
• We push out a major point release when we've added significant new functionality on top of the usual bug fixes and minor features.
• We'll push out a full new version when we've rearchitected sufficiently that the framework is no longer fully backwards-compatible. This is a ways out still.

When we're ready to release we have a local Ruby build script that takes an up-to-date local repository and packages all of the root files (without the marketing or documentation sites) and turns it into a single downloadable file. The script takes all of the JS (except jQuery) and packages it into foundation.js, then takes all the CSS (except app.css) and packages it into foundation.css.

We did it this way on the assumption that most people downloading the framework from the website are interested in building quickly and deploying rather than hacking away on the framework — by combining files we can eliminate requests which on a mobile device could have very high latency and thus a long delay to load.

Managing Time

Between issues, emails, tweets, and actual code you can imagine that Foundation could take an awfully large chunk of our time. With everything else on our plates we have to keep a few things in mind:

• The key to success with the public release of anything is to stay on top of it. We try and respond to every email, every tweet, every issue within a day.
• Foundation needs to not only support outside users but also our core services. We use Foundation for our client projects, both to deliver final code as well as to responsively prototype wireframes and interactions. We have to maintain it as rock-solid, proven code for our clients.
• It's not a one man job. Our entire team is involved in Foundation, either directly coding on it, spreading the word about it, or using it day to day and giving feedback.

Foundation is a lot of work, but it's extremely rewarding. Thanks to all of you for helping make it so successful, and we hope this little picture of how we work on it gives you an idea of how you could contribute and help us make it even better. Let us know in the comments, or on Github, what we could be doing to improve the framework and how you'd like to contribute!

We're excited to announce that we've just pushed Foundation 2.1 to the main Foundation site, available for download or for checking out from Github. We've been working on this release for a couple weeks, incorporating changes based on all kinds of feedback, issue and bug reports as well as some new tools to get you up and running even faster. Here's the highlights:

• New 4-Column Phone Grid: We've heard from a few of you that the way Foundation handles very small devices (stacking the grid vertically) could be extended for a little more control. You can now use classes that attach directly to the existing grid to make use of a 4-column grid only on phones. Check out the grid documentation to learn more →
• New Sass Gem: For those of you who to prefer to use Sass, you can now install it through a Ruby gem. Check out our Gems page in the documentation →
• Vertical Navigation Tabs: If you need a more scalable format for tabs, you can now attach a class of 'vertical' to have them stack; this is ideal for a sidebar. You can see it in action on the revised documentation site or jump right to the UI documentation page →
• Numerous Bug Fixes including fixes for Orbit, browser compatibility, inputs and buttons and lots more.

We've been very fortunate to have a lot of great reports, discussion and contributions on Github — if you haven't gotten involved there yet we'd love to have you. Still plenty to do for Foundation!

A little while ago we wrote a post on the pros and cons of stacking divs to speed up interactions. Since then we received a number of questions regarding guidance in regards to the website response time. Specifically: What should the response times be for a typical site? Some of you who have attended our our Interaction Design For Engineers talk have probably heard us speak about this. In this post we’ll go over 3 important limits to remember for site response times.

Less than 100ms

For an action that has no shared control (such as typing something in a field) 100ms is the perfect response time. You type a character and you expect it to show up in the text field immediately.

Here is the example of how to use a sub-100ms response time:

More than 100ms but less than 1sec

Any action that takes more than 100ms and less than 1s implies shared control between person using the interface and the interface itself. In other words, the user expects the app to process the command they have asked it to do. If a user clicks “next” after filling out a form, they expect to wait for at least 100ms until something happens. You might need to add a delay in your interface to achieve this response time. See below:

More than 1sec but less than 10sec

For anything that takes from 1 to 10 seconds, the user starts to lose focus on the task and lose flow. If you are in this range, you have to show some kind of message that something is happening but you don’t necessarily need to say: “this will take 20 seconds to come back”. A good solution for this response time is a spinner or some type of progress indicator such as this:

More than 10sec

This response time is just plain old depressing for the user. If the action will take more than 10 seconds you need to notify the user that they have time to go get coffee, check Twitter or their email or do something else. Alternatively, you can give the user something fun to do while they are waiting for the action to complete. Here's something we use to engage users while they are waiting for a process to complete:

Response times are a tricky subject; it’s easy to mess up the interactions and lose a customer’s focus during longer processes. Hopefully this post clarifies what to do during each time window. We’d love to hear any past experiences you’ve had with response times. Give us a shout.

It's been a wild two weeks since we released Foundation! Our open-source framework for rapidly prototyping for all devices has taken off even faster than we expected and we've been thrilled with how excited everyone has been for it. Here's a few highlights:

• We were covered by Mashable, who said "Our favorite aspect of Foundation is the ability to hide or show elements based on the media query (screen resolution) of a website."
• We were also covered in VentureBeat! "Seeing Foundation's magic in action is, well, a bit magical."
• Just today there was a nice write-up in ReadWriteWeb about building for every screen. "Whether for prototypes or even full-blown sites, it's great for the Web that ZURB has given us Foundation."
• We wrote a guest post for Smashing Magazine all about how to use Foundation to rapidly prototype.
• One enterprising fan already created a Foundation Wordpress theme.
• We've had over 50,000 visits to the Foundation site.
• We now have over 900 watchers on Github, and we were featured on the Changelog featured repo blog. Stay tuned for our appearance on the podcast!
• We've also gotten dozens of emails, hundreds of tweets, and resolved 34 issues (so far).

So what?

You've probably noticed that we're fairly passionate about this because we really believe that design for devices, not just desktops, is absolutely essential going forward. Foundation is our tool for making that easier for us, and for you, and we can't do this without your help!

All of you who have checked it out, viewed the site, sent us feedback or bugs have helped make Foundation an even better tool for this new method of Web design, and we've been working hard to integrate that into our releases. Keep it up!

New in Foundation

Yesterday we released Foundation 2.0.2, our second point release since the launch. In this update, and in 2.0.1 before it, we:

• Changed the download pack so that the CSS and JS are consolidated. That means fewer requests for mobile devices out of the box. You can still get each individual file by cloning from Github.
• We added in alert styles so you can easily create page alerts, either by hand or using a tool like Rails.
• Added in forms CSS to allow for Rails-style error states (error wrappers), merged from one of our contributors
• Numerous bugfixes for edge case styles, documentation, browser QA and more

What that means is that Foundation is now even more reliable and has more tools for you to use to build rapid prototypes and production code for any device. We've got some cool things coming up including more small-device tools, additional form styles, and a slew of handy extra tools for Sass, Compass, and Less.

If you're working with Foundation already we'd love to check out what you've created, and of course we're always available to answers questions either via email, twitter, or our Github issues page. Thanks for helping make Foundation's first two weeks so successful, and we're excited to keep working on this project with you for the coming months and years!