Cloud Four Blog

Technical notes, War stories and anecdotes

Responsive Web Design is Solid Gold

A few years ago I wrote an article entitled CSS Media Query for Mobile is Fool’s Gold. It garnered a lot of attention at the time, and I still see people reference it.

I’ve long wanted to write an update to that article, but never knew quite what to say until now. And because one inflammatory title deserves another, read on for why Responsive Web Design is Solid Gold.

Our default approach is now responsive web design

Back in 2010 when I wrote the Fool’s Gold article, our default approach for mobile was to use device detection. If a site was simple and the budget small, we might use responsive web design.

Some time ago our default approach switched. We now treat responsive web design as the default approach and look out for reasons why it won’t work instead of the other way around.

Why did our default approach change? Two reasons: performance and device diversity.

Update on performance

Much of my Fool’s Gold article focuses on performance problems with flexible images and CSS background images. One of the reasons why I’ve had trouble figuring out how to write a follow up is because the performance issues that I raised remain true today.

Let’s do a quick round up of the issues and updates on each:

Perhaps most importantly, most responsive web sites are still far too large on small screens.

So if most of these remain true and most responsive designs are bloated, why has my perspective changed?

Because it is possible to build responsive design responsibly and create fast experiences. The keys to doing so are:

  1. Build mobile first responsive designs
  2. Keep CSS background images in scoped media queries
  3. Conditionally load JavaScript and even HTML fragments based on screen size and capabilities
  4. Implement a responsive images solution
  5. Handle retina images very carefully and err on the side of performance

If you do these things and do the normal things you should do to make any web page fast, you will have a fast responsive design. It may not be easy, but it is possible.

But what about the fact that most responsive designs are bloated? As Tim Kadlec says, “blame the implementation, not the technique“.

I don’t blame device detection for the many sites that route people to the mobile home page instead of the article they’re looking for. And I don’t blame responsive web design for the fact that most implementations are bloated.

Can a responsive design ever be as fast as a page tailored for a specific device?

Probably not. But the web is a balancing act between many competing interests. A site that was completely tailored for search engine optimization would be unreadable by humans.

By the same token, performance is an extremely important factor, but is still just one of many factors that make a site successful. You can build responsive designs that are fast enough that the benefits of responsive design outweigh the potential performance improvements you might get from separate sites.

Especially when you consider device diversity.

Device diversity makes responsive design inevitable

Let’s assume for a moment that responsive design doesn’t work for your project. So you decide that you’re going to need to build mobile, tablet and desktop experiences. And let’s set aside for the moment the inevitability of new form factors like televisions, watches, etc.

Even in this scenario with different experiences for each of the three major form factors, you’re still going to end up needing responsive design—or at least responsive characteristics.

Yesterday, Samsung announced that it was launching a 6.3 inch phone. The range of screen sizes on mobile phones alone will likely force you to build something that will adjust from the small screen sizes of Blackberry Bolds and feature phones to the mammoth screens of some Samsung devices.

Tablets present a similar challenge ranging from 7 to 13 inch displays (and sometimes much bigger). And we’re all familiar with the large difference between ultrabook screens and cinema displays.

I wrote in much more detail about the impact of device diversity earlier this year and my conclusion that:

Any attempt to draw a line around a particular device class has as much permanence as a literal line in the sand. Pause for a moment and the line blurs. Look away and it will be gone.

So regardless of what techniques you use in addition to it, responsive web design will likely be part of your solution.

What about mobile context?

One of the other points I made in the Fool’s Gold article was related to mobile context. It is something I’ve struggled with for years.

I’m now firmly on the side that there is no mobile context. We have abundant data that shows that people use their mobile devices indoors and for a wide variety of things.

Luke captured it well when he wrote:

But if there’s one thing I’ve learned in observing people on their mobile devices, it’s that they’ll do anything on mobile if they have the need. Write long emails? Check. Manage complex sets of information? Check. And the list goes on. If people want to do it, they’ll do it on mobile -especially when it’s their only or most convenient option.

Amen.

So Jeremy Keith and Stephen Hay were right. There is no mobile web. Mea culpa.

Still No Silver Bullets

I concluded my Fool’s Gold article by stating the obvious: there are no silver bullets when it comes to adapting our existing apps and sites for mobile screens. At that point in time, people were touting media queries as a quick fix for mobile.

Since then, our profession has learned a lot more about the complexity of designing and building experiences for multiple devices. Now it is generally understood that supporting all the devices that may access our content and services isn’t easy, but that tackling problems that range from responsive images to legacy content management systems are the heavy-lifting that we must do in order to be future friendly.

