Tags: ffly

4

sparkline

Detection

When I wrote about responsible responsive images a few months back, I outlined my two golden rules when evaluating the various techniques out there:

  1. The small image should be default.
  2. Don’t load images twice (in other words, don’t load the small images and the larger images).

I also described why that led to my dissatisfaction with most server-side device libraries for user-agent sniffing:

When you consider the way that I’m approaching responsive images, those libraries are over-engineered. They contain a massive list of mobile user-agent strings that I’ll never need. Remember, I’m taking a mobile-first approach and assuming a mobile browser by default. So if I’m going to overturn that assumption, all I need is a list of desktop user-agent strings.

I finished by asking:

Anybody fancy putting it together?

Well, it turns out that Brett Jankord is doing just that with a device-detection script called Categorizr:

Instead of assuming the device is a desktop, and detecting mobile and tablet device user agents, Categorizr is a mobile first based device detection. It assumes the device is mobile and sets up checks to see if it’s a desktop or tablet. Desktops are fairly easy to detect, the user agents are known, and are not changing anytime soon.

It isn’t ready for public consumption yet and there are plenty of known issues to iron out first, but I think the fundamental approach is spot-on:

By assuming devices are mobile from the beginning, Categorizr aims to be more future friendly. When new phones come out, you don’t need to worry if their new user agent is in your device detection script since devices are assumed mobile from the start.

Responsible responsive images

I’m in Belfast right now for this year’s Build conference, so I am. I spent yesterday leading a workshop on —the marriage of responsive design with progressive enhancement; a content-first approach to web design.

I spent a chunk of time in the afternoon going over the thorny challenges of responsive images. Jason has been doing a great job of rounding up all the options available to you when it comes to implementing responsive images:

  1. Responsive IMGs, Part 1,
  2. Responsive IMGs, Part 2—an in-depth look at techniques,
  3. Responsive IMGs, Part 3—the future of the img element.

Personally, I have two golden rules in mind when it comes to choosing a responsive image technique for a particular project:

  1. The small image should be default.
  2. Don’t load images twice (in other words, don’t load the small images and the larger images).

That first guideline simply stems from the mobile-first approach: instead of thinking of the desktop experience as the default, I’m assuming that people are using small screen, narrow bandwidth devices until proven otherwise.

Assuming a small-screen device by default, the problem is now how to swap out the small images for larger images on wider viewports …without downloading both images.

I like Mark’s simplified version of Scott’s original responsive image technique and I also like Andy’s contextual responsive images technique. They all share a common starting point: setting a cookie with JavaScript before any images have started loading. Then the cookie can be read on the server side to send the appropriate image (and remember, because the default is to assume a smaller screen, if JavaScript isn’t available the browser is given the safer fallback of small images).

Yoav Weiss has been doing some research into preloaders, cookies and race conditions in browsers and found out that in some situations, it’s possible that images will begin to download before the JavaScript in the head of the document has a chance to set the cookie. This means that in some cases, on first visiting a page, desktop browsers like IE9 might begin get the small images instead of the larger images, thereby violating the second rule (though, again, mobile browsers will always get the smaller images, never the larger images).

Yoav concludes:

Different browsers act differently with regard to which resources they download before/after the head scripts are done loading and running. Furthermore, that behavior is not defined in any spec, and may change with every new release. We cannot and should not count on it.

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That’s why I was surprised by Jason’s conclusion that device detection is the future-friendly img option.

Don’t get me wrong: using a service like Sencha.io SRC (formerly TinySRC)—which relies on user-agent sniffing and a device library lookup—is a perfectly reasonable solution for responsive images …for now. But I wouldn’t call it future friendly; quite the opposite. If anything, it might be the most present-friendly technique.

One issue with relying on user-agent sniffing is the danger of false positives: a tablet may get incorrectly identified as a mobile phone, a mobile browser may get incorrectly identified as a desktop browser and so on. But those are edge cases and they’re actually few and far between …for now.

The bigger issue with relying on user-agent sniffing is that you are then entering into an arms race. You can’t just plug in a device library and forget about it. The library must be constantly maintained and kept up to date. Given the almost-exponential expansion of the device and browser landscape, that’s going to get harder and harder.

Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven’t imagined yet—will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won’t hold up. Today’s onslaught of devices is already pushing them to the breaking point. They can’t withstand what’s ahead.

So while I consider user-agent sniffing to be an acceptable short-term solution, I don’t think it can scale to the future onslaught—not to mention the tricky issue of the licensing landscape around device libraries.

There’s another reason why I tend to steer clear of device libraries like WURFL and Device Atlas. When you consider the way that I’m approaching responsive images, those libraries are over-engineered. They contain a massive list of mobile user-agent strings that I’ll never need. Remember, I’m taking a mobile-first approach and assuming a mobile browser by default. So if I’m going to overturn that assumption, all I need is a list of desktop user-agent strings. That’s a much less ambitious undertaking. Such a library wouldn’t need to kept updated quite as often as a mobile device listing.

Anybody fancy putting it together?

Ending September

September was quite a month. There were plenty of events that I attended right here in Brighton:

In the middle of all that, I went to Tennessee for Breaking Development and Mobilewood.

I finished the month with a trip to Italy for the inaugural From The Front conference. It was a great little grassroots affair. It was basically a free event—there was an ostensible cover charge of ten euros just to ensure that people didn’t sign up without showing up. That’s why I waived my usual speaking fee (as an aside, if you’re a conference organiser and you’re thinking about asking me to speak for free at an event that charges hundreds of dollars/pounds/euros to attendees …don’t).

I have to admit that the location of the event did make a difference. I jumped at the chance to return to Bologna. Jessica and I even managed to squeeze in a trip down to Florence. Pictures were taken.

The evening before travelling to Italy, before I packed my bag I had a chat with Jen for her podcast, The Web Ahead.

5by5 | The Web Ahead #3: Jeremy Keith on Everything Web on Huffduffer

We talked about a lot of stuff from the nitty-gritty of responsive web design workflows and processes to being future friendly in the face of the mobile browser landscape. We also discussed long-term digital preservation and the web’s role as a storage medium for our collective culture. It sounds like a random grab-bag of topics, but in my mind all of this is connected.

I somehow managed to avoid even once mentioning a space elevator.

Mobilewood

Online communication is a wonderful thing but I firmly believe that there’s enormous value to be had in getting together in meatspace for some proper face-to-face discussion. Take the gathering in New York of what later came to be known as HTML5 Super Friends. It was an intense two days of poring over the spec with really smart people. My brain hurt by the end of it but that was a small price to pay for such a rewarding experience.

When the finest minds in mobile recently gathered together in Nashville for the Breaking Development conference, the opportunity for extending the gathering was too good to pass up. By some clerical error, I was also asked along. Thus it was that I found myself in the company of these fine people in a secluded house in Tennessee:

We called it Mobilewood. It was a blast.

Cuddling with multiple devices Jump into Mobilewood! The heroes of mobilewood IMG_0118

It wasn’t all hot tubs and campfires—although there was plenty of both. We worked hard and played hard. Luke did a great job of structuring the event, wielding his managerial experience to make sure that we never got bogged down. We began with some ambitious discussions which led to more focused brainstorming which in turn led to a number of individual projects.

It became clear from fairly early on that simply focusing on mobile alone would be missing the bigger picture. Instead of being overwhelmed by the ever-increasing range of devices out there, we need to embrace the chaos and accept there will be even more devices—and types of devices—that we can’t even anticipate. We should embrace that. Instead of focusing on whatever this season’s model happens to be, we should be crafting our services in a robust way, striving for universal access tomorrow as well as today.

The first project to launch is a manifesto of sorts. It’s a called to arms. Or rather, it’s a call to be future friendly:

  1. Acknowledge and embrace unpredictability.
  2. Think and behave in a future-friendly way.
  3. Help others do the same.

The future friendly site also contains a set of design principles, but they are the starting points for discussions rather than the end points for solutions. Consider them a work in progress.

You can also find a list of future-friendly resources that will most definitely grow over time—probably beyond the bounds of the site.

This is just the beginning. The future is ours to make—friendly.

Devices and mobinauts