The talk description:

Responsive web design has become an important tool for front-end developers as they develop mobile-optimized solutions for clients. Browser-detection has been an important tool for server-side developers for the same task for much longer. Unfortunately, both techniques have certain limitations. I’ll show how both front-end and server-side developers can take advantage of the new technique called RESS (Responsive Web Design with Server Side Components) that aims to be combine the best of both worlds for delivering mobile-optimized content.

Intrigued? Here is the deck:

I love to get feedback so feel free to pop questions or comments below.

Responsive web design has become an important tool for front-end developers as they develop mobile-optimized solutions for clients. Browser-detection has been an important tool for server-side developers for the same task for much longer. Unfortunately, both techniques have certain limitations. I’ll show how both front-end and server-side developers can take advantage of the new technique called RESS (Responsive Web Design with Server Side Components) that aims to be combine the best of both worlds for delivering mobile-optimized content.

If the talk sounds interesting here are some useful links to get some more background (though I will obviously cover all this in the talk):

• RESS: Responsive Design + Server Side Components by Luke Wroblewski (@lukew)
• Which One: Responsive Design, Device Experiences, or RESS? by Luke Wroblewski (@lukew)
• RESS, Server-side Feature-detection and the Evolution of Responsive Web Design by me

I’ll also be talking a little bit about my work with Detector.

By the way, the other talk that night will be given by Patrick Fulton (@patrickfulton) and is on Compass. The description:

This presentation is an overview of Compass, which is a CSS authoring framework that tackles common stylesheet problems such as grid layouts, handling CSS3 vendor differences, and stylesheet optimization. It does for CSS what jQuery has done for JavaScript: solve real world problems, letting designers and developers create stylesheets more efficiently.

Thanks to Tobie Langel (@tobie) and Lindsey Simon (@elsigh) for including my library in the official repo and Paul Irish (@paul_irish) for getting us all together.

HighEdWeb National

The first is the national HighEdWeb conference which is being held in Milwaukee October 7-10. Milwaukee may not sound like the best location to spend a few days in chilly October but that’s more than made up for by the warm crowd. And it truly is a warm, friendly crowd of people who you can really commiserate with and learn from. It’s one conference where the connections grow beyond the conference itself. I haven’t been to national since the move away from Rochester but I’m hoping to change that this year. The deadline for submission for proposals is April 21st. You can submit ideas for a poster session or a 45 minute talk. Registration is $600 before July 31 but if you get accepted for a talk you save $100. A great deal. Go submit a proposal now.

HighEdWeb Arkansas

The second is the regional HighEdWeb Arkansas conference July 26-27. It’s being held in Little Rock. If you live within driving distance and want a nice, intimate higher ed conference experience then this is the one for you. I presented at another regional last year (HighEdWeb Rochester) and was impressed with the local connections that people were able to make. I’m running a workshop at HighEdWeb Arkansas this year and I’m looking forward to mingling with folks from a different part of the country. The deadline for submission of proposals is April 20th. If you’ve never spoken before but have something to share or want to roll out new material (which is what I did) this is a great venue to do it in. Go submit a proposal now.

PS – Another conference I’m presenting at, the Web Conference at Penn State, is almost full. Make sure to register now if you haven’t already.

Fast forward a year and a half (and quite a few arguments)… I’ve now worked on one responsive project, I’ve watched a number of other responsive projects come out of our department, and I’ve come to appreciate where and when responsive web design works and works well. On top of that I’ve learned how helpful front-end projects like Modernizr, MicroJS, and YepNope.js can be to any developer. That being said, it’s tough to teach an old dog new tricks and, to me, it still seemed as if their was something not quite right about responsive web design.

At this point I won’t rehash the arguments. Yes, dear dead horse, you can have a rest. Instead, I’ll focus on an article Luke Wroblewski (@lukew) wrote entitled, Responsive Design + Server Side Components.

RESS: Responsive Design + Server Side Components

For a while now I’ve felt like I was somehow out of touch for still preferring browser-detection over responsive design (like I said, I’m an old dog). I’m assuming it’s because I tend to follow front-end folks on Twitter who are very much on the responsive web design bandwagon. But between Luke’s article, Yiibu’s talk, Adaptation, as well as their Profile tool, and the news that 82% of Alexa’s top 100 properties used server-side detection to modify some amount of their content I started to feel a little less out of touch.

The principle concept that I found so intriguing in Luke’s article, as well as the work done by Yiibu, is that browser-detection can be used to help inform an overall responsive design as opposed to being the be-all-end-all for templating. By this I mean that partial pieces of content can be inserted intelligently and where appropriate (think images) into a larger layout that’s given to all browsers and is governed by responsive design principles. Hence the combining of “responsive design” and “server side components” in Luke’s name for the technique.

This isn’t something that I should consider revolutionary. On the face of it’s sort of “Duh!” but sometimes even the obvious has to be pointed out. It’s nice to see a bridge of sorts form between these two competing concepts. Their is value on both sides of the fence and they can and should work together. The question is “How?”

Implementing a RESS Solution

Luke does a good job of taking a reader through a theoretical(?) RESS solution that is based on his experiences at his start-up, Bagcheck. He shows,  quite clearly, how the server-defined partials fit in nicely with an overall responsive design. One thing that the original RESS example fails to review is how content is classified for browsers though there is a nod towards user agent detection. I was curious to see how that part of a RESS solution worked so I put together one of my own that used Mustache just like in his example and Detector.

My implementation of a RESS solution is very simple. I didn’t explore much beyond modifying some markup, adaptive images, and CSS. The first thing that I realized when I started tackling the “how” was that I was going to have to categorize browsers into classes (to be fair, Luke does mention classes). For the purposes of the example I set the browser classes to be desktop, mobile-advanced, and mobile-basic. The desktop class has “regular-sized” images, the mobile-advanced class has smaller images as well as some modified CSS, and the mobile-basic class has a very simple layout that utilizes accesskeys.

If you’re interested in how I set-up the demo and how it all works please check out the tutorial and the source. What I’d like to talk about now is how I ended up with my classifications and how I think it points to more responsive solutions on the server and not just in the browser.

Taking Feature-Detection Server-Side

Developers have been using server-side libraries & services like WURFL, DeviceAtlas, and 51Degrees.mobi to provide mobile device characteristics for ages. In that respect, server-side feature-detection is nothing new. I would propose that we update our terminology a bit though. “Device detection” seems anachronistic and, frankly, misguided to me. Who cares what a device can do if the browser, the bit we as developers actually interact with, can’t access them?  This is not to suggest that these device databases don’t contain that kind of information but rather that they include details that, for the most part, might not matter to developers. In order to get more relevant data there is one technique that server-side developers should appropriate from our front-end brethren and it’s browser feature-detection.

In his article, Cutting the Interrogation Short, Alex Russell (@slightlylate) makes an interesting proposal. He suggests, “feature tests should only ever be run when you don’t know what UA you’re running in.” This is a proposal I wholeheartedly agree with. So where to store the results of these feature tests that you want to run only once per user-agent? Alex suggests a few methods that rely on the front-end detection libraries but I would suggest that the results get stored in a server-side cache (but, hey, I’m biased). Feature test results stored on the server, using the user agent as a key, gives server-side code the ability to act on them making the server-side code that much smarter about what should be delivered. If necessary, the server-side code can always pass the list of features for a particular user agent to the browser as a cookie or a JavaScript include. Also, if tests are stored server-side the initial set of tests can be extremely robust. The developer would capture a lot of details but still have control over what gets delivered to the browser thereby optimizing the experience for their visitors. Hopefully, it could make for a “best of both worlds” scenario.

And server-side feature-detection is what is being done in my RESS demo and helping me classify browsers… well, sort of. The demo was created to help put my browser- and feature-detection library, Detector, through its paces. One of its core features is offering browser families based on definitions that combine information from traditional user agent parsing (via ua-parser-php) and information from Modernizr-based tests (full list). The families in the demo are not based purely on browser features as determined feature-detection but that’s not to say that Detector couldn’t (and it probably should) be expanded to include more information on, say, browser-window width (which is currently one of the few things it doesn’t capture) and could then rely almost exclusively on feature tests. But there’s actually one area where these cached feature tests would offer a lot of help…

It’s Not Just About Mobile Versus Desktop

RESS, server-side feature-detection, and Detector are not mobile solutions. Yes, they come from people focused on mobile-related issues but any of these options can be used in helping deliver optimized experiences to any browser. In the same way that Modernizr helps polyfill for older browsers, server-side feature-detection and RESS can and do offer similar capabilities. I’d hate to see them get pigeonholed as solutions that are only implemented by mobile developers. I believe that the combination of these techniques can offer a very robust platform for building future friendly websites and apps. That said, there is still work to do to make these solutions as robust as possible.

