Archive for the ‘UI/UX’ Category

File Under: UI/UX, Visual Design
May
21
2012

The Eephus League Magazine: Pitch-Perfect Web Design

By

The Eephus League Magazine: showing publishing pros how it's done.

Baseball season is already well under way, but it’s never too late for another site about America’s favorite pastime — especially when it’s as awesome as the beautiful Eephus League Magazine.

Even if you have no idea what the name means — and fear not, even some baseball fans aren’t familiar with the Eephus pitch since it isn’t throw much (though current Red Sox reliever Vicente Padilla has something like an Eephus pitch) — the site is well worth a visit for its gorgeous layout and design.

The Eephus League Magazine is written and produced by web designer Bethany Heck, but if the interface and navigation looks slightly familiar it’s probably because the underlying code is the work of Ian Coyle, creator of Nike’s Better World site, which we featured last year.

Since then Coyle has also released Edits Quarterly, an online magazine of photography and short films. Edits is what inspired Heck to put together The Eephus League Magazine. And it’s not hard to see why, with Edits Coyle managed to create something even the so-called pros of the magazine publishing world can’t seem to make — a digital magazine that doesn’t suck.

What makes Edits — and its offspring like Eephus — remarkable is that it manages to feel like reading a print magazine even though you’re really just scrolling down a webpage. For example, there are what you might call “pages” in Coyle’s design, but they aren’t simple skeuomorphs like you’ll find in e-readers. Instead the “pages” just serve to move you through the content and keep articles separate even as they are all together on one page. Scrolling remains vertical; there’s no awkward “page flipping” actions. The Eephus League Magazine uses Coyle’s JavaScript, so moving through it feels just like browsing Edits, but Heck has made a few adjustments to fit Eephus‘s own layout and images.

In the end the experience of both magazines is different enough to catch your eye, but not so much so that it overwhelms the content. But don’t take our word for it, head over to Eephus and be sure to check out Edits Quarterly as well.

Tags:
File Under: Programming, UI/UX, Web Basics
Mar
26
2012

Video: Progressive Enhancement 2.0

By

A webpage doesn’t have to look the same in every browser. In fact, a webpage shouldn’t look the same in every browser, according to former Yahoo developer and JavaScript guru, Nicolas Zakas.

Zakas, who spent five years as the front-end tech lead for the Yahoo homepage, recently spoke at the March BayJax Meetup group about what he calls Progressive Enhancement 2.0 — offering users the best possible experience given the capabilities of their device.

Not the same experience, mind you, but the best possible experience. That means progressively enhancing sites according to the device’s (browser’s) capabilities.

Progressive enhancement is perhaps best summed up by the famous Mitch Hedburg quip, “an escalator can never break, it can only become stairs.” In other words, if you’re building websites well they never break, even if you look at them in Lynx. The site may not look the same in Lynx as it does in, say Chrome, it may not function as smoothly, but the core content is still there and can still serve as a stairway that gets people where they want to go even when the enhanced ease of the escalator is absent.

More practically, progressive enhancement means starting with the least capable devices — an older phone, Lynx running on Windows 95 — and then adding more sophisticated features based on screen size, bandwidth and so on.

Zakas also takes on the common assumption that a web “page” is analogous to the printed page. In fact Zakas argues the web is more like television, which has a similar separation of content and device. In that analogy old browsers are like black and white TVs. No one expects a black and white TV to play HD content, but everyone would be disappointed if you served black and white content to an HD TV. Hence the need for progressive enhancement.

If you’re well versed in the history of the web the beginning of the video may be a bit slow, but stick with it. Also be sure to watch the questions at the end where Zakas addresses how to progressively enhance more application-like web pages.

Tags: ,
File Under: CSS, Mobile, UI/UX, Visual Design, Web Basics
Mar
14
2012

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

By

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:

Tags: ,
File Under: Programming, UI/UX, Visual Design
Mar
2
2012

Connect With Your Creation Through a Real-Time Editor

By

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.

Tags: ,
File Under: UI/UX, Web Basics
Mar
2
2012

Users Expect Websites to Load in the Blink of an Eye

By

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:

Tags:
« OLDER POSTS