And despite those challenges, I’m excited about where the web is heading and what we can do with progressive enhancement and responsive web design.

Responsive web design: it’s solid gold, baby. :-)

We’re Hiring! Front end developer with strong JS skills

We’re growing! We’re searching for an enthusiastic and talented JavaScript and front-end developer to join our team.
We’re looking for someone who is crackerjack at JavaScript and the other building blocks of complex HTML5 apps—of course!—but who isn’t scared of putting things together on the back end or tackling other technical tasks needed to bring a web-based or hybrid native mobile application to bear.

Mobile is fast-paced and constantly changing, and we’re changing constantly along with it. Our team is built of flexible, smart folks who enjoy learning new stuff all the time and see opportunity in the challenges presented by all of those mobile devices out there (and their sometimes-finicky, inconsistent behavior).

We’re a small agency with big aspirations, focused on building mobile and web solutions for our customers. We believe in cross-platform solutions and advocate a mixture of mobile web, native, and hybrid approaches to mobile development depending on the project objectives.

Cloud Four was founded in November, 2007 by four mobile and Web enthusiasts. Our mission is to create usable, inspired mobile and web applications using standards-based technologies. Our clients range from Fortune 500 companies to local businesses, and our projects vary in audience and scope accordingly.

This is a full time position on-site in lovely, lively Portland, Ore. We offer benefits including medical, dental, vision, and IRA.

Job Description

  • Research, identify and document client technical requirements.
  • Determine and identify appropriate technologies to be used.
  • Assist with developing technical project schedules, plans, task assignments and time estimates.
  • Assist in strategic planning and requirements gathering.
  • Program mobile applications and build mobile web sites.
  • Be a positive and enthusiastic contributor to our team.

Our ideal candidate is:

  • Able to create a concise, clear plan of action from multiple input sources and stakeholders; flexible and responsive to changes in requirements and scope.
  • Self-directed and takes an ownership role of complex projects.
  • Strategy-focused and creative; excited to face new challenges and learn new skills.
  • Deadline-driven and steadfast about meeting commitments to customers.
  • Excellent communicator, ability to comprehend and articulate technical concepts both internally and to customers.
  • Able to learn and be productive quickly.
  • Passionate about the job and enjoys solving customer needs.
  • Straightforward, honest, team player.
  • Able to effectively prioritize multiple tasks.
  • Comfortable and enthusiastic in a small, start-up environment.

Experience and skills we’re seeking

  • 3-5+ years of relevant technical experience or related background.
  • Keen focus on JavaScript, with a firm expertise in application design, architecture, performance, testing and security.
  • Extensive experience with additional core front-end technologies (HTML5, HTML5 APIs, CSS), tools and components.
  • Some programming experience in at least one additional web language: PHP and/or Ruby are ideal.
  • A background of mobile web application implementation and/or experience with PhoneGap or other hybrid-native
    technologies strongly preferred.
  • Strong problem solving and analysis skills.
  • BA/BS or equivalent.
  • Not required, but excellent:
    • Native iOS or Android development
    • Node.js experience
    • Back-end web development experience

Drop us a line

Interested? Send us a resume and cover letter at jobs@cloudfour.com.

Responsive Web Design Business Challenges

During the Future of Mobile Web summit that dotMobi sponsored, I brought up a series of responsive web design (RWD) challenges that I’ve been thinking about that have little to do with technical implementations. John Leonard from dotMobi commented that he hadn’t read any blog posts about them. Time to remedy that.

Search Engine Optimization

Google, Bing and Yahoo all have different search bots for mobile. Google’s recommendations on how to make sites mobile friendly are all based around building separate sites and then ensuring that the Google mobile bot is redirected to the mobile version. Matt Cutts has talked about this in a video answer and Google has gone so far as to describe how you should redirect the Google mobile bot in some detail.

What does this mean for sites using responsive web design? Honestly, I don’t know. Nor does anyone else it appears. There is some question about whether or not mobile SEO is even worth pursuing.

But it is worrisome. Google recently announced that mobile website optimization now factors into mobile search ads quality. I’ve seen no indication that Google is considering responsive web design in its definition of mobile optimization. The announcement linked to several case studies and articles illustrating separate sites as the approach.

This is probably a problem with the search engines and not with responsive web design as a technique, but if a company relies on search engine traffic for revenue, it likely won’t matter who is to blame.

Advertising

There’s been a lot written about the difficulty of incorporating advertising into responsive design. Most of the focus has been on the fact that ads aren’t designed to be responsive breaking responsive layouts.

