Archives
Category Archive
for: ‘Smashing Magazine’

Keeping The Big <picture> Small: How To Avoid Duplicate Downloads In Responsive Images


  

The <picture> element is a new addition to HTML5 that’s being championed by the W3C’s Responsive Images Community Group (RICG). It is intended to provide a declarative, markup-based solution to enable responsive images without the need of JavaScript libraries or complicated server-side detection.

The <picture> element supports a number of different types of fallback content, but the current implementation of these fallbacks is problematic. In this article, we’ll explore how the fallbacks work, how they fail and what can be done about it.

The <picture> Element And Fallback Content

Like <video> and <audio>, <picture> uses <source> elements to provide a set of images that the browser can choose from. The <source> elements may optionally contain type and media attributes to let the browser know the file type and media type of the source, respectively. Given the information in the attributes, the browser should render the first <source> with a supported file type and matching media query. For example:


<picture>
    <source src="landscape.webp" type="image/webp" media="screen and (min-width: 20em) and (orientation: landscape)" />
    <source src="landscape.jpg" type="image/jpg" media="screen and (min-width: 20em) and (orientation: landscape)" />
    <source src="portrait.webp" type="image/webp" media="screen and (max-width: 20em) and (orientation: portrait)" />
    <source src="portrait.jpg" type="image/jpg" media="screen and (max-width: 20em) and (orientation: portrait)" />
</picture>

For situations in which a browser doesn’t know how to deal with <picture> (or <video> or <audio>) or cannot render any of the <source> elements, a developer can include fallback content. This fallback content is often either an image or descriptive text; if the fallback content is an <img>, then a further fallback is provided in the alt attribute (or longdesc), as normal.


<picture>
    <source type="image/webp" src="image.webp" />
    <source type="image/vnd.ms-photo" src="image.jxr" />
    <img src="fallback.jpg" alt="fancy pants">
</picture>

The <picture> element differs from <video> and <audio> in that it also allows srcset. The srcset attribute enables a developer to specify different images based on a device’s pixel density. When creating a responsive image using both <picture> and srcset, we might expect something like the following:


<picture>
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg 3x" type="image/jpeg" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" type="image/jpeg" />
    <img src="fallback.jpg" alt="fancy pants" />
</picture>

The idea behind a <picture> example like this is that exactly one image should be downloaded, according to the user’s context:

  • Users with <picture> support and a viewport at least 40 ems wide should get the big image.
  • Users with <picture> support and a viewport narrower than 40 ems should get the med image.
  • Users without <picture> support should get the fallback image.

If the browser chooses to display the big or med source, it can choose an image at an appropriate resolution based on the srcset attribute:

  • A browser on a low-resolution device (such as an iMac) should show the 1x image.
  • A browser on a higher-resolution device (such as an iPhone with a Retina display) should show the 2x image.
  • A browser on a next-generation device with even higher resolution should show the 3x image.

The benefit to the user is that only one image file is downloaded, regardless of feature support, viewport dimensions or screen density.

The <picture> element also has the ability to use non-image fallbacks, which should be great for accessibility: if no image can be displayed or if a user needs a description of an image, then a <p> or <span> or <table> or any other element may be included as a fallback. This allows for more robust and content-appropriate fallbacks than a simple alt attribute.

The Fallback Problem

Right now, the <picture> element is not supported in any shipped browsers. Developers who want to use <picture> can use Scott Jehl’s Picturefill polyfill. Also, Yoav Weiss has created a Chromium-based prototype reference implementation that has partial support for <picture>. This Chromium build not only shows that browser support for <picture> is technically possible, but also enables us to check functionality and behavior against our expectations.

When testing examples like the above in his Chromium build, Yoav spotted a problem: even though <picture> is supported, and even though one of the first two <source> elements was being loaded, the fallback <img> was also loaded. Two images were being downloaded, even though only one was being used.

This happens because browsers “look ahead” as HTML is being downloaded and immediately start downloading images. As Yoav explains:

“When the parser encounters an img tag it creates an HTMLImageElement node and adds its attributes to it. When the attributes are added, the node is not aware of its parents, and when an ‘src’ attribute is added, an image download is immediately triggered.”

This kind of “look ahead” parsing works great most of the time because the browser can start downloading images even before it has finished downloading all of the HTML. But in cases where an img element is a child of <picture> (or <video> or <audio>), the browser wouldn’t (currently) care about the parent element: it would just see an img and start downloading. The problem also occurs if we forget about the parent element and just consider an <img> that has both the src and srcset attributes: the parser would download the src image before choosing and downloading a resource from srcset.


<picture>
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg 3x" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" />
    <img src="fallback.jpg" alt="fancy pants" />
    <!-- fallback.jpg is *always* downloaded -->
</picture>

<img src="fallback.jpg" srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" alt="fancy pants" />
<!-- fallback.jpg is *always* downloaded -->

<video>
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <source src="video.ogv" type="video/ogg" />
    <img src="fallback.jpg" alt="fancy pants" />
    <!-- fallback.jpg is *always* downloaded -->
</video>

In all of these cases, we would have multiple images being downloaded instead of just the one being displayed. But who cares? Well, your users who are downloading extra content and wasting time and money would care, especially the ones with bandwidth caps and slow connections. And maybe you, too, if you’re paying for the bandwidth you serve.

A Potential Solution

This problem needs both short- and long-term solutions.

In the long term, we need to make sure that browser implementations of <picture> (and <video> and <audio>) can overcome this bug. For example, Robin Berjon has suggested that it might be possible to treat the contents of <picture> as inert, like the contents of <template>, and to use the Shadow DOM (see, for example, “HTML5’s New Template Tag: Standardizing Client-Side Templating”). Yoav has suggested using an attribute on <img> to indicate that the browser should wait to download the src.

While changing the way the parser works is technically possible, it would make the implementation more complicated. Changing the parser could also affect JavaScript code and libraries that assume a download has been triggered as soon as a src attribute is added to an <img>. These long-term changes would require cooperation from browser vendors, JavaScript library creators and developers.

In the short term, we need a working solution that avoids wasted bandwidth when experimenting with <picture> and srcset, and when using <video> and <audio> with <img> fallbacks. Because of the difficulty and time involved in updating specifications and browsers, a short-term solution would need to rely on existing tools and browser behaviors.

So, what is currently available to us that solves this in the short term? Our old friends <object> and <embed>, both of which can be used to display images. If you load an image using these tags, it will display properly in the appropriate fallback conditions, but it won’t otherwise be downloaded.

Different browsers behave differently according to whether we use <object>, <embed> or both. To find the best solution, I tested (using a slightly modified version of this gist) in:

  • Android browser 528.5+/4.0/525.20.1 on Android 1.6 (using a virtualized Sony Xperia X10 on BrowserStack)
  • Android browser 533.1/4.0/533.1 on Android 2.3.3 (using a virtualized Samsung Galaxy S II on BrowserStack)
  • Android browser 534.30/4.0/534.30 on Android 4.2 (using a virtualized LG Nexus 4 on BrowserStack)
  • Chrome 25.0.1364.160 on OS X 10.8.2
  • Chromium 25.0.1336.0 (169465) (RICG Build) on OS X 10.8.2
  • Firefox 19.0.2 on OS X 10.8.2
  • Internet Explorer 6.0.3790.1830 on Windows XP (using BrowserStack)
  • Internet Explorer 7.0.5730.13 on Windows XP (using BrowserStack)
  • Internet Explorer 8.0.6001.19222 on Windows 7 (using BrowserStack)
  • Internet Explorer 9.0.8112.16421 on Windows 7 (using BrowserStack)
  • Internet Explorer 10.0.9200.16384 (desktop) on Windows 8 (using BrowserStack)
  • Opera 12.14 build 1738 on OS X 10.8.2
  • Opera Mobile 9.80/2.11.355/12.10 on Android 2.3.7 (using a virtualized Samsung Galaxy Tab 10.1 on Opera Mobile Emulator for Mac)
  • Safari 6.0.2 (8536.26.17) on OS X 10.8.2
  • Safari (Mobile) 536.26/6.0/10B144/8536.25 on iOS 6.1 (10B144) (using an iPhone 4)
  • Safari (Mobile) 536.26/6.0/10B144/8536.25 on iOS 6.1 (10B141) (using an iPad 2)

I ran five tests:

  1. <picture> falls back to <object>
  2. <picture> falls back to <embed>
  3. <picture> falls back to <object>, which falls back to <embed>
  4. <picture> falls back to <object>, which falls back to <img>
  5. <picture> falls back to <img>

I found the following support:

What the user sees
Test 1 Test 2 Test 3 Test 4 Test 5
Android 1.6 fallback image fallback image fallback image fallback image fallback image
Android 2.3 fallback image fallback image fallback image fallback image fallback image
Android 4.2 fallback image fallback image fallback image fallback image fallback image
Chrome 25 fallback image fallback image fallback image fallback image fallback image
Chromium 25 (RICG) picture/source image picture/source image picture/source image picture/source image picture/source image
Firefox 19 fallback image fallback image fallback image fallback image fallback image
IE 6 no image no image no image no image fallback image
IE 7 no image no image no image no image fallback image
IE 8 fallback image no image fallback image fallback image fallback image
IE 9 fallback image fallback image (cropped and scrollable) fallback image fallback image fallback image
IE 10 fallback image fallback image (cropped and scrollable) fallback image fallback image fallback image
Opera 12.1 fallback image fallback image fallback image fallback image fallback image
Opera Mobile 12.1 fallback image fallback image fallback image fallback image fallback image
Safari 6 fallback image fallback image fallback image fallback image fallback image
Safari iOS 6 (iPad) fallback image fallback image fallback image fallback image fallback image
Safari iOS 6 (iPhone) fallback image fallback image fallback image fallback image fallback image
HTTP requests
Test 1 Test 2 Test 3 Test 4 Test 5
Android 1.6 1 GET 1 GET 1 GET 2 GETs 1 GET
Android 2.3 1 GET 1 GET 1 GET 2 GETs 1 GET
Android 4.2 1 GET 1 GET 1 GET 2 GETs 1 GET
Chrome 25 1 GET 1 GET 1 GET 2 GETs 1 GET
Chromium 25 (RICG) 1 GET 1 GET 1 GET 2 GETs 2 GETs
Firefox 19 1 GET 1 GET 2 GETs 2 GETs 1 GET
IE 6 1 GET none 1 GET 1 GET 1 GET
IE 7 1 GET none 1 GET 1 GET 1 GET
IE 8 1 GET none 1 GET 1 GET 1 GET
IE 9 1 HEAD, 1 GET 1 GET 1 HEAD, 1 GET 1 HEAD, 2 GETs 1 GET
IE 10 1 HEAD, 1 GET 1 GET 1 HEAD, 1 GET 1 HEAD, 2 GETs 1 GET
Opera 12.1 1 GET 1 GET 1 GET 2 GETs 1 GET
Opera Mobile 12.1 1 GET 1 GET 1 GET 2 GETs 1 GET
Safari 6 1 GET 1 GET 1 GET 2 GETs 1 GET
Safari iOS 6 (iPad) 1 GET 1 GET 1 GET 2 GETs 1 GET
Safari iOS 6 (iPhone) 1 GET 1 GET 1 GET 2 GETs 1 GET
Image-aware context menu
Test 1 Test 2 Test 3 Test 4 Test 5
Android 1.6 yes yes yes yes yes
Android 2.3 yes yes yes yes yes
Android 4.2 yes yes yes yes yes
Chrome 25 no no no no yes
Chromium 25 (RICG) no no no no no
Firefox 19 yes yes yes yes yes
IE 6 no no no no yes
IE 7 no no no no yes
IE 8 yes no yes yes yes
IE 9 yes yes yes yes yes
IE 10 yes yes yes yes yes
Opera 12.1 yes yes yes yes yes
Opera Mobile 12.1 yes no yes yes yes
Safari 6 no no no no yes
Safari iOS 6 (iPad) no no no no yes
Safari iOS 6 (iPhone) no no no no yes

Making Sure The Content Is Accessible

Although the specifics of how to provide fallback content for <picture> are still being debated (see also this thread), I wanted to test how Apple’s VoiceOver performed with different elements. For these experiments, I checked whether VoiceOver read alt attributes in various places, as well as fallback <span> elements. Unfortunately, I wasn’t able to test using other screen readers or assistive technology, although I’d love to hear about your experiences.

Read by VoiceOver
alt on picture alt on source (picturesource) alt on object (pictureobject) alt on embed (pictureembed) alt on embed (pictureobjectembed)
Chrome 25 no no yes yes no
Chromium 25 (RICG) yes no no no no
Firefox 19 no no yes yes no
Opera 12.1 no no no no no
Safari 6 no no yes yes no
Safari iOS 6 (iPad) no no yes yes no
Safari iOS 6 (iPhone) no no yes yes no
Read by VoiceOver
alt on img (pictureobjectimg) alt on img (pictureimg) span (picturespan) span (pictureobjectspan)
Chrome 25 no yes yes no
Chromium 25 (RICG) no no no no
Firefox 19 no yes yes no
Opera 12.1 no no yes no
Safari 6 no yes yes no
Safari iOS 6 (iPad) no yes yes no
Safari iOS 6 (iPhone) no yes yes no

Bulletproof Syntax

Based on these data, I’ve come up with the following “bulletproof” solution:


<picture alt="fancy pants">
    <!-- loaded by browsers that support picture and that support one of the sources -->
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg" type="image/jpeg" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, big-3x.jpg" type="image/jpeg" />

    <!-- loaded by IE 8+, non-IE browsers that don’t support picture, and browsers that support picture but cannot find an appropriate source -->
    <![if gte IE 8]>
    <object data="fallback.jpg" type="image/jpeg"></object>
    <span class="fake-alt">fancy pants</span>
    <![endif]>

    <!-- loaded by IE 6 and 7 -->
    <!--[if lt IE 8]>
    <img src="fallback.jpg" alt="fancy pants" />
    <![endif]-->
</picture>

.fake-alt {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

Here we have a <picture> element, two sources to choose from for browsers that support <picture>, a fallback for most other browsers using <object> and a <span> (see note just below), and a separate <img> fallback for IE 7 and below. The empty alt prevents the actual image from being announced to screen readers, and the <span> is hidden using CSS (which is equivalent to HTML5 Boilerplate’s .visuallyhidden class) but still available to screen readers. The <embed> element is not needed.

(Note: The use of the <span> as a fake alt is necessary so that VoiceOver reads the text in Opera. Even though Opera has a relatively small footprint, and even though it’s in the process of being switched to WebKit, I still think it’s worth our consideration. However, if you don’t care about supporting that particular browser, you could get rid of the <span> and use an alt on the <object> instead (even though that isn’t strictly allowed by the specification). This is assuming that the <span> and alt have the same content. If you have a richer fallback element, such as a <table>, using both it and a non-empty alt attribute might be desirable.)

A similar solution should also work with <audio>, although <img> fallbacks for that element are, admittedly, rare. When dealing with <video>, the problem goes away if our fallback image is the same as our poster image. If these may be the same, then the “bulletproof” syntax for <video> would be this:


<video poster="fallback.jpg">
    <!-- loaded by browsers that support video and that support one of the sources -->
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <source src="video.ogv" type="video/ogg" />

    <!-- loaded by browsers that don't support video, and browsers that support video but cannot find an appropriate source -->
    <img src="fallback.jpg" alt="fancy pants" />
</video>

However, if your <video> needs a separate fallback and poster image, then you might want to consider using the same structure as the <picture> solution above.

Note that <video> and <audio> don’t have alt attributes, and even if you add them, they will be ignored by VoiceOver. For accessible video, you might want to look into the work being done with Web Video Text Tracks (WebVTT).

Unfortunately, extensive testing with <video> and <audio> elements is beyond the scope of this article, so let us know in the comments if you find anything interesting with these.

How Good (Or Bad) Is This Solution?

Let’s get the bad out of the way first, shall we? This solution is hacky. It’s obviously not workable as a real, long-term solution. It is crazy verbose; no one in their right mind wants to code all of this just to put an image on a page.

Also, semantically, we really should use an <img> element to display an image, not an <object>. That’s what <img> is for.

And there are some practical issues:

  • Chrome and Safari won’t show proper context menus for the images, meaning that users won’t be able to open or save them easily.
  • IE 9 and 10 send an extra HEAD request along with the GET request.
  • Using a <span> as a fake alt is pretty sketchy, and although it worked for my tests in VoiceOver, it could potentially cause other accessibility problems.

All that being said, as a short-term solution, it’s not too bad. We get these benefits:

  • A visible image in every browser is tested (<picture> and <source> when supported, and the fallback otherwise).
  • Only one HTTP GET request in every browser is tested (and the extra HEAD request and response in IE are tiny).
  • VoiceOver is supported (and is hopefully supported with other screen readers).

<!-- show screenshot of network pane here -->

The semantics of the solution, while not ideal, are not horrible either: the HTML5 specification states that an <object> “element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin” (emphasis mine).

And although the <span> is not as nice as a real alt attribute, using a visually hidden element for accessibility is not uncommon. Consider, for example, “Skip to content” links that are visibly hidden but available to screen readers.

Next Steps

The best part about this solution, though, is that it highlights how bad the current situation is. This is a real problem, and it deserves a better solution than the monstrosity I’ve proposed.

We need discussion and participation from both developers and browser vendors on this. Getting support from browser makers is crucial; a specification can be written for any old thing, but it doesn’t become real until it is implemented in browsers. Support from developers is needed to make sure that the solution is good enough to get used in the real world. This consensus-based approach is what was used to add the <main> element to the specification recently; Steve Faulkner discusses this process a bit in his excellent interview with HTML5 Doctor.

If you’re interested in helping to solve this problem, please consider joining the discussion:

The next step towards a long-term solution is to achieve consensus among developers and browser vendors on how this should work. Don’t get left out of the conversation.

Thanks to fellow RICG members Yoav Weiss, Marcos Cáceres and Mat Marquis for providing feedback on this article.

(al)


© David Newton for Smashing Magazine, 2013.

Continue reading

Read More

Interview: How I Work: IDEO’s Duane Bray On Creating Great Digital Experiences


  

Welcome to another interview in the series called “How I Work.” These interviews revolve around how leading thinkers and creators in the Web world design, code and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), but rather step back and learn a bit about their habits, philosophies and workflow for producing great work.

You might want to have a look at the first interview as well, which features Doug Crockford, Yahoo’s JavaScript evangelist.

Today we’ll talk to Duane Bray from IDEO, a firm that is consistently listed as one of the world’s most innovative companies due to its uncanny ability to constantly come up with great ideas for its clients. Duane Bray is a partner at IDEO and heads up the firm’s digital business from its New York City office.

Duane Bray at IDEO's New York City office
Duane Bray at IDEO’s New York City office.

Like all IDEOers you meet, Duane Bray is unfailingly nice, with a soft, well-spoken voice. He reminds you of the kid in the back of algebra class doodling away during lecture and still acing the tests.

We recently sat down with Duane over a couple sessions to get his thoughts on Agile development, how you too can gather great user insights, tips for prototyping digital projects with clients and why he still sketches interfaces out on paper.

Q: What has you excited about digital work these days?

Duane: I’m particularly excited about the movement away from standards-based specifications towards real stuff. For us, we’ve been doing a lot more experimentation around Agile development processes and pairing up designers and developers side by side throughout the process from day one. The last thing you want to do is hire a designer who is really talented at conceptual thinking and say, “Okay, now you’re going to spend six weeks documenting everything with InDesign for the thing you did.”

What’s funny though, is when you have a designer working with a developer on weekly builds, all that stuff still gets done. But from the designer’s perspective, they are constantly making. We’ve found our teams to be super excited to be working in this way.

Certainly we’re not the first to discover Agile, but it’s made a big difference in our culture because we want people to get their ideas as real and tangible as soon as possible.

Q: How does IDEO go about getting big, breakthrough insights?

Duane: Well, for a lot of our clients, they come to us with these sort of vague questions, and they want us to help them figure that out. So, we want to start off by making sure we’re a bit exploratory — and that involves going out and being inspired by behaviors.

For example, there might be a question around new forms of video consumption online. We want to go out and find people that are representative of some extreme form of behavior. This helps us get inspired and further shapes our strategy.

One woman we found has two computers at work. One is displaying her work and the other one is displaying reality television. She needs both streams to do her job. The interesting thing is you can almost hit pause and ask her what’s going with the show and with her work and she can answer both.

So it starts to suggest, what are some of the interesting forms of literacy that are coming through our digital tools? And how might we design for this? Are there new mental models we haven’t thought about before, rather than going with industry standards?

A brainstorming session at IDEO
A brainstorming session at IDEO.

Q: IDEO is famous for “thinking with your hands” via prototypes — how do you transfer this over to digital?

Duane: For me I don’t see any distinction in how IDEO designs digital products compared to our other products. We’re still going to get out there and be inspired by what’s going on in the world.

We always start our projects with some sort of investigation into what are people doing and how it impacts how they’re going to engage. And we get tangible quickly — and it’s not so very different from any other prototyping process. We do group sessions to generate ideas, we sketch together, we might have someone make a mock-up on a phone or tablet to test out a behavior. What’s most important for a prototype is to choose the right fidelity for the question you’re seeking to answer.

Q: What’s this discovery process look like?

Duane: Sometimes we’ll prototype something in the browser or on mobile to test some of these concepts out. We’ll also play around with paper prototypes because it’s an appropriate way to get client input.

But I like to find ways to disrupt the conversation when we’re talking with consumers.

For example, if something is very polished, consumers will feel they have to say they like it because it’s polished. So sometimes having hand-sketches, along with something on an iPad, we’re able to get very nice conversations going.

Prototyping is about blending that low-fidelity and high-fidelity process and blending our thinking as we go along.

Q: How would you make a case to a Smashing Magazine reader for adopting a prototyping process with their clients?

Duane: Well, the client is going to be in a better position to make more informed decisions because they are seeing things that are real. I would also argue that it isn’t a massive investment anyway and there is a better payoff down the road because you’re getting more real (tangible) early on — which means you’re going to get better input from users.

Imagine not going through that process: doing a bunch of sketches, building out a spec document, a developer builds it, you test it and people hate it.

At that point there has been such a huge investment in producing that thing. So there is actually a lot of emotional attachment now and it’s either going to be financially impossible to correct it or people will be too wedded to the idea and it’s going to be impossible to change.

Q: How do you show these prototypes?

Duane: We do a lot of live work. We’ll recruit a panel of end users. Particularly in the early stages when we’re looking for inspiration, we’ll want to be in their (the users’) context. So instead of bringing them into a focus group, we might go into their homes or offices and observe them. We’ll also put stuff up on the web and blast out an SMS message and ask people to interact so we can get a more broad approach as well.

Sometimes we’ll do a hybrid of both and have our developers do quick builds and mock-ups and then go back out into the field to get more insights with a select group.

We want to know less about what percentage of people clicked on this or dropped off and more about their process of going through and using that experience. What are the specific things that are barriers and why?

At some point, when we have a much more robust build, then we’ll push it out to more people. So there is definitely an interim phase. We tend to start high touch and stay that way for a while. We’re looking for finding the emotions around why people engage or why they don’t. If we understand those, it becomes a lot more powerful in how we tune the tools.

Q: What’s your experience been with Agile Development processes?

Duane: One of the things we’ve found when we’re working in an Agile process is that we can actually be incredibly fast.

An iPhone app that IDEO created for Lincoln Center.
An iPhone app that IDEO created for Lincoln Center.

To give you an example, we did a project here in New York for Lincoln Center, which was their first iPhone app, and we ran it as an Agile process. We went from kick-off to an app in the iTunes store in eight weeks. That’s concept, design and build (and I wouldn’t want to claim we can do every project on that timeline). But we had an amazing client that was able to make decisions very quickly, so we had a fast turnaround time there.

But again, it was because we were getting very real, very fast.

Q: Can you give us a step-by-step breakdown for creating this app in only eight weeks using Agile?

Duane: Sure. First, we spent half a day with our designers and developers at Lincoln Center’s campus, and in advance we created briefs about what an app could look like around different themes. We broke up into teams and every group had to go and interview people at Lincoln Center and talk to them about the theme and do a tour themselves.

We had clipboards of iPhone screen printouts, and they (the teams) had to sketch an experience and get feedback — all in four hours. It was a great way to get immersed: we talked to security guards, out-of-town tourists, locals who would hang out there, people at the information desk and we got a ton of insights.

So, we had all these amazing stories to go back and work with for honing our hypothesis on what this experience should be and we started building it. We did a detailed sketch session, prioritized the feature set, mapped out the flow, did some wireframes and then did a planning session with our development team (from Pivotal Labs). The project was so fast; there were literally just screenshots on the iPhone to simulate the flow. We were sharing it with people quickly and got to the stage where there was a build a week.

Screenshots of the iPhone app that IDEO created for Lincoln Center.
Screenshots of the iPhone app that IDEO created for Lincoln Center.

But the reality about that process is that you couldn’t do waterfall in eight weeks. I would say it’s more efficient than an old-fashioned step process.

Agile has been around for 20+ years, and we’re certainly not the first to discover it but now it’s finally getting traction. Designers and developers want to spend time making stuff and getting it out there and this process is all about that.

Q: What habits or hang-ups do you see in great web designers and developers?

Duane: Well, one of the things I think that is probably the most challenging for working in this more iterative, rapid-fire way is the ability to be more open and transparent with the work that you’re doing. Sometimes as designers we want to spend some time crafting, hiding in a corner and sketching and then do the “ta-da!” But some of this new way of working requires us to move beyond that.

One of the things I’ve been thinking about is how do you encourage greater transparency of work that’s in progress? We’ve been prototyping with tools like Flowdock that allows for conversation to sit around the workflow. That is particularly important, if we’re talking about getting stuff out there really early. These are the certain things that aren’t to the nature to how a designer is trained.

There is also this thing about great developers having curiosity. Being curious about the end user you’re designing for and involving the developers in that process for insights. Being able to imagine if they’ll use the thing you’re making.

Some folks are really natural at that, and in other cases it takes a lot of work. But I think that’s where we’re going — working off of blended teams with people of different skill sets.

Q: Any tips on how a small shop can get similar disruptive insights like IDEO does?

Duane: As designers it’s easy to get blinders on because we know what we know and it’s easy to get caught up in it. So, take some time to start over like you’ve never done this before. Sign up for some new tools and track your progress and behavior as an end user. There is something about just getting out to find inspiration. Look for stuff going on, whether it’s a related conference or just inviting in some experts to talk over wine and cheese at your office.

Even a small shop can reach out to friends of friends and watch them interact with some early prototypes or simply have a conversation. Say you’ll buy them drinks every other week and just show them stuff and see what you can learn from building that into your process.

One thing I do is have a screen on my phone that is just apps I would never normally download. So, we might be doing a project around, say, video, and I’ll go try every app out there and use this as a great way to learn. Projects are often an opportunity to dive deeper into a subject area you’re not necessarily interested in but you could be super-inspired by it.

Q: Now how do you capture those inspirations?

Duane: I usually have my notebook open as I’m using all these apps and I’m sketching out ideas and patterns. You start to get a feel for trends and think about different ways to accomplish the same task.

Sketchnotes in Duane Bray's notebook.
Sketchnotes in Duane Bray’s notebook.

Q: Where and how do you do your best work and not get burned out?

Duane: I usually get away from my desk. I’ll go sit up front on the couch with my laptop and my sketchbook. I force myself to move around. If you just sit at your desk you’re inclined to get into bad habits because everything is sitting around you. Some people have the zero inbox but I have 35,000 messages, so I just use the search box in email.

I’m someone who runs on intuition and not organizational processes. I have a thousand sticky notes on my desk.

But I’m pretty rigid about taking weekends off. I wasn’t always this way but I’ve learned that by being open to being inspired by stuff that has nothing to do with what I’m working on is really important.

Otherwise, you’re not grounded enough to bring something original to the table.

(cp) (ea)


© Jacob Cook for Smashing Magazine, 2013.

Continue reading

Read More

Infinite Scrolling: Let’s Get To The Bottom Of This


  

Infinite scrolling promises a better experience for users. However, the good is often accompanied by the bad and the ugly. Once we understand the strengths and weaknesses of infinite scrolling, we can begin to use it to enhance our interfaces.

Human nature demands hierarchy and structures that are easy to navigate. But infinite scrolling sometimes leaves users feeling disoriented as they travel down a page that never ends.

The NeverEnding Scroll

The Good

Long lists are not new, but the way in which we scroll these lists has fundamentally changed since the arrival of mobile interfaces. Due to the narrowness of mobile screens, list items are arranged vertically, requiring frequent scrolling.

Infinite scrolling is highly trending as an interaction behavior on pages and lists. The basic functionality is that, as the user scrolls through content, more content is loaded automatically. With the popularity of social media, massive amounts of data are being consumed; infinite scrolling offers an efficient way to browse that ocean of information, without having to wait for pages to preload. Rather, the user enjoys a truly responsive experience, whatever device they’re using.

Pagination vs. Infinite Scroll
Pagination versus infinite scrolling (Large version)

Websites with lots of user-generated content today are using infinite scrolling to handle content that is being generated every second. By unspoken agreement, users are aware that they won’t get to see everything on these websites, because the content is updated too frequently. With infinite scrolling, social websites are doing their best to expose as much information as possible to the user.

Twitter integrates infinite scrolling effectively. Its feed fits the criteria: a large amount of data (tweets) and a real-time platform. From the perspective of the user, all tweets are equally relevant, meaning that they have the same potential to be interesting or uninteresting; so, users will often scroll through all of the tweets in their feed. Being a real-time platform, Twitter is constantly being updated, even if the user leaves their feed unattended. Infinite scrolling seems to have been created especially for websites like Twitter, which successfully employs the technology.

Infinite scrolling appears to have found its niche on the Web. However, there are also drawbacks that must be considered before assessing its value.

The Bad And The Ugly

With so much data to browse, users must stay focused on the information they are searching for. (Remember about being goal-oriented?) Do users always want a never-ending stream of data? Analytics show that when users search for information on Google, only 6% advance to the second page. So, 94% of users are satisfied with receiving only 10 results, which suggests that users find Google’s ranking of results to be relevant.

To Click or Not to Click

Google has implemented infinite scrolling for image search results but has yet to implement it for its general results. Doing so would eliminate the need for users to click to reach the second page. Google will probably maintain pagination because this pattern is quite symbolic for its brand. If it does switch to infinite scrolling, when would users typically stop scrolling? After 20 results? 50? When does an easy browsing experience become more complicated?

Looking for the best search result could take a second or an hour, depending on your research. But when you decide to stop searching in Google’s current format, you know the exact number of search results. You can make an informed decision about where to stop or how many results to peruse because you know where the end is. According to studies conducted in the field of human-computer interaction, reaching an end point provides a sense of control; you know that you have received all relevant results, and you know whether the one you are looking for is there or not. Knowing the number of results available provides a sense of control and helps the user make a more informed decision, rather than be left to scour an infinitely scrolling list.

Pagination: The Click Barrier
Pagination is a barrier of clicks. (Large version)

When items are distributed across Web pages, they are framed and indexed and have a start and end point. The information is presented clearly and orderly. If we select an item from a paginated list and are taken from that page, we know that clicking “Back” will return us to that page (probably to the same scroll position). Our Web search will continue right where it left off.

If you scroll the same list of results with infinite scrolling, you are left without that sense of control because you are scrolling through a list that is conceptually infinite. Let’s say you count yourself among the 94% who stop reading after the first page (i.e. 10 results) of a Google search. When the list scrolls infinitely, there is essentially no end to the first page. Rather than look for the end of the page, which doesn’t exist anyway, you decide to stop scrolling at the 10th item. This poses a problem with infinite scrolling, because the 11th item is directly in sight. With a paginated list, on which you wouldn’t see the 11th result, deciding not to continue browsing is easier. However, when the next results are already there, you’d probably just keep on scrolling and scrolling.

As Dmitry Fadeyev points out:

“People will want to go back to the list of search results to check out the items they’ve just seen, comparing them to what else they’ve discovered somewhere else down the list. Having a paginated interface lets the user keep a mental location of the item. They may not necessarily know the exact page number, but they will remember roughly what it was, and the paginated links will let them get there easier.

Not only does the infinite scroll break this dynamic, it also makes it difficult to move up and down the list, especially when you return to the page at another time and find yourself back at the top, being forced to scroll down the list once again and wait for the results to load. In this way the infinite scroll interface is actually slower than the paginated one.”

— Dmitry Fadeyev, When Infinite Scroll Doesn’t Work

When Infinite Scrolling Fails

The best companies are constantly testing and studying new interactions with their users. Increasing numbers of these studies are showing that infinite scrolling does not resonate with users if it does not support their goal on the website.

Temptation

