All posts tagged ‘responsive design’

The Web Needs to Get Ready for the High-Resolution Future

The high-resolution retina display iPad has one downside — normal resolution images look worse than on lower resolution displays. On the web that means that text looks just fine, as does any CSS-based art, but photographs look worse, sometimes even when they’re actually high-resolution images.

Pro photographer Duncan Davidson was experimenting with serving high-resolution images to the iPad 3 when he ran up against what seemed to be a limit to the resolution of JPG images in WebKit. Serving small high-resolution images — in the sub-2000px range — works great, but replacing 1000px wide photographs with 2000px wide photos actually looks worse due to downsampling.

The solution (turns out) is to go back to something you probably haven’t used in quite a while — progressive JPGs. It’s a clever solution to a little quirk in Mobile Safari’s resource limitations. Read Davidson’s follow-up post for more details, and be sure to look at the example image if you’ve got a new iPad because more than just a clever solution, this is what the future of images on web will look like.

As Davidson says:

For the first time, I’m looking at a photograph I’ve made on a screen that has the same sort of visceral appeal as a print. Or maybe a transparency laying on a lightbox. Ok, maybe not quite that good, but it’s pretty incredible. In fact, I really shouldn’t be comparing it to a print or a transparency at all. Really, it’s its own very unique experience.

To show off the sample on his site Davidson uses a bit of JavaScript to toggle the high- and low-res images, highlighting the difference.

But how could you go about serving the higher res image to just those screens with high enough resolution and fast enough connections to warrant it?

You can’t.

So what’s a web developer with high-res images to show off supposed to do? Well, right now you’re going to have to decide between all or nothing. Or you can use a hack like one of the less-than-ideal responsive image solutions we’ve covered before.

Right now visitors with the new iPad are probably a minority for most websites, so not that many people will be affected by low-res or poorly rendered high-res images. But Microsoft is already prepping Windows 8 for high-res retina-style screens and Apple is getting ready to bring the same concept to laptops.

The high-res future is coming fast and the web needs to evolve just as fast.

In the long run that means the web is going to need a real responsive image solution; something that’s part of HTML itself. An new HTML element like the proposed <picture> tag is one possible solution. The picture element would work much like the video tag, with code that looks something like this:

 
  
  
 



The browser uses this code to choose which image to load based on the current screen width.

The picture element would solve one part of the larger problem, namely serving the appropriate image to the appropriate screen resolution. But screen size isn’t the only consideration; we also need a way to measure the bandwidth available.

At home on my Wi-Fi connection I’d love to get Davidson’s high-res images on my iPad. When I’m out and about using a 3G connection it would be better to skip that extra overhead in favor of faster page load times.

Ideally browsers would send more information about the user’s environment along with each HTTP request. Think screen size, pixel density and network connection speed. Developers could then use that information to make a better-informed guess about which images it to serve. Unfortunately, it seems unlikely we’ll get such tools standardized and widely supported before the high-res world overtakes the web. With any server-side solution to the bandwidth problem still far off on the horizon, navigator.connection will become even more valuable in the mean time.

Further complicating the problem are two additional factors, data caps on mobile connections and technologies like Apple’s AirPlay. The former means that even if I have a fast LTE connection and a high-resolution screen I still might not want to use my limited data allotment to download high-res images.

AirPlay means I can browse to a site with my phone — which would likely trigger smaller images and videos since it’s a smaller screen — but then project the result on a huge HD TV screen. This is not even a hypothetical problem, you can experience it today with PBS’s iPhone app and AirPlay.

Want to help figure out how the web needs to evolve and what new tools we’re going to need? Keep an eye on the W3C’s Responsive Images community group, join the mailing list and don’t be shy about contributing. Post your experiments on the web and document your findings like Davidson and countless others are already doing.

It’s not going to happen overnight, but eventually the standards bodies and the browser makers are going to start implementing solutions and the more test cases that are out there, the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.

Photo: Ariel Zambelich/Wired

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:

File Under: Browsers, Mobile

Adobe Shadow Simplifies Mobile Web Testing

Adobe Shadow makes it easy to test your site on multiple devices at the same time. Photo: Adobe

Adobe Labs has released Adobe Shadow, a new project that offers a simple way to test your websites on multiple devices at the same time.

To try out Adobe Shadow, head on over to Adobe Labs and grab the desktop app and Chrome browser plugin, along with the Android and iOS offerings.

If you’ve never tried testing your site simultaneously on multiple devices, the fact that Shadow consist of four separate apps should give you some idea of how difficult it generally is. Thankfully, once you have all the pieces installed, Shadow makes the rest of the testing process as simple as hitting refresh. In fact, much of the time you don’t even need to do that — Shadow will automatically mirror whatever you’re doing on the desktop to the rest of your connected devices.

Though it’s still a beta release, Shadow may well be the most useful thing Adobe has ever built for web developers, particularly those that have embraced responsive design. It’s no secret that, while responsive design allows developers to easily target a wide range of screen sizes, it adds a considerable amount of work to the development process. But with Shadow mirroring your website across dozens of devices at the same time, testing becomes simple and easy. It’s a bit like synchronized swimming for web browsers. You can even debug and make changes directly in Chrome and then see the results on each device. To get an idea of how Shadow works, check out this overview video from Adobe:

There are two small problems with Shadow. The primary problem is that Shadow will only test your site in WebKit mobile browsers. We’d hate to see Shadow become yet another reason for developers to ignore non-WebKit browsers. So, while Shadow is great, it won’t give you the whole picture right now.

The good news is that Shadow is a beta release and a work in progress. I spoke with Bruce Bowman, Senior Product Manager of Shadow and, while he stopped short of committing to anything, Bowman made it clear that Adobe plans to keep expanding Shadow’s capabilities as the project progresses.

The other problem with Shadow isn’t actually a problem with Shadow directly, but its usefulness is nevertheless directly related to the number of iOS and Android devices you have on hand. Obviously those that will benefit most from Shadow are large web development shops with the budget to invest in dozens of mobile devices. Shadow is no less handy for individual developers with only one or two devices, though the results are of course limited.

Should Shadow prove popular, perhaps it will help spur the sort of device swap gatherings we’ve heard mobile expert Peter Paul Koch suggest — a group of web developers pool their resources, bring together a wide range of mobile devices and take turns testing websites. Shadow could make that process considerably easier and faster thanks to its live editing capabilities.

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.

Building a Responsive, Future-Friendly Web for Everyone

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

This week’s Consumer Electronics Show in Las Vegas has seen the arrival of dozens of new devices from tablets to televisions. Some of these newfangled gadgets will soon be in the hands of consumers who will use them to access your website. Will your site work? Or will it end up mangled by a subpar web browser, odd screen size or slow network connection?

No one wants to rewrite their website every time a new device or browser hits the web. That’s why approaches like responsive design, and the even broader efforts of the future-friendly group, are trying to develop tools and techniques for building adaptable websites. That way, when a dozen new tablets suddenly appear on the scene, you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Even if you aren’t a gadget lover, CES should help drive home the fundamental truth of today’s web — devices, they are a comin’. Webmonkey has compiled helpful resources for creating responsive design in the past, but the field is new and evolving rapidly so here’s an updated list of links to help you get started responsive, future-friendly sites that serve your audience’s needs whether they’re browsing with a tiny phone, a huge television or the web-enabled toaster of tomorrow.

Basics:

  • 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 4-inch screens, one for 7-inch, one for 10-inch and one for desktop. Keep it liquid, otherwise what happens when the 11.4-inch screen 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. 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 screens. Similar techniques can be used to scale video.
  • Forget about perfect. If you haven’t already, abandon the notion of pixel perfect designs across devices. An iPad isn’t a laptop isn’t a television. Build the perfect site for each.

Further Reading:

  • Future Friendly — An overview of how some of the smartest people in web design are thinking about the ever-broadening reach of the web: “We can’t be all things on all devices. To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services. People are also increasingly tired of excessive noise and finding ways to simplify things for themselves. Focus your service before your customers and increasing diversity do it for you.”
  • Building a Future-Friendly Web — Brad Frost’s excellent advice: “Think of your core content as a fluid thing that gets poured into a huge number of containers.”
  • There is no mobile web — “There is no mobile web, nor desktop web. It is just the web. Start with the content and meet people halfway.”
  • Responsive by default — Andy Hume on why the web has always been responsive, but was temporarily sidetracked by the fad of fixed-width sites.
  • COPE: Create Once, Publish Everywhere — NPR’s Director of Application Development, Daniel Jacobson, walks through how NPR separates content from display and uses a single data source for all its apps, sites, APIs and feeds. A great example of what Frost talks about regarding content as a fluid thing.
  • Support Versus Optimization — It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers?
  • The Coming Zombie Apocalypse — Not satisfied thinking a few years ahead? Scott Jenson explores further into the future and tries to imagine what the web might look like when devices all but invisible.

Techniques: