Hero images present unique challenges for responsive designs. During a recent responsive images audit, we found a unique solution which I wanted to share.
What are hero images?
Until a couple years ago, I was unfamiliar with the term hero image. A friend who worked for a large agency used the term, and I had to ask what it meant. I don’t know if it is a common description and I was living under a rock. Or maybe it is agency jargon.
But just in case I’m not the only one who doesn’t know what a hero image is, a hero image is a large promotional image like the one from Target below:
Responsive hero images?
Hero images often present unique problems for responsive designs. Many hero images have text in the image itself. When text is in an image, it often means that the responsive image will fall into the art direction use case instead of the easier to solve resolution switching use case.
We can see an example of why the art direction is important by looking at the CB2 site and one of its hero images.
This image contains three photographs, two logos with type in them, and a stamp and text that both use thin strokes. If we simply resized this image to 320 pixels wide, the text would be too small to be readable.
CB2 doesn’t currently have a responsive site, but it does have a mobile web site where we can see how they handle this hero image on small screens.
In order to make the image work on small screens, CB2 does the following:
Changes from three photographs to two
Modifies the aspect ratio to make the image taller
Redesigns the layout of the image
As you can see the changes necessary to make a hero image work on small screens can be substantial.
Requirements for hero images
Our usual process for responsive designs is to understand the goals, needs, analytics, and user feedback for each pattern in the design. We use this information to understand the requirements for the pattern and to prioritize what the small screen version needs to accomplish.
The full requirements for hero images can be summed up as:
A box for marketing.
In my experience, any attempt to narrow down what can go into the box will meet resistance. The people responsible for marketing understandably don’t want their future options limited.
Ideal world solutions
As we were brainstorming ideas on what to do for this client, we kept finding ourselves referring to what we would do in an ideal world.
In an ideal world, we’d:
Build complex HTML5-based animations like Apple.
Apple has created rich pages that react as you scroll and otherwise interact with them. They make the old days of flash animation look quaint.
They are also one of the wealthiest companies on the planet and only release new products once a year. You may not have similar resources.
Remove text from images, put it in HTML, and use CSS to overlay the image.
This makes a ton of sense. If we separate out the text from hero images, then we can adjust the placement of the text as the viewport changes.
Sites like Crate and Barrel have established a specific text treatment and placement for all promo images.
However, this again is an ideal world situation. All of the photography must have areas that are designed to accommodate the text. You can see how Crate and Barrel must ask all of their photographers to keep this in mind.
That solution may not work depending on the requirements of the brand and how frequently the images are being updated.
Real world conditions
We’re often not working in an ideal world. Take Free People for example:
Free People has a strong artistic vision for their site. The combination of type and imagery matters. And they update the images daily.
If you’re updating hero images on a daily or weekly basis, many of the ideal world solutions are impractical. Not to mention the fact that the people responsible for creating the hero images may be graphic designers, not web designers or developers.
Give them <picture> and let them have their box
After striking out on the idealistic solutions, we started looking at ways to give the designers as much control as they might need.
We thought, “We should use the picture element to give them a box that marketing can use. Then their designers would have complete control to decide how many image sources they need and where the breakpoints should be.”
Responsive image breakpoints FTL!
Doing this would have been easier for us, but it would have be a jerk move.
Imagine what this would have meant for the designers who create these images. Not only does the responsive design mean that they have to create multiple versions of hero images now.
But we’d also asking them to figure out how many versions of the hero images they need to make and where the image breakpoints should be. And they need to figure this out every day for every image they create.
Like I said: a jerk move. Don’t do this.
Using hero image text to determine breakpoints
After striking out on several different solutions, we realized that the text might be the key. If it weren’t for the text in these hero images, the hero images would fall under the resolution switching instead of art direction use case.
We wondered if there was a way look at how well the text resized and determine the breakpoints based on when the text became illegible.
This was the point at which we discovered that there were in fact a few requirements for the client’s hero images:
The images must use the brand’s chosen typeface.
The typeface could not be smaller than 18pt.
All of the images must follow these rules. So we set out to find out how well the typeface resized.
We started by creating a canvas in Photoshop that matched the largest size that the hero images would ever be used at. We filled that canvas with the chosen typeface in various sizes and weights.
Below is an example of what that canvas would have looked like if the typeface was Myriad and brand color was black.
After we saved the image as a PNG, we opened it in Chrome and started resizing it until the text was unreadable.
We determined that the 18pt italics weight became unreadable at around 774 pixels. So we created a new image that started at that size and repeated the experiment.
The new image could span from 780 to 540 pixels wide before it became unreadable. So we then made a third image that started at 540 pixels wide. The third image worked at our smallest supported size, 320 pixels, so we stopped there.
Adjusting for ease of implementation
Once we knew where the type was no longer readable, we made some minor adjustments. We changed the image breakpoints from the arbitrary measurements that we had received in our experiment to numbers that were more easily divisible, and where possible, matched our grid.
So instead of using 774 pixels as the point as which we should switch from the 1080 image to a different one, we decided on 780 pixels.
We then took several of the existing hero images and attempted to make smaller versions of them using the new image sizes. We found, similar to the CB2 example above, that we needed to adjust the aspect ratio of the hero images in order to give us more vertical real estate on small screens.
After we had completed all of our tweaks and had new sizes for the responsive versions of the hero image that we thought would work, we used our type image resizing technique to verify that the typeface would hold up for the range of that we were going to recommend.
Type-based guidelines for responsive hero images
When we had completed our research, we had a simple set of guidelines that we could give to the designers responsible for the hero images.
So long as the designers didn’t use anything smaller than 18pt and continued to only use the typeface that the brand specified, then the three sizes of hero images that we specified would work.
I know it seems suspicious that we ended up with small, medium and large images when so much of our industry is focused on mobile, tablet and desktop.
But we didn’t pick three image sources ahead of time. We let the type tell us how many breakpoints were needed.
In fact, we did a test and found that if the client wanted to use 16pt in their typeface of choice, that it would have required four breakpoints. And if they change fonts, a new experiment would be needed.
Start with an audit and let content be your guide
This system worked for one client on one project. It may not work for your project.
But whatever you do, it is a reminder that finding a solution starts with a responsive images audit. And whenever possible, we should let the content dictate how our responsive design will respond.
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 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.
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.
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.
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.
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.
We’re growing! We’re searching for an enthusiastic and talented front-end designer to join our small team in downtown Portland.
We believe good designers are also educators and explainers. You should be comfortable leading design discussions and facilitating workshops with clients to gather requirements and establish direction.
While you’re comfortable with wireframes and comps, you’re also fluent in the language of the web and often prefer to go from sketching to designing in the browser. You’ll need a passion for HTML and CSS to build the complex responsive designs we specialize in.
Nearly every project we undertake we do as a team. We prefer frequent iterations and working collaboratively with our clients on designs. We need people who have empathy and communicate well.
We provide a positive and creative workplace where people can do their best work. We value the unique contributions of every member of the Cloud Four team. We welcome and seek diverse opinions and backgrounds.
We’re not interested in startup insanity. We support our families with reasonable hours, flexible schedules, and the ability to work from home when needed. We offer benefits including medical, dental, vision, and IRA.
We’re a small agency with big aspirations. We started Mobile Portland and host a community device testing lab. We speak at conferences and participate in web standards setting. We like exploring the frontiers of what’s possible on the web and sharing what we learn.
If this sounds like you, please send your resume and a cover letter explaining why you’re the right person to join our team to firstname.lastname@example.org.