RESS Doesn’t Solve the Dumb Content Problem… Yet

In Next Steps of Responsive Web Design Jon Arnes Sæterås (@jonarnes) writes, “It is not only the design of the web site and the layout of content that needs to be adapted of enhanced; the idea of being responsive, adaptive and enhancing, must be implemented in the whole value chain.” His value chain contains four parts:

• Stupid Editor
• Stupid CMS
• Stupid Web Server
• Device (I’d suggest browser) assumed to be intelligent

RESS and storing feature-detection results on the server  can go a long way in making the web server smarter and giving us a better idea of just how intelligent that browser is. But even addressing those two things only means that the output is smarter. Neither solutions address how content enters the system (e.g. the editor) and how it’s stored (e.g. the CMS). For example, in the mobile-advanced layout of the demo on whom or what does it fall to properly crop & size the images?

In the same way that responsive web design made designers and front-end developers think more about how to be both mobile and future friendly I’m hopeful that RESS and server-side feature-detection can start a conversation amongst those of us focused on the server end of things (especially content management systems!) about how we can better deliver content to make those responsive web designs that much better. Can we help responsive web design evolve that much more?

Detector v0.5 has been posted to GitHub. The Detector demo site has also been updated to reflect the new version.

About Detector

Detector is a simple, PHP- and JavaScript-based browser- and feature-detection library that can adapt to new devices & browsers on its own without the need to pull from a central database of browser information. Detector dynamically creates profiles using a browser’s (mainly) unique user-agent string as a key. Using Modernizr it records the HTML5 & CSS3 features a requesting browser may or may not support. ua-parser-php is used to collect and record any useful information (like OS or device name) the user-agent string may contain.

With Detector a developer can serve the appropriate markup, stylesheets, and JavaScript to a requesting browser without being completely dependent on a front-end-only resource loader nor a browser-detection library being up-to-date. Detector can be used with a solution like Mustache to provide robust templating support.

The following are the major changes in this release:

ua-parser-php Integration

I was unhappy with the original browser detection library in Detector so I created a PHP-based pseudo-fork of the ua-parser project called ua-parser-php. It is included as a submodule of Detector and provides a much more robust classification system for browsers and mobile devices. Because of the number of attributes it parses out of a user-agent string it should give developers more flexibility when developing solutions.

Browser Families

With the new families feature in Detector developers can organize browsers that share certain traits into groupings. With families a developer can test for a browser’s grouping rather than each individual feature that browser may support when displaying content. This might be especially useful for templating solutions.

Expanded Feature Tests

Modernizr 2.5.2 has been included with this release as well as an expanded set of features including tests for cssremunit, deviceorientation, devicemotion, and lowbandwidth support. See the full list of Detector’s core tests.

Detector Wiki Added

I’ve attempted to grow the documentation for Detector beyond the original, limited README by using the wiki that comes with a GitHub repository. Content includes:

• How Detector Works
• Adding & Using Detector With Your Application
• Detector Test Tutorial
• Detector Family Tutorial
• Templating with Detector & Mustache Tutorial

Other Changes

Those are the big changes but their are a few other, minor changes:

• a configuration file for setting debug mode as well of locations of files & directories is now included
• both core and extended profiles can now be versioned
• the original layout of the files has been cleaned up some
• two simple demos, one for including a YouTube video and the other for templating, are now included
• while not a change in Detector per se, the archive of user agents now contains 170+ user agents and their associated feature tests

If you have any questions about the project please feel free to drop a line in the comments.

When talking “mobile” apps seem to get all of the attention but a mobile-optimized website is a necessity for many businesses. Any company that relies on email or social media to help spread the word about their offerings (think “web links”) really should make sure their website is easily viewable on a phone. Jason and Lyza do a fantastic job of taking a “new to mobile” developer through the various options that are available for making a website mobile-optimized (their are many!).

The book includes hands-on lessons with each chapter (including code you can download) and useful “case studies” to make it clear how each technique should be used. By covering the latest trends like Responsive Web Design and HTML5 APIs and some old school techniques like device detection and CSS-MP “Head First Mobile Web” makes a great resource for anyone looking to get into mobile web development or, like myself, looking to brush up on their skills.

