Archive for the ‘UI/UX’ 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: UI/UX, Web Basics

Users Expect Websites to Load in the Blink of an Eye

Photo: tobias.munich/Flickr

Think your three-second page loads are “just fine”? Think again.

According to engineers at Google, even the blink of an eye — which takes around 400 milliseconds — is too long.

That’s the word from the New York Times, which makes an unusual foray into the world of web development with its article “For Impatient Web Users, an Eye Blink Is Just Too Long to Wait.”

Some web developers may remember the days of the two-second rule (and no, not the one that applies to dropping food on the floor). The established wisdom — well-tested at the time by usability experts like Jakob Nielsen and others — was that after two seconds the number of users willing to wait for your page to load dropped off significantly.

That rule still holds, it’s just the amount of time that’s changed. Nowadays, the Times claims, users drop off after a mere 400 milliseconds, and a difference in page load time of just 250 milliseconds is enough to convey a distinct advantage over your competitors.

It’s that last number that’s perhaps most interesting. Anyone who’s browsing the web via a 3G connection can tell you that if you’re only willing to wait 400 milliseconds for a page to load, you aren’t going to see much of the web. On mobile networks bandwidth constraints are even more of an issue than they were when the two-second maximum was popularized. Users seem to understand this, but they don’t see it as an excuse. Now, perhaps more than ever, slight differences in page load time can give your site a significant advantage over competitors, according to the Google and Microsoft engineers quoted in the Times piece.

In other words, users may still, in some circumstance, be willing a wait a second, but if your competitor’s page is even 250 milliseconds faster, you can kiss your users goodbye.

Don’t believe us? Head over to the Times article and see if Google’s engineers don’t convince you. When you’re done we’ve got a few tips on how to speed up your website and make sure that no one has the edge on you. Here are a few helpful articles from the Webmonkey archives:

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.

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: