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.

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.

Browser Resizing Can Be CPU and Memory Intensive — A stretch.I’m not saying that there isn’t an impact to having the browser resize images. There definitely is especially if you’ve got an image that is several times larger than it needs to be based on the page layout. But in retrospect, this argument was a bit of FUD.

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.

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.

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.

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.

Drop us a line

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.

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.

Jason GrigsbyJanuary 12, 2012Comments Off on 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 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.

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:

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

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. :-)

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.

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.

“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.

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.

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.

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 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?

Join us for a spirited, knowledge-packed day scouting the frontiers of responsive web design and development in lovely Portland, Oregon. Responsive Field Day is a welcoming and affordable gathering for web designers and developers.