What I think I appreciate most about the book, beyond the depth & practicality of the information, is Jason’s and Lyza’s frankness in the pros and cons of each solution and being clear how each can be useful. I was most struck by this in the WURFL section. A lot of time is spent talking device detection (one of my favorite mobile techniques) but they’re very clear about some of the licensing downsides to the product. They don’t just gloss over that very important issue.

It’s a surprisingly quick read considering the thickness of the book. That’s probably because, rather than being big blocks of text talking theory, it has a lot of practical examples, tips & tricks and uses a great conversational tone. This book really is designed to be, above all, practical and easy to learn from. If you’re at the start of a project and want to know what is available to you with mobile web or using web technologies (they also cover PhoneGap for making HTML-based apps) you should really pick this one up.

Update on February 11, 2012: ua-parser-php was updated to v1.0.0. The list of supported browsers and devices was greatly expanded. A number of bug fixes were also added by Bryan Shelton.

ua-parser-php is a PHP-based pseudo-port of the ua-parser project. ua-parser-php is designed to parse a user agent string and return certain properties like browser name, OS version, and, in some cases, device name. ua-parser-php utilizes the user agents regex YAML file from ua-parser but otherwise uses its own set of properties to describe a browser, OS, and device. ua-parser-php was created as a new browser-detection library for the browser- and feature-detection library Detector.

If you want, you can test your browser against ua-parser-php. As usual, the code is available on GitHub.

Usage

Using ua-parser-php is straightforward. Simply include it in your project, make the call to parse the user agent and you’ll be returned an object with various properties of the user agent. Examples follow:

<?php

    require("UAParser.php");
    $result = UA::parse();

    print $result->full;
    // -> Chrome 16.0.912/Mac OS X 10.6.8

    print $result->browserFull;
    // -> "Chrome 16.0.912"

    print $result->browser;
    // -> "Chrome"

    print $result->version;
    // -> "16.0.912"

    print $result->major;
    // -> 16 (minor, build, & revision also available)

    print $result->osFull;
    // -> "Mac OS X 10.6.8"

    print $result->os;
    // -> "Mac OS X"

    print $result->osVersion;
    // -> "10.6.8"

    print $result->osMajor;
    // -> 10 (osMinor, osBuild, & osRevision also available)

    /* 
     * in select cases the device information will also be captured
     */

    print $result->deviceFull;
    // -> "Palm Pixi 1.0"
       
    print $result->device;
    // -> "Palm Pixi"

    print $result->deviceVersion
    // -> "1.0"

    print $result->deviceMajor;
    // -> 1 (deviceMinor also available)

    /*
     * Some other generic boolean options
     */

    print $result->isMobile;
    // -> (would return true if the browser met the criteria of a mobile browser based on the user agent information)

    print $result->isMobileDevice;
    // -> (would return true if the device met the criteria of a mobile device based on the user agent information)

    print $result->isTablet;
    // -> (would return true if the device was a tablet according to the user agent information)

    print $result->isSpider;
    // -> (would return true if the device was a spider according to the user agent information)

    print $result->isComputer;
    // -> (would return true if the device was a computer according to the user agent information)

    print $result->isUIWebview;
    // -> (would return true if the user agent was from a uiwebview in ios)
?>

If you want to grab a copy of the YAML data from ua-parser each night you can use a cron job and point it at the following bit of code:

<?php

   require("UAParser.php");
   $result = UA::get();

?>

NOTE: Using this feature will overwrite a number of changes I’ve made to the user_agents_regex.yaml file included with the ua-parser-php distribution.

Credits

Thanks to the ua-parser team for making the core data available to others so we can build our own solutions.

The full note from Karine regarding her survey is below:

Hello,

I’d like to invite you to complete this short survey about the state of the mobile web (mobile websites, apps, etc.) at your institution:
higheredanalytics.com/mobile

This is the second edition of this survey and 105 of your colleagues already completed it but we need more. Its goal is to assess how colleges and universities respond to the needs of the increasing population of mobile device owners.

Please take the survey whether or not your institution has a mobile solution - as I’m trying to evaluate the current state for higher education as a whole – and not just for early adopters.

The results of this survey will be used for presentations and articles. Anybody who completes the survey will receive a copy of the executive summary of the survey report as well.

If you have any questions, please let me know. Thanks for your time and your help.

Karine

Higher Ed Mobile Web Summit
http://higheredexperts.com/mobile