Embedded above is an excellent presentation by Brad Frost. Below you can find a video that goes along with the slides.
Frost’s slides and talk revolve around the idea that the web is changing too rapidly to claim we can create future-proof websites or webapps. Instead we need to think in terms of future-friendly sites. In other words, forget perfection and start embracing what elements you can today. For Frost that means tools like responsive design, but also creating content that is “like water.”
“Think of your core content as a fluid thing that gets poured into a huge number of containers,” writes Frost. “Get your content ready to go anywhere because it’s going to go everywhere.”
Of particular note in the slides is Frost’s breakdown of Forbes.com into content and, ahem, not content. As Frost says, “people’s capacity for bullshit is rapidly diminishing… we need to respect people’s time and give them relevant, purposeful content without the extra cruft.” In other words, don’t be Forbes.
Be sure to check out the various helpful websites and books Frost lists toward the end for more on how to make your own sites future-friendly. [Update: Here's a link to Frost's collection of helpful links and resources for future-friendly sites.]
We’ve given you a look at some best practices for responsive design, but beyond the nuts and bolts of @media queries and flexible grids, there is something more subtle, and more important, at work behind the moniker responsive design.
Good design has always been about not just putting content first, but making it easy to read that content — give people what they’re looking for or they will go elsewhere.
It sounds rather basic, but if good, content-driven design were actually common on the web, then we wouldn’t need tools like Readability, Safari’s Reader or Instapaper, which are all services that strip out superflous distractions and give people what they want — content. If you’ve read through our guide to designing for readability first, hopefully you’re already streamlining your website and focusing on the content rather than sidebar, ads and other distractions. Responsive design picks up where that idea leaves off.
The cornerstone of any responsive design is a flexible grid system that adapts to different screen sizes, but that’s really the least interesting aspect once you master it. In the larger sense, responsive design is not about fluid grids, it’s about determining the constraints of the reader’s screen and how those constraints change the way your site needs to display. It’s about shifting your content based on the screen size of your reader and ensuring that your visitors have the best experience regardless of what device they might use.
In other words, responsive design is about making sure that the reading device being used doesn’t matter. Screen size is the obvious place to start. The constraints of small screens dictate some design choices, for example a single column of content, and means putting the primary content at the top of the page. It also mean ensuring your typography looks good. For example, the typical desktop browser font sizes of 14-16px often feel too small on an iPad.
But screen size isn’t the only thing to bear in mind when you’re building your site. Don’t ignore other aspects of today’s myriad mobile devices, like touch-based interfaces, access to GPS data or screen resolution. For example, your site might have a nice flexible grid, but if half your links require a hover state to be noticed, your site is no more “responsive” for a touch screen user than the average archived Geocities page. Also consider the impact of transitions and animations which can help guide users and create a greater feeling of responsiveness.
Different devices also have different built-in tools. Test for things like geolocation support using Modernizer and if the device supports it, use it. For example, a location-based form that works well on your desktop site might be better served by using the location data automatically on a mobile site.
In the end responsive design is not just about the size of the screen, it’s about how your arrange you information to give people what they want. Every site is different and you if simply jump on the flexible grid bandwagon without giving proper thought to your unique content, you’re not going to have an effective website.
Unless you’ve been too busy wake boarding the Alps to notice, there’s a movement afoot amongst web designers — Responsive Design. Ethan Marcotte coined the term responsive design to describe the process of using liquid layouts and media queries to scale websites so that they fit any screen size. If you’ve never heard of responsive design before, Marcotte’s introduction is well worth a read.
In a nutshell, responsive design means using fluid grids, fluid layouts and @media queries to adapt your website to the plethora of different screen sizes on today’s (and tomorrow’s) web. Whether your visitor is on a phone, an iPad or a gargantuan desktop monitor, your website adapts.
Responsive design becomes an even more appealing tool when you start, as Luke Wroblewski says, designing for mobile first. That is, start with the small screen. Strip your site down to its essence and then build from there. Starting from the bare bones ensures a great mobile site, and it forces you to really focus on what matters to your visitors.
So how do you go about building a good responsive site? Well, that depends on the individual website, but there are some common patterns that are starting to emerge. To help you get started with responsive design, here are a few nascent best practices we’ve gleaned from a variety of sources around the web:
Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
Use liquid layouts that can accommodate any screen size. Don’t simply design one look for the iPhone/Android, one for tablets and one for the desktop. Keep it liquid, otherwise what happens when some new, intermediate screen size suddenly becomes popular?
Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around.
Use the Respond or CSS3 Media Queries JavaScript libraries to bootstrap @media query support into older browsers that won’t otherwise know what to do with it. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screen.
Embrace lazy loading. There may be items on your site, auxiliary content that’s nice to have, but not essential. Load that content using JavaScript after the primary content is done loading.
Forget about perfect. Even with these suggestions you’re still leaving out users who have old browsers with JavaScript disabled. Such users are increasingly rare and if they see the mobile layout on their desktop, guess what, it’s not the end of the world. Your site is still perfectly usable.
Keep in mind of course that responsive design is a young idea and new ideas — and new tools — pop up everyday. Think of these not as hard and fast rules, but guidelines to build on.
Readability, a browser tool which isolates the text on a webpage making it easier to read, has announced it’s moving beyond its humble beginnings to become a “full-fledged reading platform.” Readability will now offer iOS apps and, more importantly, it’s no longer a free tool.
The new Readability will cost you a minimum of $5 a month, with 70 percent of that fee going directly to the writers and publishers whose sites you visit.
Readability and similar tools, like Apple’s Safari 5 web browser have been criticized for cutting into publishers’ bottom line by eliminating online advertisements. The new non-free Readability is at least in part a way to address this concern. As readers, most people want a clean, distraction-free reading experience. At the same time no one wants to deprive their favorite websites of the income necessary to keep the site going. Readability’s new pricing plan is an attempt to find some common ground and keep everyone happy.
Not only does the new Readability give readers an option to hide ads and view a more readable page (which they may well be doing anyway), it provides a new source of income for the site. Even better, that additional revenue comes from the actual content, rather than simply the ads surrounding the content.
Ironically, in testing the new Readability, I realized that most sites I read regularly already have clean designs, nice typography and uncluttered layouts — sites that don’t really need Readability. But the new payment system can help those sites too. Readability’s payment system turns the service into something more than just a reformatting tool — it’s a bit like a roving micropayments system, handing out money to sites you enjoy.
Here’s how it works: The minimum fee is $5 a month, though Readability encourages you to spend more if you can afford it. The money is then split up between articles where you use Readability. Visit only one site and it will get all of your money; visit several dozen and each will see only a few pennies unless you up your monthly payment. You can use the Readability web interface to see where your money is going. It’s like micropayments, but all the transaction details are handled behind the scenes by Readability.
Of course you aren’t just paying the writers and publishers. Thirty percent of your monthly fee money goes to Readability, which has some new browser extensions, web badges, an API and some nice looking (though as-yet-unapproved) iOS apps built around the popular Instapaper.
The Instapaper contribution means that in addition to the “Read Now” button, which gives you a more readable version of the current article, there’s also a new “Read Later” button. Read Later works just like it does in Instapaper, saving the article to your account for when you have more time to read. Unfortunately, right now there’s no way to actually integrate your Instapaper account with Readability.
The “Read Now” and “Read Later” buttons can come from either the Readability browser extension, bookmarklet or from the site itself using a new embedded button (there’s also an API for more sophisticated integration).
Despite the integration tools and new payment system, it’s unlikely most sites will ever get rich from Readability. Of course it’s unlikely most sites are making much from Google Ads either, and it certainly never hurts to have another form of income, even if it is measured in pennies.
[Update: For those worried that Readability is no longer free at all, we should note that you can keep using the bookmarklets and browser extensions without paying for the service.]
Top: Maximized window with tabs in the titlebar. Bottom: Normal tab bar
Firefox 4 has entered the home stretch. The recent release of beta 8 added the last of the major new features for Firefox 4, including a new add-ons interface, better syncing and more hardware accelerated WebGL support. From now until the final release later this year, Firefox development will primarily focus on squashing bugs and refining the user interface.
The Firefox 4 UX roadmap outlines the user interface changes that Mozilla is hoping to complete before Firefox 4 is released. Most of the changes are very small — improving the contrast of the type in the URL bar or tweaking the session restore dialog — but there’s one welcome change in the list that many Firefox fans have been clamoring for — tabs in the titlebar.
The idea of saving screen real estate by smashing tabs up into the title bar of the browser windows started with Google Chrome and has since been copied by other browsers and applications.
It’s a tiny tweak, probably not more than a few dozen pixels are saved, but it can make all the difference when you’re using a netbook or other small screen device. Putting tabs at the top of the browser window also adheres to Fitts’ law, which says that the closer things are to the edge of the screen, the easier they are to click.
In Firefox’s case Fitts’ law seems to be the main reason for the new look — tabs are only pushed into the title bar when the window is maximized, making it easier to flick the cursor to the top of the screen and click a tab.
The new tabs-in-the-title-bar look is expected to arrive in Firefox 4 beta 9 (which will be the next release in Firefox’s beta cycle), but you can preview it today by grabbing a special build of Firefox for Windows and Linux. The builds are the work of Firefox developer Bill Gianopoulos, and as such are not official releases nor are they supported by Mozilla.
Also bear in mind that the code used to create these experimental versions of Firefox comes from Firefox’s nightly builds, which means there may be more bugs than you’ll find in the latest Firefox beta. That said, these builds worked just fine for us on Windows 7 and XP.
If you’ve got a small screen or have been looking for a way to make Firefox’s tabs a bit more like Google Chrome’s, grab the experimental builds. If you prefer to wait for something official, Firefox 4 beta 9 should be released in the relatively near future.
Unless you’ve been too busy wake boarding the Alps to notice, there’s a movement afoot amongst web designers — Responsive Design. Ethan Marcotte coined the term 
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code