When you’re looking for that perfect search result and are tempted to continue scrolling into a wasteland of irrelevant results, time is wasted. Chances are that the best result will appear in the first 10 items. Therefore, infinite scrolling merely tempts you to continue reading, wasting time and decreasing productivity in the process.

Optimism

Even more annoying is that scroll bars do not reflect the actual amount of data available. You’ll scroll down happily assuming you are close to the bottom, which by itself tempts you to scroll that little bit more, only to find that the results have just doubled by the time you get there.

Exhaustion

Infinite scrolling overwhelms users with stimuli. Like playing a game that you can never win, no matter how far you scroll, you feel like you’ll never get to the end. The combination of temptation and optimism play a big role in exhausting the user.

Pogosticking

Infinite scrolling often causes your position on the page to get lost. “Pogosticking” happens when you click away from an infinitely scrolling list and, when you return by clicking “Back,” are brought to the top of the previous page, instead of to the point where you left off. This happens because the scroll position is lost when you navigate away from an infinitely scrolling page, forcing you to scroll back down each time.

Loss of Control

Infinite scrolling leaves you with the feeling that you might be missing out on information. You continue scrolling because the results are right there, but you feel overwhelmed because you’re losing control over the amount of data being shown. There is something nice about defined pages on which the amount of content is quantified, where you can comfortably choose whether to click to view more or to stop. With infinite scrolling, you don’t have control over the amount of data on the page, which becomes overwhelming.

Distracting

Etsy, the vintage e-commerce marketplace, implemented infinite scrolling, only to find that it led to fewer clicks from its users. Infinite scrolling was unsuccessful because users felt lost in the data and had difficulty sorting between relevant and irrelevant information. While infinite scrolling provided faster and more results, users were less willing to click on them, defeating its very purpose.

Etsy's Home Page
Etsy’s home page (Large version)

Unreachable

Have you tried reaching the footer of Facebook lately? The footer block exists below the news feed, but because the feed scrolls infinitely, more data gets loaded as soon as you reach the bottom, pushing the footer out of view every time. Footers exist for a reason: they contain content that the user sometimes needs. In Facebook’s case, the user can’t reach it. The links are repeated elsewhere but are harder to find. Infinite scrolling impedes the user by making important information inaccessible.

Facebook auto-loading News Feed and the unreachable footer
Facebook’s auto-loading news feed makes the footer unreachable. (Large version)

Footers serve as a last resort. If users can’t find something or they have questions or want more information or explanation, they often go there. If they don’t find it there, they might leave the website altogether. Companies that implement infinite scrolling should either make the footer accessible by making it sticky or relocate the links to a sidebar.

Not Exclusive

Pinterest does not have a footer at all, which makes sense given the problem we just saw with Facebook. Through infinite scrolling, Pinterest emphasizes its profusion of data, an endless sea of inspiration taken from all over the Web.

Pinterest Ocean of Pins
Pinterest’s ocean of pins (Large version)

Images are faster and easier to scroll than text, so Pinterest and Google Images succeed with infinite scrolling to an extent. However, billions of images are on the Web, and users would prefer to see only the best of them. There is something to be said for exclusivity, which seems to be lacking in Pinterest’s layout.

Limiting the number of images on Pinterest’s home page, with an “Editor’s picks” or “Most popular” list, might make the website more appealing. How exclusive can a pin be when a ton of other similar pins are next to it?

Pinterest’s tactic of using infinite scrolling for its plethora of data suffers because it overwhelms users. The collection looks bottomless, but its immensity is somewhat daunting, and browsing it might seem a waste of time. Ultimately, Pinterest is trying to expose users to infinite inspiration, but that actually undermines the human need for control. The amount of data becomes intimidating, and users are left with mixed feelings.

When Usability Wins

As mentioned earlier, Twitter integrates infinite scrolling effectively. The user sees an infinitely growing list of tweets and can comfortably click on a tweet to expand it in place, preventing the page from refreshing and, as a result, maintaining their scroll position.

Twitter's torn feed
Twitter’s torn feed (Large version)

On its mobile version, Twitter even adds a “torn paper” marker, indicating to the user where to resume reading. This subtle and simple solution enables the user to scroll up and down the list, while having a recognizable point to return to. Psychologically, that marker reassures the reader by dividing read and unread content. Such markers give the user a sense of control and a better perception of the content’s depth and how far they’ve gotten into it.

Twitter is not the only one. Discourse, an emerging discussion platform, also has infinite scrolling that empowers the user. The company considered the importance of infinite scrolling to its user experience and implemented an intriguing and unique progress indicator. The indicator appears when needed and remains in view (without interfering) while the user reads the content. The indicator numbers the item currently being viewed out of the total number of items. This is a great way to make the user feel in control, even with a lot of data.

Smart progress indicator on Discourse.com
The smart progress indicator on Discourse (Large version)

Go Hybrid

A hybrid of infinite scrolling and pagination is also a good option in many cases. With this solution, you would show a “load more” button at the end of a preloaded list, which, when clicked, loads another batch of items onto the list. The same behavior that infinite scroll does automatically, this button does on demand. The interface gains some of the advantages of infinite scrolling, without some of its drawbacks.

Because infinite scrolling requires the website to fetch so much content, the hybrid solution is used at times to control the data load. In Facebook’s news feed and Google’s image search, the infinite scrolling is automatic at first but becomes on-demand once a certain number of items have loaded. This maintains the interface while limiting the load on the server.

Hybrid Infinite Pagination on Google Images
Hybrid infinite pagination on Google Images (Large version)

Infinite Pages

Infinite pages take the concept of infinite scrolling to a new level. Websites that employ this concept are “one-pagers.” To remove the barrier of clicking to the next page, the designer turns the entire website into one long scrollable page. Examples are Unfold and Lost World’s Fairs.

