I’ll be speaking at Refresh Pittsburgh (@refreshpitt) next Tuesday, May 15th at 6.30pm. I’m really excited about this talk since it’s about a new technology, Responsive Web Design + Server Side Components (RESS), that I think holds much promise as we learn to deliver complicated responsive designs while standards get firmed up. Here is 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.
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):
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.
For fans of user-agent detection I’m pleased to announce that ua-parser-php, my pseudo-port of the original Python-based ua-parser project, has now been rolled into the official ua-parser repository on GitHub. The official repo now contains JavaScript, Python, and PHP libraries for all your user-agent detection needs. We now have three folks watching over the official repository and, more importantly, the official YAML file that powers all three libraries. I’m looking forward to seeing how all three evolve.
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.
Their are two upcoming conferences that are near and dear to me that are currently looking for presentation proposals. Please think about submitting a proposal for one or, better yet, both.
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.
This morning I had the pleasure of presenting my new talk, The Future-Friendly Campus, at the .eduGuru Summit (@eduguru). The basic points of the talk are derived from the Future-Friendly manifesto and my own response to it last fall. The general idea is that we’ve reached a point where it’s going to be difficult to continue to on our current track of developing content silos and new “solutions” when our outlets are only going to continue to proliferate. Now is the time to reevaluate and the Future-Friendly manifesto provides an interesting idea of how we can move forward. If you have comments or questions please share!
In May 2010 Ethan Marcotte (@beep) wrote the seminal article, Responsive Web Design. At first I took a dim view of the piece. Most of my mobile experience at the time was in developing mobile-optimized experiences that relied on browser-detection & serving separate templates. Honestly, it worked for me as a, primarily, server-side dev and it worked well. To me, responsive web design seemed like a front-end solution that didn’t take into account many of the issues facing mobile developers… apart from screen width that is.
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.
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 browserfeature-detection.
In his article, Cutting the Interrogation Short, Alex Russell (@slightlylate) makes an interesting proposal. He suggests, ”feature tests should only ever be runwhen 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?