When you start incorporating the new responsive images standards across your site, the task can seem daunting. How do you know which standards to use and where? How will you maintain the new markup and image sizes?
We have found that a good first step is a responsive images audit.
Much like a content audit, a responsive images audit is designed to help you take stock of the images you have on your site and how they are being utilized.
The output of the audit is often a spreadsheet describing different types of images, the templates they are used on, and what solution you plan on implementing for those images.
Sample questions to ask about images
Here are some sample questions you should consider asking about the images on your site:
Where are the source files and what is the process for publishing?
This may seem unrelated to the technical questions of how the responsive images will be implemented, but my experience has been that knowing where the images are coming from, where they are stored, and if anyone needs to modify the image before it is posted can dictate what solutions are practical.
Consider this your reminder that people are still involved and you need to understand the people part first.
Is there a big difference between smallest and largest image size?
We had a client who had badges for awards and types of recognition. These badges were displayed at a small size even when the page was large. We found that even if we had the largest size possible at retina density, the images were about same in file size. So why provide multiple image sizes?
In addition, the images came from third parties and they didn’t have the source which was another good reason to simply use the largest image and have the browser resize it.
Are the images resolution switching or art direction?
Knowing which use case you’re solving for will help determine which syntax makes the most sense.
Can we use SVG?
If the images will work well as vector, then we may be able to use a single image source.
Are there representative images we can use to find sensible jumps in file sizes for our image breakpoints?
Picking responsive image breakpoints remains a tough problem. It can be easier if all the imagery we’re using are things we control and have a distinct style.
If there are representative images, then we can save them at various sizes in the range they will be used in the template and make a determination of how many image sources we need to provide.
In situations where images come from user generated content, it can be harder to find representative images from which you can determine image breakpoints. In that case, we know we’re going to have to make an educated guess about what will work.
Do we want to support multiple image formats?
Perhaps we’re using a lot of alpha channel images and want to provide JPEG 2000 for those whose browser supports that image format. Or perhaps we want to provide WebP alternatives.
If we determine there is a good reason to do this for a set of images, then that will mean we want to use the <picture> element even if we aren’t doing art direction.
Sample responsive images audit results
We conducted a responsive images audit for a large site. The end result was a spreadsheet that looked like the table below.
||PNG8 (future SVG)
||Little variance between the wide and small screen image sizes.
||PNG8 (future SVG)
||Little variance between the wide and small screen image sizes.
||PNG8 (future SVG)
||Assumes little variance between the wide and small screen image sizes.
||Dynamically resized and compressed
||Templates specify breakpoints.
|Promo images w/ text
||Content producer defines images and breakpoints in CMS.
We did this audit a couple of years so we might have different answers today than we did then.
Also, it is worth noting that the property photography represented over ninety percent of the images on the site. We have found this to be common on the sites we’ve worked with.
Combine the audit with image services
Once you have your audit complete, you need to combine it with image resizing and processing services so you know how you will implement what your audit recommended. For more on that, check out:
Responsive images have landed in Chrome and Opera. They are in development for Firefox and Webkit. They are under consideration for Internet Explorer.
This is an amazing accomplishment. To get here, the following happened including many firsts:
- The Responsive Images Community Group was formed. It now cited as a model for how W3C Community Groups can inform the standards process.
- There have been four major specifications (picture, srcset, src-n, and the final picture specification) along with many minor iterations along the way.
- An IndieGogo campaign to fund Yoav Weiss’s implementation of the feature in Blink. The first crowd-sourced funding of a browser feature ever.
- Hours of time put in by volunteers and browser makers to make sure these standards will work and implementing them in browsers.
After nearly four years and a ton work, we finally have responsive images.
Now the hard work begins.
Responsive images will now go from the limited number of people in the Responsive Images Community Group to the web at large.
Many people will struggle to learn the new tools and to ascertain when it makes sense to use each. Not to mention the navigating the thorny, unsolvable problems of responsive image breakpoints.
For the last few weeks, I’ve been working on ways to help people learn responsive images. The first output of that work will start tomorrow with a presentation called “Responsive Images Are Here. Now What?” at An Event Apart Atlanta. I’m repeating the talk at AEA Seattle and San Diego.
If you want a deeper dive, I’m giving a full day workshop at UX Mobile Immersion on When Responsive Web Design Meets the Real World which will cover images in detail.
The research I did to prepare for those talks has created a backlog of articles that I want to write. Watch this space. They are coming soon.
So responsive images are here, and they are going to be a big deal for the web in 2015. It’s time to prepare for them; to understand how to use them; and to start tackling the tough challenges of integrating them into our sites.
I can’t wait to see how people use these new browser features.
P.S. If you attend AEA or UXIM, you can use these discount codes to save money. ‘AEAGRIG’ will save you $100 on any AEA event. ‘UXIMSPK’ will save you $300 on the UXIM workshops.
I wrote recently about why you shouldn’t use <picture> for responsive images most of the time.
In short, my argument is that most responsive images fall under the resolution switching use case and that <picture> is best used for art direction.
There is one resolution switching use case where <picture> makes sense—when you want to provide different file formats using the type attribute.
If that is the case, then you should use <picture> without the media attribute.
Most of the syntax examples for <picture> include the media attribute, but it isn’t required. You can do something like:
<source type="image/svg+xml" srcset="logo.svg" />
<source type="image/webp" srcset="logo.webp" />
<source type="image/png" srcset="logo.png" />
<img src="logo.gif" alt="Company logo" />
That is a simple example with a single file per source element, but there is no reason you can’t use the full power of the srcset attribute to provide multiple files per file type. You can even add the sizes attribute to give you more control.
So long as you don’t use the media attribute, you’re still giving the browser the information it needs to pick the right image source without dictating to it that it must use a specific one.
And unless you’re doing art direction, you should be striving to provide the browser with options, but letting the browser pick which source will work best.
(Thanks to Kevin Lozandier for reminding me that I need to write this up, and to Brett Jankford and Wesley Smits for raising this point in the comments on my previous article.)
Now that responsive images have landed in Chrome and Opera, I’ve started working on a flowchart to help people decide how to use these new features.
This work led me to wonder what ever happened to the
For those who haven’t heard of the
image-set() specification, it was a precursor to
srcset which is now part of the responsive images specification. It was originally proposed in February 2012, and WebKit-based browsers shipped prefixed support for it in August of the same year.
The are a few differences between
image-set(), but the biggest difference is that
image-set() deals with CSS images whereas
srcset is an attribute on the
How we forgot about image-set()
In 2012, the
image-set() spec was still under development and we were cautioned against using it at the time. Because media queries were available in CSS, handling CSS images in responsive designs wasn’t as difficult as handling responsive images in HTML itself.
So the Responsive Images Community Group focused on how to solve the
<img> problem. And I gradually forgot about
image-set() thinking that it was moving forward in the CSS Working Group and browsers.
It seems that I may not have been the only one who forgot about
image-set() because despite being two years older than
<picture>, it is still only supported under prefixing in Chrome and Safari. Worse, it isn’t on the roadmap for either Internet Explorer or Firefox.
Why we need image-set()
image-set() for the exact same reasons we need
sizes. Whenever we are dealing with a CSS image that fits the resolution switching use case instead of the art direction use case, we should be using
image-set() instead of media queries.
In fact, you can take nearly everything I wrote in Don’t Use <picture> (most of the time) and substitute
srcset and media queries for
<picture> and the same logic applies.
image-set() for resolution switching because it gives browsers the choice of what size image source will work best. And in cases where all we are dealing with is resolution switching, the browser is better informed than we are as web authors.
Help get image-set() into browsers
We need your help to make sure that image-set() is implemented in browsers. Help us by voicing your support and ask browsers to prioritize this feature:
Image-set() is a key piece of having a comprehensive responsive images solution in browsers. It has been languishing too long. Let’s get it back on track.
This past week, I had the luxury of attending the Digital Project Management conference in Austin. If you are a project manager and you haven’t heard about this group of awesome digital PMs, you are missing out. The first time I attended one of their events, I thought, finally! These are my people! People who actually do what I do at Cloud Four. My tribe.
What do I do, every day? What do digital project managers actually do? It’s mundane stuff, folks. In any given day, I write a ton of emails and Basecamp threads, review lists — many, many lists, in many different forms. I pester people in every way imaginable. (Letters. I’ve written actual letters at times.) I listen, a lot. I run conference calls, I Skype, I Hangout, I Slack, I SIP into meetings. Today, I slacked, then hangout, then called the same person in a 10 minute period. This is not glorious work.
It occurs to me frequently that this is work that really anyone could do. In fact, the tools we use are often designed so that anyone on my team is empowered to use them.
Want to schedule a meeting? Great! Lucid Meetings makes this really simple. It even walks you through agenda creation and attendee selection! (You know you need an agenda for every meeting, right? Make them good ones, too.) Want to ask the client a question? Perfect! Hit them up in Slack, or Basecamp. You don’t need me.
Sometimes it feels like the work we do is complete BS.
This is not the most encouraging thought to be having about your chosen career.
But here’s the thing: the reason we have project managers at all is because most people are not thinking about these things. Your project team is so heads down on the work they are doing that they don’t think about the overall project progress, or the political implications of asking a certain question, or just the right way to deal with that nagging change request. They don’t worry about the overall budget impact of that bug that was just found in QA, or how the hell you are going to schedule one extra sprint when you’ve got two other projects starting that same week.
They just don’t. But YOU do. And YOU are really freaking good at it.
[cue the inspirational music]
YOU wake up in the middle of the night, wondering why that one stakeholder didn’t seem engaged in your kick-off meeting that day.
YOU can’t shake that feeling that something isn’t right about that call you just had with your developer. She didn’t really say anything, but you know something is off and how to suss it out.
YOU know exactly how to load your project teams to maximize efficiency without overloading them.
YOU can evaluate a budget overage, report it to the customer, and offer alternatives that are actionable and clear.
YOU inspire and motivate your team to keep on keeping on.
YOU see patterns of inefficiencies in your organization and have ideas on how to address them.
And this is not just about making sure that someone (anyone) is tasked with these types of things. It’s making sure the right person is leading it.
This stuff is our DNA. And it’s not mundane or ordinary. It’s essential, technical, precise, and difficult work. It’s hard and soft skills. It’s invisible, yes, but like my ever-so-talented colleague Tyler Sticka described it, we’re like the project’s nervous system. The developers, designers, and other project team members are like arms and the legs, moving the body around, but they’d be paralyzed without a good PM to make sure signals are going where they need to be.
Like Nancy Lyons said in the closing DPM keynote, “We are change-makers, we are thinkers, we are do-ers.”
That’s some really cool, important BS, if you ask me.