Archive for the ‘Visual Design’ Category

What the New iPad’s Retina Display Means for Web Developers

The high-res future is coming

The first of the new iPads will arrive in the hands of the public this Friday, March 16. Like the iPhone before it, and no doubt many more devices to come after it, the new iPad has four times the resolution of typical screens. That means your visitors will soon be looking at your site on a high-resolution screen with a whopping 3.1 million pixels.

The sharp, crystal-clear screens are awesome news for new iPad owners, but they create some new dilemmas for web developers who’d like to offer a better experience for high-resolution screens. Sure, increased pixel density means you can serve up sharper, better looking graphics, but there is a cost as well — bigger images mean more bandwidth and longer page loads.

This isn’t a new problem by any means and Webmonkey has looked at a variety of solutions in the past, including techniques like adaptive images and responsive images.

The problem is simple: you need to send smaller images to small screens and larger images to larger screens. Sending a huge iPad-optimized image to a device with a max resolution of 320×480 just doesn’t make sense. At the same time, when bandwidth isn’t an issue, most sites will want to serve high-resolution content to displays that can handle it.

The ideal solution would be to detect both the resolution of the screen and the available bandwidth. Then, based on the combination of those two factors, the server could offer up the appropriate image. Currently that’s not possible, though there are already proposals to extend HTML to handle that scenario.

The Responsive Image Working Group is a W3C community group hoping to solve some of these problems. The group is proposing a new HTML element, <picture>, which will take into account factors like network speed, device dimensions, screen pixel density and browser cache to figure out which image to serve up. Think of it as a much smarter version of the old lowsrc property. So far though it’s all hypothetical

In the mean time if you’d like to serve up high resolution images to your third-generation iPad visitors look no further than Apple.com for one (not necessarily ideal) way to do it. An Apple Insider reader noticed that Apple is already prepping its site to deliver double-resolution images to new iPads. Cloud Four’s Jason Grigsby, whose responsive image research we’ve covered before, has a great breakdown of what Apple is doing.

Essentially Apple is serving up lower resolution images by default, then using JavaScript to send larger images on to iPads. That works, but it will definitely mean increased download times for new iPads since they have to download two files for every graphic. Apple’s approach will also up the number of HTTP requests, which will also slow down the page.

The slower page loads seem to be an acceptable trade off for Apple since the company no doubt wants to showcase the new iPad’s high resolution display with high resolution images. For other sites the bandwidth trade off may not be worth the gain in image resolution.

Still, screens are only going to continue getting better with ever-increasing pixel density. Now is the time, if you haven’t already, to start embracing CSS 3 (avoid images altogether with gradients, shadows and rounded corners in CSS 3), Scalable Vector Graphics (SVG) for resolution independent graphics and of course @media queries to serve high-res background images.

For more on detecting and developing for high resolution displays, check out these posts from around the web:

Connect With Your Creation Through a Real-Time Editor

Inspired by Bret Victor's demo, Chris Granger's live editor helps connect you with what you're building.

Last month we pointed you to a video of Bret Victor’s talk, “Inventing on Principle.” Victor has worked on experimental UI concepts at Apple and also created the interactive data graphics for Al Gore’s book, Our Choice. In the talk Victor showed off a demo of a great real-time game editor that makes your existing coding tools look primitive at best.

Inspired by Victor’s presentation, developer Chris Granger has put together a similar live game editor in Clojurescript.

If you haven’t watched the video of Victor’s talk, you should start there, but the basic idea behind his real-time editor is to make your code more closely connected to what it creates, in this case a simple game. Granger’s take on the idea is similar — all changes you make to the code are reflected immediately in the running game. You change a line of code and the game immediately changes right with it. Here’s Granger’s video demonstrating the editor:

As Granger writes on his blog, “essentially I learned that Victor was right — there’s unquestionable value in connecting yourself with your creation.”

Granger’s demo code is available on GitHub and there’s a .jar file available for download if you’d just like to play with the demo.

File Under: Visual Design, Web Basics

Building Responsive Websites: How to Handle Navigation Menus

The Boston Globe's responsive navigation shrinks down to a selectable list

The web is moving rapidly away from its fixed-layout past into what it arguably should have been all along — a flexible medium that adapts to any screen size. While there are many aspects to the move from fixed to flexible, the overall process has been dubbed “responsive design.” That is, designing sites that respond to different screen sizes, fluidly adapting to the wide array devices available today and the myriad more coming tomorrow.

The idea of designing in a completely fluid medium is a very new notion for most developers. After all, print design was always a world of fixed layouts and thus far the web had largely followed suit. Moving to something where the size and shape is often unknown is a daunting, but exciting process that’s still very much in the early, experimental stages.

As with any experimental phase, old best practices are called into question and new ones emerge. Not all responsive design experiments are good ideas. Webmonkey has looked at some overarching best practices for responsive design in the past, but we haven’t necessarily covered the finer details of creating a responsive website.

As these things occasionally happen, several developers recently tackled one of the tougher aspects of responsive design — creating a navigation menu that works on any size screen. While key to creating a usable website, menus do not easily resize to fit smaller screens.

Maggie Costello Wachs, a developer with the Filament Group, recently posted an overview of one possible approach to creating a responsive navigation menu. Wachs’ solution is to convert the menu from a horizontal list to a drop-down list as the screen gets smaller, in the end moving the drop-down list underneath the site’s logo on very narrow screens (you can see a demo here).

The drop-down list is not the only option for dealing with a navigation menu in your responsive designs. Developer Brad Frost recently posted a great overview of responsive navigation patterns, offering up pros and cons of each approach. Along with the drop-down menu, Frost covers options like moving the navigation to the footer, hiding it behind a toggle button and of course, probably the most widespread option at the moment — doing nothing. The latter option works quite well for sites with only a few menu items, but quickly breaks down when navigation menus get more complex.

Along with Frost’s lists of pros and cons are plenty of screenshots demonstrating the trade offs inherent in each approach (bonus points to Frost for using screenshots from a wide range of mobile browsers, not just the iPhone or Android).

As with all things responsive at this point there is no one right answer to the question “how do I build a responsive navigation menu?” What works well for one site might well be disaster on your next project. Don’t be afraid to try out several approaches. And remember, these are exciting times; you’re not just building responsive websites, you’re part of a collective effort to create an entirely new visual vocabulary for flexible design.

Video: Inventing on Principle

We just had a moment similar to the time we first saw content-aware scaling in action, but this time it’s even better — we’ve seen the future of programming tools and it looks awesome.

Check out the video above of Bret Victor‘s recent talk, “Inventing on Principle.” Victor has worked on experimental UI concepts at Apple and also created the interactive data graphics for Al Gore’s book, Our Choice. The video above of Victor’s keynote at the Canadian University Software Engineering Conference, captures a wonderful talk on living your life based on principles, but for many developers what’s most arresting are the software development tools demoed.

Do your current tools suddenly feel incredibly outdated? Perhaps you thought you were using a well-tuned coding machine but suddenly realize you’re really just hitting two stones together? Thought so. Sadly, the apps demoed in the video aren’t available. That’s all right, though; it just means someone needs to build them. Be sure to let us know if you do.

Responsive Design Tricks: Fluid Typography With CSS 3

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.