On these one-page websites, the sections are spread vertically, one after another. This makes the whole website less comprehensible — hence, less accessible. These websites might not have infinite scrolling, but the user might still have that feeling of a never-ending page.

On infinite pages, the height of each section will vary according to its contents. Although the approach can make for some creative interactions, it can leave users disoriented and unsure where to scroll for the next piece of information. The scroll bar is hidden on many such pages, leaving users feeling lost as they unconsciously look for the scroll position to track their progress. Hidden scroll bars deprive users of that chance for rescue. Users shouldn’t be left helpless; the interface should clearly show them how to navigate the page.

Infinite Page
Not knowing where they stand can leave the users disoriented.

UX engineers need to take extra care when designing infinite pages. They must take into account accessibility; tell users where they stand by showing the length of the page and how much they’ve viewed. Solutions could include a fixed menu, a map of the page or a scroll progress bar.

Another trick is the parallax effect, whereby different layers on the page move at different speeds according to the user’s scrolling, creating the illusion of depth (as seen on Andrew McCarthy’s website). While it can help to create beautiful and innovative experiences, it is sometimes heavily overused, and users can get confused by how much they need to scroll for more content. When the parallax effect is combined with animation, the user can get confused about whether the page is being scrolled by their movement or is moving autonomously. It’s wise to use the technique to enhance content, not as the content itself.

Let’s Get To The Bottom Of This

Infinite scrolling can be an innovative feature that greatly improves an interface by exposing content and making performance more efficient. But it needs to be used correctly.

Avoid the following sinkholes to achieve a strong infinite scrolling experience:

  • Users want immediate access to exclusive data.
    Users don’t want to be left to explore all of a website’s data on their own. When implementing infinite scrolling, identify what data is exclusive to your website and elevate it to the top of the page, and filter less relevant information.
  • Users want to feel in control.
    Infinite scrolling sabotages that feeling of control. Add a smart progress indicator, a fixed menu or a map.
  • Users often look for landmarks when scrolling.
    When scrolling through long lists, users expect to be able to easily distinguish between new and viewed data. Add landmarks along the interface to keep users oriented.
  • Consider conventional pagination or a hybrid solution.
    Good old pagination is always an alternative to infinite scrolling. And if that doesn’t fit the context, then a hybrid solution, using a “load more” button, could greatly enhance the interface.
  • Provide interesting content without an ambiguous interface.
    Having to traverse a never-ending list is logical only if the user leaves feeling that it was worthwhile.
  • Users often expect a footer.
    If footer-type information is functional to the interface, then it should appear at the bottom of the page. A fixed footer is usually the way to go with infinite scrolling.
  • An infinite list is still a list.
    Infinite scrolling still needs to meet common interface standards. Whether users take their eyes off the screen for a moment or click a link and then click “Back,” they expect to return to the exact point where they left off. Whatever your interface, make sure it meets users’ expectations.
  • Effects are nice to have but not a must.
    Many infinitely scrolling interfaces have various effects to show more data (whether by sliding in new content or another method). Be mindful not to focus more on effects than on presenting data in the most effective way possible.

Use It Correctly

Users are goal-oriented and find satisfaction in reaching the end of their exploration. To be effective, infinite scrolling has to account for this. Nothing is really infinite, not even these infinitely scrolling lists we’ve looked at. Users should always know where they stand, even when the content has not finished loading. They should know what the total amount of data is and be able to easily navigate the list. Infinite scrolling has to be implemented in the best possible way so that users can always find their way.

(al)


© Yogev Ahuvia for Smashing Magazine, 2013.

Continue reading

Read More

Open Source Plugin: Magnific Popup, A Truly Responsive Lightbox (For jQuery And Zepto.js)

  

A lightbox is one of those tools that work great on the desktop but often fail on small mobile devices. These days, finding a plugin that is responsive and that displays content right away is hard. For this reason, I created Magnific… Continue reading

Read More

Desktop Wallpaper Calendar: May 2013

  

We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered t… Continue reading

Read More

Content Knowledge Is Power

  

“Content matters!” “Comp with real copy!” “Have a plan!” By now, you’ve probably heard the refrain: making mobile work is hard if you don’t consider your content. But content knowledge isn’t just about ditching lore… Continue reading

Read More

CSS3 Transitions: Thank God We Have A Specification!

  

This article is packed with a number of quirks and issues you should be aware of when working with CSS3 transitions. Please note that I’m not showing any workarounds or giving advice on how to circumvent the issues discussed. Alex … Continue reading

Read More

Responsive Layouts: How To Maintain Hierarchy Through Content Choreography

  

One of the issues we need to be concerned with in responsive design is how to maintain hierarchy as elements on the screen are resized and reflowed. Trent Walton first called attention to the issue with his post “Content Choreograp… Continue reading

Read More

Pre-Order Your Smashing Book #4 Now: “New Perspectives On Web Design”

  

Update (24.04.2013): A standalone eBook Bundle option is now available as well. The bundle contains two eBooks — for iBooks, Kindle, Nook and most other eBook readers and devices.
It’s that time of the year again: We’ve sta… Continue reading

Read More

Is Photoshop Really Dead?: Repurposing Photoshop For The Web

  

Like any overzealous teenager aspiring to be a Web designer back in 1999, I found myself in an “Electronic Design” class, behind the wheel of one of those old-school aqua iMacs. If you found yourself in a similar situation, chanc… Continue reading

Read More
Page 1 of 3123»

Contact Us

Nebraska Digital
2124 Y St., Suite 108
Lincoln, NE 68503
402.476.3438
info@nebraskadigital.com