But there is another more structural issue: sometimes advertisers just want to advertise on one form factor and not another. App developers who want to drive app store purchases may not be interested in advertising on desktop. An advertiser interested in location-based advertising is also unlikely to consider responsive advertising desirable.

Will responsive web designs be able to participate in the growing mobile advertising opportunity?

Analytics

Most web analytics tools that support mobile provide an option to use a server side way of tracking instead of tracking via JavaScript. This is offered because many older devices either don’t support JavaScript or support it so poorly that using JavaScript-based tracking code is problematic.

Bryan and Stephanie Rieger have talked about how in their experience switching to the server-side code will show a lot more mobile traffic from a wider variety of devices than if you stick to the JavaScript version.

The problem is that you can’t run both the JavaScript and the server-side (mobile) variant on the same page. The analytics vendors recommend using the server-side code on your mobile site and the JavaScript one on your desktop site because the JavaScript version has a lot more data and features than the server-side one.

Sites using responsive web design will need to choose between more accurate data about the total mobile traffic (server-side tracking code) or deeper information about a small set of visitors (JavaScript tracking code).

Content Delivery Networks (CDNs)

On a responsive web design that takes care to provide only the assets that are appropriately sized for the device requesting the page, the images will vary based on the device. This causes problems with content delivery networks that have become accustomed to being able to cache a single asset for all devices or at worst caching a desktop and a mobile version of the asset.

As Ronan Cremin put it, CDNs may now need to cache different images based on the entire spectrum of devices accessing a site. FWIW, depending on how they are implemented, this can be a problem for separate sites as well.

One way in which RWD does not resemble the transition to standards

The move towards responsive web design has been compared by many to the changes that happened when web design went from being table-based to using web standards and CSS layouts. The Boston Globe’s new site has been compared to the impact that the ESPN and Wired redesigns in proving the value of web standards.

It may be that my faulty memory, but I don’t remember a similar list of potential drawbacks from a business perspective to making the change to CSS-based layouts. If anything, things standards-based layouts had great business benefits because of the increased semantic markup leading to better search rankings and the leaner code helping with page performance and bandwidth costs. Yes, like responsive web design, retraining staff and changing infrastructure could be a major undertaking, but there wasn’t concern that making a change would negatively impact search rankings or make analytics more difficult.

And I honestly don’t know how big of a problem any of these things are with the exception of the analytics problem which seems clearly to be a pickle. It may be that search engine rankings aren’t impacted at all. But the fact that we don’t know seems like something that should be sorted out and considered if those things are critical to the success of a given project or client.

And to be 100% clear, I’m not saying people shouldn’t do responsive web design. Even if you were to build separate sites, you should still do responsive web design for the separate sites.

I’m simply saying these are challenges and concerns that I don’t think we’ve currently got good answers for.

Mobile web workshop in New York — We need your help

Lyza and I are giving a mobile web workshop next week at WebVisions NYC. We’re preparing an outstanding workshop for web designers and developers who want to learn how to build for mobile devices. We’re very excited about the workshop. It’s going to rock, but we need your help!

But we’ve got a problem. We came up with a fun theme (Zombie Apocalypse!) to make the workshop interesting, but we’ve heard people were reluctant to register for the workshop because they didn’t get it. :-(

Since we heard about the registration problem, we’ve lept into action:

  • We’ve rewritten the workshop description so it is clearer what people will learn at the workshop.
  • We’ve posted a fun preview of the talk. The preview made me giggle multiple times when I read what Lyza had wrote.
  • We’re here asking for your help.

We need your help getting the last minute word out. If you can take a moment to share the event, we would appreciate it. Particularly if you know people in New York who would benefit, we would be grateful if you pass the word onto them directly.

Zombie Apocalypse of Devices Preparedness 101 Workshop Preview

And of course we have discounts to share

WebVisions has provided us with a way to save 40% on conference passes. There are two options:

  1. Save 40% off a conference pass, get a FREE pass to Thomas Phinney’s “Web Typography Best Practices” workshop ($250 value) and a 60-day unlimited WebINK account (register at http://wvnyc-webink.eventbrite.com/), OR
  2. Save 40% on conference passes to WebVisions NYC and receive a FREE Workshop pass ($250 value) to Kevin Hoyt’s “Web Standards Playground” (register at http://wvnyc-adobe.eventbrite.com/).

I honestly had to read that a few times to make sure I understood the deal correctly. Seriously, 40% off and you get a free workshop? My guess is that Adobe and WebINK are helping sponsor the discounts which is pretty cool way to get into a workshop and save money.

WebVisions is a fantastic event

WebVisions is new to New York, but it has been going on in Portland for several years now. It always has fantastic speakers and the line up in New York is no different. Please help us make the event a success.

Thanks in advance for spreading the word. We greatly appreciate it and promise we’ll be less cutesy and more descriptive in our workshop abstracts from now on. :-)

Responsive IMGs Part 3 — Future of the IMG Tag

The conversation in the comments on part 1 and 2 of this Responsive IMGs series have been exceptional. If you read the articles, but didn’t read the comments, I encourage you to go read them. There are people much smarter than me in those comment threads.

One of common conclusion from the commenters is that our current IMG tag isn’t going to cut it. That we need some sort of replacement that is future friendly. This isn’t the first time the idea of expanding or replacing the IMG tag has come up.

I promised to collect some of these proposals so we can discuss their relative merits.

Current proposals and discussions to replace or extend the IMG tag

As far as I know, there hasn’t been a formal proposal submitted to any standards bodies, but there have been several conversations worth highlighting. I was going to try to summarize the various proposals, but there hasn’t been a lot of consensus. I’m afraid that to get up to speed, you’re going to have to read the threads.

Adaptive Images on W3C HTML mailing list

At the end of May, Dom Hazael-Massieux kicked off a lengthy thread talking about Adaptive Images with two ideas: a srclist attribute and new image file format that would be a text file containing a list of images.

The thread continues with many other ideas including new http headers, progressive image formats, and general media formats with queries.

BTW, Adaptive Images has been added as a placeholder on the HTML.next list.

Discussing Alternatives For Various Sizes Of The Same Image & Introducing src Property In CSS As An Option by Robert Nyman
Robert asks the question, “whether various sizes of the same image is really content or presentation?” If it is presentation, then it should be in CSS. Again, great discussion in the comments.
Responsive images using CSS3 by Nicolas Gallagher
“This method relies on the use of @media queries, CSS3 generated content, and the CSS3 extension to the attr() function.” This means it relies on already existing standards without creating anything new. Unfortunately, it doesn’t prevent multiple images from being downloaded and currently only Opera supports the CSS3 content property. That said, if we could get browser makers to change download behavior, this could work with existing standards.
My take on adaptive images, Responsive images – hacks won’t cut it, and Simpler responsive images proposal by Yoav Weiss

No one has been blogging more about the need for a better solution than Yoav. His proposals have changed over time. The simpler responsive images proposal is his latest version, but they are all worth reading to see his thoughts and the feedback on each post.

add html-attribute for “responsive images” on WhatWG mailing list

Anselm Hannemann started a recent thread on the WhatWG mailing list proposing using media- and inline media queries to provide different images. One of the things notable about this thread is that there are some on the list who don’t think the current situation is a problem or if it is a problem, that it is a niché use case. We have some education to do.

Comments on Responsive IMGs Part 1 and Part 2

It seems weird to link to my own posts, but the comments on each post contain some good suggestion. Scott Jehl said, “It’s unfortunate the comment streams of these images posts are separated. Good stuff going on in both.” I agree. Best I can do is link them up with this post.

What are our goals for a replacement for the IMG tag?

As I read through the conversations about the potential replacements or extensions for the IMG tag, I’m struck by the fact that people seem to all see the same problem, but haven’t yet come up with common criteria that could be used to evaluate different potential solutions. Until that exists, we won’t have consensus.

For example, I would love to have the browser send more data via HTTP headers that would allow us to make determinations on the server about what size image to send. But I don’t think that will work as a replacement for the IMG tag because we need something that will work for HTML widgets where the server isn’t part of the picture.

(Psst… but seriously browser makers, more headers would be great!)

So what should be our criteria. Here is start from my perspective:

  • It should be an HTML element and not solely CSS because IMGs are often part of the content. IMGs are semantic.
  • The solution should work without server content negotiation so that it can be used for HTML widgets. This doesn’t preclude servers being part of the solution, but we need a solution that will work if servers aren’t in the mix.
  • Current caching and proxy strategies cannot be ignored. Because of this, different image sizes likely need to be at unique URLs or the wrong size image for a given user will end up cached at the edge of the network.
  • It should support arbitrary image sizes and pixel density.
  • It should support art direction decisions to change the image at different sizes.
  • It should be a framework that will allow for future expansion based on factors beyond screen size. For example, if the browser provides information about the speed of the network connection, the designer or developer should be able to decide on the most appropriate image. We don’t have to define this now, but we shouldn’t box ourselves in to only looking at screens size.

That’s my start on criteria. What did I get wrong? What would you add? And of the various IMG tag replacements that have been suggested, which do you think holds the most promise?