dmolsen.com

Slides from my Responsive Web Design Summit talk, 'Measuring Web Performance'

2013-04-06T10:00:00-04:00

On Tuesday, April 16, 2013, I was lucky enough to give the opening talk on the web performance day of RWD Summit presented by Environments for Humans. This is the short description for the talk:

Today, a web page can be delivered to desktop computers, televisions, or handheld devices like tablets or phones. While a technique like responsive design helps ensure that our web sites look good across that spectrum of devices we may forget that we need to make sure that our web sites also perform well across that same spectrum. More and more of our users are shifting their Internet usage to these more varied platforms and connection speeds with some moving entirely to mobile Internet.

In this session we’ll look at the tools that can help you understand, measure and improve the web performance of your web sites and applications. The talk will also discuss how new server-side techniques might help us optimize our front-end performance. Finally, since the best way to test is to have devices in your hand, we’ll discuss some tips for getting your hands on them cheaply.

This presentation builds upon Dave’s “Optimization for Mobile” chapter in Smashing Magazine’s ”The Mobile Book.”

So here is the deck embedded into the post for your convenience:

Measuring Web Performance from Dave Olsen

Questions about the deck? Want me to give this talk at your conference or meet-up? Check out my contact info or hit me up at @dmolsen on Twitter.

Going Old School With Command Line Interfaces for Managing Your Web Apps

2013-04-06T10:00:00-04:00

My last few projects for West Virginia University have been super simple. In order to keep the back-end management of the projects simple as well I’ve started writing command line interfaces as opposed to web-based ones. My interest in using command line tools is based on the work I did with the PHP library for ua-parser. For that project I wanted to give developers a simple way to cron out updates to the regexes.yaml file. It seemed natural for me to take that experience and use it in my day-to-day work.

The Benefits of Moving to the Command Line

Moving to command line interfaces for these projects has given me four wins:

A lot less code. Authentication code? Gone. Templates? Nuked. SSL-enabled hostnames? Don’t have to worry about it. All of the cruft that is needed to host a secure admin web interface doesn’t have to be written. It’s faster to get up and running as well as faster to modify.
Simpler security. The security model now becomes one of access to the server and file. The important caveat here being that your command line utility should be outside of the document root for your website.
Better documentation. Because the interface consists of flags (e.g. -f) I have to make sure I provide help documentation in case anyone else needs to use them. It also helps me since I forget them after a while too. The makes for a better solution all around.
Cron-friendly. Because the interfaces are written to be accessed and report to the command line it makes it very easy to cron reports and functionality (e.g. getting an updated file from a remote server each day)

The Downside to Moving to the Command Line

“But,” you might ask, ”don’t you become a bottleneck for administering these projects?” I think the natural assumption is that now I can’t easily hand off responsibility to anyone else. My experience in the past has been that clients won’t, for the most part, take responsibility if they can avoid it anyway. Regardless, the people who would need to pick up the project all have access to the servers so no one is actually locked out. Also, with the documentation built-in hopefully it’s straightforward for them to address any issues.

That said, if you’re the one and only one who has access to the server or you keep the tool local then, yes, you will be a bottleneck. Understand if the trade-off is worth it.

A Simple Command Line Utility Example Written in PHP

The following is a simple example of what a command line tool might look like if it were built with PHP. By the way, this is one place where I think PHP really excels but lots of frameworks come with similar tools. You could also make your command line tool even more interactive (e.g. ask yes/no questions or similar) but I didn’t cover that in the example. See the example on GitHub.

Generating an Access Token for Instagram

2013-04-05T10:00:00-04:00

One of the hotter social networks in higher education is Instagram. As a developer you might find yourself needing to pull photos into a website using Instagram’s API like we did when we recently added Instagram photos to our central social networking website, Connect with WVU. As with many APIs Instagram requires authentication to access many of its end-points. This is fine but unfortunately the service makes the assumption that you are going to access the end-points on behalf of a particular user that has had the opportunity to give an application permission to access their information. This isn’t always the case. Especially when you simply want to access the service to pull your own user’s information via a small script.

Our Set-up

In our situation we have a social network data collection service that queries the Instagram API every 10 minutes to get the latest photos that have been posted to our WestVirginiaU account. The info is saved to a SQLite database. When users hit connect.wvu.edu a request is made to this service to retrieve the latest information (along with Facebook, Twitter, Google+, YouTube and foursquare data) from the SQLite database.

The trick is that the service simply needs to make requests as the primary account but has no way to login to authenticate and get an an access token for Instagram. A service like Twitter gets this particular use case correct in that they allow you to generate an access token via their developer admin. Instagram doesn’t have this feature yet. Hopefully they add it. For now you can do the following.

Generating an Access Token for Instagram

Generating a token to be used in your application is actually fairly straightforward once you know the magical incantation. Just do the following:

Write down the client ID, client secret, and redirect URI for the client you want to generate an access token for. You can find it on the “Manage Clients” panel in the Instagram Developer’s site.
Visit the following address replacing the client ID and the redirect URI:
When prompted choose “Yes” to authorize the app
You’ll be redirected to the redirect URI you supplied. At the end of the address you’ll see a request variable called code. Copy the value.
Open Terminal (or favorite command line tool). Copy and paste the following. Replace the appropriate values:
Copy the access token from the returned JSON object.

It should also be noted that the generated access token can still expire. It shouldn’t expire in the near-term but it’s not permanent.

Media Query-less Design, Content-based Breakpoints & Tweakpoints

2013-03-05T10:00:00-05:00

This post is a follow-up to Lessons Learned Building the New dmolsen.com: Static, A Performance Budget, Sass & SVG. The previous post focused on my technical choices in the re-design of dmolsen.com. This post focuses on my design choices.

I had two popular quotes floating around in my head as I moved my design for the new dmolsen.com from the sketchpad to the browser. The first quote was from Bryan Rieger (@bryanrieger):

@zomigi the first media query is actually the absence of support for media queries.
— Bryan Rieger (@bryanrieger) December 1, 2011

The second quote was from Stephen Hay (@stephenhay) (sorry, I could only find Brad’s version of the quote):

start with the small screen first, then expand until it looks like shit. TIME FOR A BREAKPOINT! @stephenhay #bdconf
— Brad Frost (@brad_frost) April 16, 2012

These two quotes led to the foundational design concepts that guided the implementation of the new layout. The first concept, that the site should work without media queries, was surprisingly natural to implement. The second concept, that content alone would determine the layout’s breakpoints, has had a much larger influence on me than I expected. Both with regards to this particular layout as well as in how I think about and approach responsive design in general.

Media Query-less Design

It’s become the norm to approach responsive design from a “mobile layout first” perspective. Essentially, your base styles should be the mobile ones and then you should work your way “up” towards desktop screen sizes via the use of media queries that incorporate min-width rules. I would argue that instead we should be working from the base styles for a design and then only use media queries to tweak those base styles at breakpoints. This leads to an easy-to-understand progression of styles that either build on each other or only slightly modify each other. A small, Sass-ified example of this from my new layout:

For me this was a much more straightforward way of looking at my layout decisions. It’s all the same layout regardless of viewport size but their may be some simple and minor variations.

The other benefit of this style is that the media query itself becomes a feature test by separating those browsers that might understand certain CSS properties versus older browsers that might not. So older IE support was essentially baked in based on approaching the whole layout as “media query-less”. IE and similar browsers have a layout that works but we can still use “cooler” CSS features without much fuss. Yes, Virginia, this is progressive enhancement. It did highlight one area where min-width based queries might not be usable though and that’s navigation.

I made liberal use of nth-child() in the CSS for my navigation on smaller screen sizes. IE would choke on this so this is one area where I ended up using a media query with max-width. So in this case the larger screen styles are set to the default and then pared down based on breakpoint.

Admittedly, I’m working with a really simple two-column layout so my CSS should never get all that crazy. Even two-columns can cause their own issues when we decide to set breakpoints based on content though.

Content-based Breakpoints

For such a simple concept this decision was a surprisingly scary one to me. By their very nature fluid layouts mean that we must give up a certain amount of control but implementing breakpoints based on device width returns a certain level of comfort or certainty. You can say to yourself:

I’m totally not going to use device detection but if I set my breakpoint at 768px my site will look like this on an iPad. No worries.

Trusting that your content will just happen to look acceptable everywhere based on simply flexing a browser window, marking breakpoints, and then using ems (not even px) to describe breakpoints… I had some trepidation to say the least.

At the end of the process I found content-based breakpoints to be surprisingly liberating for three reasons:

One simple rule to decide breakpoints: line length. Line length look a little short or long? Breakpoint. Otherwise things are kosher. There’s even a Golden Ratio Typography Calculator though I didn’t use it.
Layout moves away from being fixed and focused at the page level and instead one must think in containers and sub-containers. This leads to a lot of minor but important optimizations which seem to be picking up the name “tweakpoints.”
Testing became sort of a joke because the final layouts seemed to Just Work™. Again, the caveats being that this is a simple layout and I had already employed my 50K budget so I didn’t have to worry that much about performance.

The move from thinking about an overall layout to thinking about containers and sub-containers and their related tweakpoints is one of my more exciting take-aways from this project.

Tweakpoints

I’m not the first to hit on this but I’m glad the issue seems to be picking up ink these last few weeks. It’s such a natural progression of the process. Mark Boulton (@markboulton), Ben Callahan (@bencallahan), and Jeremy Keith (@adactio) expand on this idea better than I can with The In-Between, There is No Breakpoint, and Tweakpoints respectively.

I’d like to highlight the primary example in which tweakpoints, or at least what I’m thinking of as tweakpoints, are used in this layout. The primary container for the page, #main-container, has one breakpoint at 52.5em. Below that breakpoint the layout for the container is a single column and above that it’s two column.

The decision to break is driven primarily by the line length for the .sidebar container. Once the length gets too short I drop it below .content. Within the .sidebar container though we have another layout decision. Now that the width is set to 100% the line length is too long and the image of the book awkwardly floats in a sea of grey.

I couldn’t do a ton about the overall line length but I could address the image. This, to me, is a tweakpoint. I’m addressing a minor issue with a sub-container and tweaking the layout of content in that container only. In this case, the paragraph containing the book text gets floated left and the book image gets floated right. This only works for so long though. The line length gets too short again for the book text. Once that happens the sub-container is tweaked again and the text is again stacked at 31.25em.

Wrapping It Up

As I’ve said a few times, this isn’t the most complicated layout on the planet but I do think some of the lessons learned here will help me as I tackle more complicated responsive projects. Content-driven layout can be quite the rabbit hole but I think the more you tweak simply based on a squishy browser window the less testing for specific devices you’ll need. You can feel a little better that your content will go and flow in a predictable and usable fashion.

Lessons Learned Building the New dmolsen.com: Static, A Performance Budget, Sass & SVG

2013-02-25T14:10:00-05:00

Building off of my Re-introduction post I wanted to share some of the things that I learned as I built the new, responsive edition of dmolsen.com. I figure that my experience with doing this might provide some insight to other folks looking to integrate new techniques and technology into their own projects. The source for the site is on GitHub. All projects start with requirements…

Dropping WordPress & Going Static with Octopress

I’ve been toying with the idea of dropping WordPress for a while. While it was easy to get up and running it never seemed like it was a good fit for me. It has to be updated constantly, the post editor is a serious pain in the ass, and it sucks down RAM. Between not really getting enough traffic to justify my RAM-driven hosting costs and the fact that the post creation process was more of a hinderance than a help I decided to make a big change with this redesign. Out went WordPress and in came old-school static HTML.

One big plus of using a CMS like WordPress though is having the ability to use templates. To make sure I still had this feature I looked for a good static site generator. It would give me the flat files I wanted but, hopefully, make it easier to maintain my site. I finally settled on Octopress.

To be clear, Octopress definitely has its own drawbacks. Upgrading Ruby on my Mac was a serious headache and I’m not a big fan of Liquid-based templates. That said, I feel like I’m back in control of every aspect of my site. I was able to quickly stub out my own templates and design. I can now write my posts in Markdown, a format I love, and I can write whenever I have the desire too because the files are all local to my computer.

The 50K Performance Budget

The second major decision was setting my performance budget for the basic template for the site. Both Tim Kadlec (@timkadlec) and Clearleft (@clearleft) have written on this topic recently. See Setting a Performance Budget and Responsive Design on a Budget respectively. This is a technique that our team had used for our 2011 responsive holiday card website (sadly, it’s is no longer online). The budget for that had been 100K. For this site I wanted it to be 50K. A very aggressive goal but, hey, why not?

If you don’t count web fonts the basic template easily fits within my 50K budget. My CSS, JavaScript, images, and mark-up only add up to 39K. Cut out Google Analytics and Gaug.es and the page weight drops to 23K. Unfortunately, I’m a sucker for web fonts. Because of my lack of design skills as well as the large blocks of text that naturally make up a blog I knew type was going to have to be an important visual component of my site.

I ended up using two fonts, Roboto and Roboto Condensed, that total 69K. Combining that number with the other assets the total weight for the basic template for my site ends up being around 109K.

Did I blow my budget by including the fonts? Sure. But performance optimization is, like many things, a compromise. The type face makes a huge difference, I think. The 50K goal was completely arbitrary and aggressive but having a tight ceiling made me think more critically about design and feature choices. In the future my performance budgets will also include things like total number of requests and a max time-to-document-ready threshold.

Sass is Snazzy

Sass, a CSS pre-processer, has blown up in our office. Between being baked into our new CMS, a Build Responsively workshop, and the introduction of CodeKit it seems like everyone here is using it. I hadn’t had the opportunity to use it but, since it is included as part of Octopress, I figured I’d give it a whirl. I love it. Here is how it helped me:

Being able to have a large number of SCSS files organized by which region of the page the styles affected that get merged into one file in production made the whole process of remembering where styles were and tweaking them that much faster and easier.
Variables meant that I could tweak a breakpoint and be assured every element affected by the change would be updated.
Nesting reduced what I had to type and, again, helped me organize my styles better.
I only used one mixin in my project but I can see how, for example if you needed to create cross-platform gradients, it could make your life a whole lot easier.

My site is simple and I barely scratched the surface of what Sass can do. And, to be clear, you don’t have to use Octopress to take advantage of Sass.

SVG: A Different Kind of Logo

One of the challenges that I set for myself when I started redesigning this site was to try to create a logo that required only CSS. Unfortunately, using CSS to clip text to a circle isn’t very well-supported across browsers. Once I had settled on the clipped look, though, I really wanted it so I looked at another solution, SVG. Within two hours I went from basically not knowing anything about SVG to the hot logo that you see today. It’s really just a simple text file with a linked web font.

While straightforward to build I don’t think I’ve made the best use of SVG. The web font works on most SVG-supporting browsers but fails, for example, on the default browser on Android 4.2. This results in a shortened logo. Also, by linking to a web font I took what is a nicely performant 0.7K text file and essentially turned it into an 18K text file-web font combo. An image would be way better in this case. That said, I think SVG offers promise as a format. Being high-DPI and responsive-layout friendly are definite plusses. By the way, take a look at the source for the header and you can see how I provide a fallback for browsers that don’t support SVG at all.

If you’re interested in learning more about SVG and how you might be able to take advantage of it check out David Bushell’s (@dbushell) two SVG articles, A Primer to Front-end SVG Hacking and Resolution Independence with SVG.

Other Interesting Bits

This post is getting quite long! Some other things that I found useful/interesting as I put together the new version of my site:

HTML5: Rather than use a JavaScript solution for backwards compatibility you might notice that I actually use <divs> nested within the HTML5 elements. All of my styles hook into these elements. It’s not the most semantic solution but relying on JavaScript seemed odd to me.
nth-child(): This pseudo-selector melted my brain for a little bit (for the son of a math teacher I really suck at math) but once I got a handle on it was incredible useful. The navigation at small viewports is completely driven by nth-child(). Chris Coyier (@chriscoyier) has a great write-up about it on CSS Tricks.
:before & :after combined with ‘content’: I had no idea the CSS property content even existed. Again, Chris Coyier with a good overview. The bars in the nav and pips for lists use it. Blockquote also uses content but it uses the open-quote value. Note, if you use the open-quote value make sure blockquote:after is set to content: no-close-quote so that other <blockquote>s get the appropriate type of opening quote.
HTML5 Canvas: One requirement that I gave myself was that the image on the right must randomly change when the site is being viewed in larger viewports. What better way to achieve this than canvas? After some false starts I ended up using toDataURL() and background-image (the JavaScript). If you look at the source for this page you’ll see a lot of random gibberish in the #canvas-container div. That’s that image.
@-ms-viewport: Last but not least is the use of the @-ms-viewport rule for Windows RT. Tim Kadlec recently did a good write-up about issues with IE10 on Windows RT, IE10 Snap Mode and Responsive Design. I found it really useful for getting IE10 to properly register the viewport on device rotation.

Wrapping It Up

This article is primarily about the requirements that I set up for myself as I developed the new version of this site as well as some of the technical features I implemented. What’s missing is anything that is really about responsive design. Their is now a follow-up post, Media Query-less Design, Content-based Breakpoints & Tweakpoints.

A Re-introduction

2013-02-25T14:00:00-05:00

I haven’t written anything of any serious consequence for this blog in seven or eight months. Obviously, a lot of my available writing time was spent on my chapter for Smashing Mag’s The Mobile Book but I had another reason for the long hiatus. The Mobile in Higher Ed “brand” left me feeling a little hemmed in regarding the topics I could cover. Or, at least, the topics that I originally thought I should cover.

In early 2012 I started building a lot of tools (see Detector, Throttle & ua-parser-php). This blog seemed to simply became a series of posts related to tool updates. Frankly, to me, that was sort of boring and not befitting of the original mission of the blog so I stopped writing them. For example, I never posted about another tool that I developed, lazyBlock.

Ultimately, the problem was that I put too much pressure on myself to produce a certain type of content and, when the inspiration never came, I just plain avoided the site and writing. So, in the same way that my Twitter account is “just me,” I sort of have to accept that my blog will also be “just me” and reflect my interests in the moment.

The redesign of my blog reflects this change in thinking. Gone are references to Mobile in Higher Ed. I now feel like I don’t have to keep every post within those two constraints, Mobile and Higher Ed, which was part of what was contributing to my writer’s block. I will have my tool updates, their will be posts about mobile web-related technology and their will be higher ed-related content. It’s just that now I know I don’t have to fit all of those things into one post.

Thank you for sticking with the blog through the lean times. I hope I can reward that loyalty moving forward. If you’re interested in the behind-the-scenes of the re-making of the blog check out the other new post today, Lessons Learned Building the New dmolsen.com: Static, A Performance Budget, Sass & SVG.

Talking Mobile Web Performance & RESS in Smashing Magazine’s “The Mobile Book”

2012-11-08T00:00:00-05:00

Later this month or in early December you’ll be able to read my contribution to Smashing Magazine’s (@smashingmag) latest printed piece, ”The Mobile Book.” I’m honored to have been asked to join a fantastic line-up of writers and then given the freedom to write a chapter about a topic that I think is important in this age of the always connected device, web performance. The short description:

Although Responsive design per se has provided a great fundamental concept for designing mobile-optimized websites, the core ideas that make up these concepts pre-date the mobile revolution. In this chapter, Dave Olsen reviews what it takes to optimize mobile experiences in terms of performance. How do we keep responsive websites lightweight? What do we need to know about caching, lazy loading, latency? How can we start using RESS? Device detection or feature detection? Also, how do we develop and test our websites for performance? This chapter answers all these questions and more.

The contributors to the book are a Who’s Who list of the leaders in the mobile web space. Smashing Magazine provides a handy Twitter list of authors but they are:

Jeremy Keith (@adactio) with the foreword
Peter Paul-Koch (@ppk) covering ”What’s Going on in Mobile?”
Stephanie Rieger (@stephanierieger) covering ”The Future of Mobile”
Trent Walton (@TrentWalton) covering ”Responsive Design Strategies”
Brad Frost (@brad_frost) covering ”Responsive Design Patterns”
Dennis Kardys (@dkardys) covering ”Hands On Design for Mobile (UX Perspective)”
Greg Nudelman (@designcaffeine) & Rian van der Merwe (@RianVDM) covering ”Mobile UX Design Patterns”
Josh Clark (@globalmoxie) covering ”Designing With Gestures and Touch”

Smashing Magazine put together some more information on the book as well as more details on each chapter.

Many thanks to Vitaly Friedman for giving me the opportunity to contribute to the book. Also, thanks to him and the rest of the gang at Smashing Magazine for their work editing and proofing the chapter as well as gently shepherding me across the finish line. Thanks to Tim Kadlec (@tkadlec) for his quality technical edits.

If you pre-order the book you’ll save 20% and get the eBook for free. Frankly, the book looks gorgeous (thanks to illustrations from Mike Kus (@mikekus)) and I know the content will be awesome so go order it today.

Detector v0.8.5 Released: Now Being Used on www.wvu.edu

2012-08-14T00:00:00-04:00

With the release of the new home page for West Virginia University Detector is finally being used in production. Unfortunately, there were a few bugs that were uncovered with this move. v0.8.5 fixes these issues and I now feel comfortable most folks can use Detector in their own production environments. The issues fixed include:

a very rare bug where the cookie used to set-up a profile wasn’t properly cleared so a future visit would overwrite the profile with empty data.
the call to addUAToList() is now commented out. it became an unnecessary performance bottleneck.
profiles are now saved in directories that are based on the first two characters of the hash of the user-agent. this way one directory doesn’t fill up with a ton of files and thereby possibly affecting performance. more on this below.

But it’s not all bug fixes…

New Feature: Smarter Mustache Templating

One feature that I’m really excited about is the smarter fallbacks when using Detector with my fork of mustache-php (included in the Detector project). When using Detector and mustache-php to build a RESS-based website you can organize your Mustache partials based on Detector’s families feature. Essentially, Mustache looks for partials based on the browser’s family first and then fallbacks to a default directory of partials that’s shared amongst all the families. I’ve written a tutorial that explains how it all works.

With v0.8.5 I’ve added a wrinkle to that default behavior. If you set splitFamily to true in config.ini Mustache will still look for a partial based on the browser’s family first but then it will attempt to split the family name based on dashes rather than falling back to a default directory. This should give developers more flexibility when setting up families as well as limit duplicated partials. At least it did for us. A good example of how this feature might be useful is for delivering Retina images.

For the most part, the partials shared between a family set-up to address the layout needs of a Retina-capable mobile browser and the partials for a family set-up to address the layout needs of a modern mobile browser will be the same. Rather than duplicate these partials we can, with this new feature, simply set-up our Retina-quality family so that its name builds off of the latter family name. For example, the family name for the regular modern mobile browser might be ‘mobile-advanced’. We can then name our Retina-related family ‘mobile-advanced-retina’. Any partials shared between the two simply need to go in ‘mobile-advanced’ as partial requests that aren’t found in ‘mobile-advanced-retina’ will fall back to it first.

Early Stats

I’ve been very curious how Detector would perform once it was thrown into production. Most importantly, I wanted to know how many profiles it would create once a lot of different browsers could hit it. Performance has been fine. The profile numbers on the other hand have blown me away and they’re almost entirely driven by IE 7 and 8. Since we launched at midnight on Thursday, August 2nd our home page has had ~72,000 unique visitors and ~238,000 pageviews. This is a slow time of year for us though our traffic should ramp up quickly. Based on those ~72,000 unique visitors Detector has created 11,002 profiles. They take up 45MB of disk space. The kicker really is IE 7 & 8. Combined, IE 7 & 8 account for 7,952 of the 11,002 profiles (72.3%) . I find it incredible that there’s that much variation in IE user-agent strings. I guess Microsoft allowed anything to be stuck in the UA. For what it’s worth, IE 7 & 8 have only provided 25% of the visits during the same time period.

I’ll be keeping an eye on the disk usage. Maybe I’ll need to think about a garbage collection routine for old profiles. Otherwise things seem to be working well.

Introducing Throttle: Helping You Test Your Websites at Mobile Network Speeds (aka Slooowwww)

2012-07-10T00:00:00-04:00

As I noted at the end of my last post, How to Build a Device Lab, getting devices is only half of the battle when trying to create a robust platform for testing your mobile websites. The other half is finding tools that allow you to test your websites quickly and easily. While reviewing tools the one thing that stuck out to me was that we were running tests from our devices over an, essentially, pristine WiFi connection. In the real world, our users would be stuck on clogged networks with varying levels of quality. Guy Podjarny’s (@guypod) presentation, The Mobile Difference In Numbers, does a good job of showing why we need to take network performance into account when designing our mobile websites. Therefore, modifying network speeds would need to play a larger part in our testing scenarios if we really wanted to know how well our mobile designs were working.

All of the tools that I found related to modifying connection speeds were focused on modifying the requests coming from only one computer. e.g. You’d have the piece of software installed on your computer and any request you made from that computer would be affected. When testing multiple, black-boxed devices (e.g. an iPhone, a Google Nexus, and a BlackBerry 9800) this scenario wouldn’t work. So doing what I do tend to do I built my own solution. Because of how shim and Adobe Shadow work I decided to use an extra Mac that we had lying around as a WiFi access point. That way we could still use those tools and I could control the network speeds of the requests coming from our devices. Also, if it was set-up correctly, any of our designers could sit at their desks, testing and modifying their code, and update the network speed “on the fly.” So with that…

Introducing Throttle

Throttle, available on GitHub, is a simple node.js app that allows you to simulate poor network connections (e.g. like a cellular connection) so you can test how your websites will perform. For example, testing a responsive website on a poor 3G connection without actually having to have a poor 3G connection. To use Throttle simply connect your Mac to ethernet, share that network connection via Airport, turn on Throttle, and any device connected to that WiFi access point will then be throttled to the the network speed you specify via a web-frontend. If you don’t have node.js on your computer don’t fret. It’s very easy to install so you can get Throttle up and running quickly.

It’s important to note that Throttle was designed to be used in conjunction with a device lab and products like shim or Adobe Shadow where a shared connection is expected. That has definitely influenced its design and test cases.

Throttle has some very simple features:

Web-based app so it can be accessed & updated from any connected device or computer
Modify download network speeds for connected devices
Modify upload network speeds for connected devices
Modify the latency, or delay, in the network connection for connected devices
Handy presets to quickly switch between network types
The machine Throttle is installed on still has a full-speed Internet connection
Works nicely with Adobe Shadow. I want it to get it to work with a stock install of shim.

Directions for setting up and using Throttle are now available on the project’s GitHub repo. You can check out a screenshot to see what you’ll be getting if you install Throttle. Throttle started out as a hack to shim so thanks to that project and the team at Boston Globe for the inspiration. Throttle uses Twitter Bootstrap and Glyphicons for design elements.

If you have any suggestions, criticisms or thoughts on Throttle please feel free to share them in the comments. I’m hopeful that I can get the current presets updated to appropriately reflect common connection speeds. I’m definitely open to suggestions for making that part of the system better.

How to Build a Device Lab [Part 1]

2012-06-26T00:00:00-04:00

Recently, we were lucky enough to be given the opportunity to build a device lab for our department. Stephanie Rieger (@stephanierieger) covers the many reasons why organizations need to get their hands on real devices for testing. As mobile becomes an increasingly important outlet for our content it behooves us to make sure that content actually works on them. Over the years we had picked up a few devices but this was a chance to ”do it right” and we jumped at it.

Deciding Which Devices to Get

We took a fairly pragmatic stance when deciding what devices we should get for our device lab. We evaluated devices based on the following criteria:

Rank: where was the device ranked in our stats for wvu.edu. this can be found in Google Analytics under the “Mobile” category.
OS & OS Version: we wanted a good cross-section of OSes
Screen Dimensions: again, we wanted a good cross-section of screen dimensions
WiFi-Capable: the device had to be WiFi-capable so we could use the device without a cellphone plan. this was a critical feature of any device we considered.
Availability & Cost: and, finally, the device had to be available for purchase and not overly expensive. this ruled out the latest and greatest.

I think we ended up meeting our goals on OS and screen dimensions. Our lab now includes devices running Windows Phone 7, webOS, BlackBerry 5, 6 & 7, Nokia Series 40 as well as various flavors of iOS and Android. If you’re just starting your device lab I would rank devices as so:

iPod Touch: as long as you aren’t doing anything with GPS this could be a cost-effective choice for iOS & small screen testing. ~~no retina display though~~. it does have a retina display. if someone knows of a reason why this wouldn’t work please let me know.
Mid-level Android: target something like the Samsung Fascinate that can only run 2.x of Android
High-end Android: an HTC Thunderbolt (maybe not so high-end anymore) or another device capable of running Android 4.0. make sure to get a different screen pixel width/height than your mid-level device.
iPad/Android/Kindle Tablet: i’m sort of loathe to add a tablet to the list but it could matter if you’re into that kind of thing. an iPad will probably be your most expensive device though you can get a refurbished iPad 2 if you don’t care about retina.
High-end BlackBerry: any BlackBerry that can run 7.0 (e.g. BlackBerry 9900)
Windows Phone 7: if only to experience something really different when it comes to a mobile OS. can be older model since none of the current hardware will support the next edition of Windows Phone anyway.

I think you can fill in as necessary after that based on your audience. Depending on where you are in the world you may want a Symbian-based or Bada-based device. If you know you have a number of important administrators with older BlackBerries pick up a 6.0 device. Android devices offer a lot of options for testing responsive designs with their varied screen widths and heights. Obviously, you might want to pick up an iPhone for testing ~~its Retina Display~~ (can do this on the iPod Touch). More is better but you don’t have to kill yourself getting the perfect combo of devices. Especially if that’s what’s keeping you from jumping in.

And, remember, you can always check out emulators for any of the devices you can’t get your hands on or you can look at web-based device testings services like BrowserStack. Ryan Seddon (@ryanseddon) put together a good post that covers some of the options in the latter category.

Where To Get Devices

Once you’ve decided what type of devices you want then the obvious next step is getting your hands on some. I think their are four ways to go about this:

Hand-me-downs: this is probably the most common method to pick up devices. Someone in your department is due for a refresh on their phone and they give you their old device. Makes the device free to you but takes time to build up a significant library and, if your department is like ours, most folks tend to get the same device so when the refresh happens you’re stuck with multiples of the same device.
Cellphone Store Leftovers: you should be able to go into your local cellphone dealers and ask if they have older devices that you can purchase at a discount. This will usually range from 25-50% off. The problem is, if you’re in a smaller market like us, the leftovers may provide very slim pickings.
eBay: every device you might ever want for your lab is on eBay. This could be a good way to get some devices on the cheap.
Mobile Karma: Mobile Karma buys and then re-sells used devices. They don’t have the widest selection and their list of devices is definitely US-centric but, that said, I think it’s a more than good enough resource for building a starter device lab. Also, if you see a device one day don’t expect it to be there the next. All the devices they provide come in very good condition and include chargers and extra batteries. Do compare the prices they show against those you can find on eBay.

Trolling eBay and Mobile Karma should show that you don’t have to break the bank to start building a device lab. Especially if you limit yourself to devices 1-3 from my list above. An iPod Touch (refurbished) from the Apple Store and a Fascinate and Thunderbolt from Mobile Karma are, combined, only $438. And there are no contract costs with those Android phones!

Dealing with Activation Issues

Using your new devices won’t be as simple as turning them on, connecting to a WiFi network, and firing up the browser. All of them would/should have been reset to their factory defaults meaning you’re going to have to activate them but without a cellphone plan. Not every device likes this. For example, with the Palm Pre 2 you’ll have to get it to run in dev mode via entering a code in the emergency number screen. Other devices will have other ways to skip activation (e.g. using the volume keys). You’ll also want to come up with one central account (most likely Gmail-based) that can be used to create accounts across all of the various app stores.

Activation issues can be overcome… just don’t be surprised by this step.

And, please note, you don’t have to provide a credit card when creating a centralized iTunes account. You can download free apps without one on record so you can skip that step if that’s an issue. Then you can use that account for all of your iOS testing devices.

Managing Your Devices

When I asked on Twitter, ”Got any questions about setting a device lab?,” the number one question was related to how to share purchased devices with other departments. To be honest, we haven’t gotten that far yet. We’re currently working on how to make sharing within the department easy. After that we can look outwards. I have a feeling we won’t be loaning out devices. Does that sound mean? Sure. Is it more practical for us? Yes. This doesn’t mean that folks couldn’t visit us to test of course. The bonus of that is that they then have some experts to help them troubleshoot any problems.

Another question was ”When should we retire a particular device?” At this point I think their is something to be learned from testing even if it’s on an older device (e.g. BlackBerry 5.0). If a design is completely screwed up on an OS like that and your stats show almost no visits from that operating system/browser then it’s OK to ignore but, otherwise, the more you can cover the better. And, again, their is always something to be learned from older platforms.

Other Things to Buy

Unfortunately, devices are only part of the cost in setting up a lab. This is especially true if, like us, you want to set-up a mobile device lab. Where “mobile” means allowing the device lab to easily move around to different cubes or offices. You should think about picking up the following:

Power strips: you’ll need to plug-in the devices somewhere. you don’t need an outlet for every device but you’ll most likely need to expand on the outlets you already have.
Stands: you’ll want something to place your devices on so they can sit at an angle and be easily viewable by the designer/developer as they’re testing. testing, courtesy of something like Adobe Shadow, can be as simple as ”refresh a desktop browser & all of your mobile devices (based on WebKit) refresh with it automagically.” serious.
Cart: you’ll need something to put the devices on to move ‘em around.
Source of WiFi: can be an access point or, if using SHIM, you’ll want an extra computer that maybe has been sitting around collecting dust

We’re still in the process of fleshing this part out so I don’t have numbers but it shouldn’t be overwhelming budget-wise.

Getting Devices Is Only Half the Battle: Browser Testing

Getting devices into the hands of your developers and designers is only the first step in integrating device testing into your website design routine. In order to get folks to buy-in it has to be easy. Very, very easy. This is one of the reasons we want the cart. We hope that, by using the devices in their familiar environments (e.g. their own cubes), it will encourage them to test more. The other point is that what we’re really interested in on these devices are the browsers. In my next article I’ll talk about what browsers you might want to target and how you can use a combination of Adobe Shadow, SHIM, and ipfw to make it dead-simple for developers to robustly test and tweak their mobile designs in those browsers.

Have your own tips for setting up a device lab? Any other questions I can answer? Please submit a comment!

Help Needed: Reviewing & Updating Detector’s Feature & Test Suite

2012-06-19T00:00:00-04:00

As I push towards the v1.0 release of Detector I’ve decided to focus on refining the list of tests that form the core of Detector’s ”browser map.” My original listing of tests was cherry-picked from Modernizr’s “build tool.” While a useful listing it doesn’t cover every feature that may be of interest to developers. Especially, as I found, those developers primarily interested in mobile.

The draft listing of Detector’s v1.0 tests is available as a Google Doc. I wasn’t sure of the best way to leave feedback so I guess you can either reply to this post or put your comments in the “User Contributed Notes” section of each sheet. The primary criteria for a listed test is simply my own interest in that particular feature. The only type of tests that I’ve ruled out for now are ones that simply test browser performance (e.g. FPS).

The listing was built using the following resources:

Modernizr’s core tests & extra tests listed in their repo
Ringmark’s core tests
The When I Can I Use tests

In locations where I’ve listed that a test doesn’t exist (primarily Modernizr) I simply mean that it’s not included in the official repo for that library. It could exist elsewhere. Ringmark didn’t contain every test I expected (e.g. battery) so maybe I overlooked something there as well. Suffice it to say it’s been a few late nights.

I also referred to the following material as reference:

To explain the organization of the sheets a little bit… Each sheet is my attempt to organize tests into logical groups. There is overlap. The most important column is B as that determines what’s happening with a particular test. The key is included at the bottom of each sheet.

I would love feedback on the list. Suggestions of tests to include or remove are very much welcome. I know the doc is overwhelming but I wanted to record as much information as I could while doing this process rather than have to look up things later on. I haven’t looked at performance issues yet, fine-tuned tests, or anything as I’m simply trying to decide if the features could prove useful to developers and act as a quality snapshot of a UA. All of that will come as I narrow down what will be in the v1.0 test suite.

Thanks.

Detector v0.8.0 Released: Modernizr for Your PHP App Now Cleaner, Leaner, & Meaner

2012-06-04T00:00:00-04:00

In preparation for some summer projects I cleaned up my PHP & Modernizr-based browser- and feature-detection library, Detector. You can get a taste of what it can do by visiting the feature list page or checking out the RESS template demo. The code and feature-set are essentially where I want them to be for 1.0. I could stand to add proper unit tests and the like. I’ll attempt to add them in the near future but my schedule is getting really busy. The highlights for this release include:

a better job of handling browsers that don’t support JavaScript or cookies. This extends to customizable family properties for those same browsers as well as search engine bots. Learn more in the docs.
the ability to change the family property for a browser via a request variable. For responsive designs this could mean “desktop” mode. Learn more in the docs.
Modernizr-based tests can now be run once per-session for those features that need to be tested on a per browser basis but won’t change in subsequent requests (e.g. pixel density ratio). Learn more in the docs.
in general I’ve tried to DRY up the code & reduce memory footprint

On the face of it it doesn’t seem like a whole lot happened. More changes are listed in the CHANGELOG. This release, in my opinion, makes Detector a robust and flexible library that brings PHP developers that much closer to their front-end brethren. Now we can build dynamic, future-friendly applications that can take advantage of browser properties server-side.

The Cautionary Tale of “The Expert Has Spoken:” Jakob Nielsen & the Mobile Site Debate

2012-05-23T00:00:00-04:00

In higher education we really like “best practices.” We like solutions that are proven and that we can easily implement as we dip our toes into new technologies. I’ve watched this happen with social media and I’m now experiencing it with mobile. Part of the reason we try to find and follow “best practices” is our need to get the most bang for the buck. Another part of it is the fact that many of us wear so many hats that we need to rely on “experts.” Lastly, I think another part of it is that for so long we’ve seen our industry as behind-the-times that, yet again, we must be behind with this technology and therefore there must be guidelines to follow; things we can follow to “get it right.” Here’s what I’ve learned about mobile though…

Everyone, in every industry is figuring this out at the same time, it’s fucking messy, and, for the most part, anyone spouting off about any particular solution as being “the right way” is full of it. And the reason they’re full of it? One size doesn’t fit all (no matter what it might say on the package).

This is why I get peeved when people we should all hold in high-esteem drop blog posts with overly pithy summaries that actually end-up muddying the waters that much more.

In early April 2012 usability expert Jakob Nielsen turned his attention to mobile and penned a piece entitled, Mobile Site vs Full Site. The summary for the article follows:

Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.

The very first and, to quote him, ”very clear” guideline that Jakob lists for mobile-optimized websites is ”Build a separate mobile-optimized site.” [Jakob’s emphasis] Now the article is essentially correct in highlighting that the rules for mobile design can be different than desktop design and that most of today’s websites don’t properly address these issues. Josh Clark’s (@globalmoxie) rebuttal is very much worth reading and others picked apart the salient points at the time the original article was written so I won’t re-hash them. The thing that bothered me then, and does again in light of his equally good and bad article Repurposing vs. Optimized Design (another good overview so I won’t re-hash it either), is the definitive stance regarding an overall solution that Jakob takes when, in fact, he’s really only suggesting this “usability tip” for a particular subset of sites or use cases.

In a follow-up article on .net magazine, ”Nielsen Responds to Mobile Criticism,” Nielsen offers clarification on this original article and answers the following question that is based on one of the primary arguments used against his original post:

.net: The strategy of forking content for separate sites has been described as “a content strategy nightmare” – it’s too hard to maintain and will result in inferior experience for users.

JN: I would assume that most industrial-scale sites [emphasis mine] would be generated from a single back-end product database and content management system, with the different designs represented by templates and rules about what information goes into what version.

Later, in answer to the same question, he says:

Many companies and government agencies have products and information that don’t speak much to the mobile use case, and they can usually get away with having a single website that’s optimised for desktop use but with some adaptations to make it reasonably accessible on mobile devices.

So Jakob’s first, ”very clear” guideline is now not so clear. It gets worse:

.net: Multiple URLs for a single piece of content is often thought of as a bad idea.

JN:There are at least three different ways of implementing different user interfaces for different devices:

Each version lives at a different URL.

The same URL serves up different versions, depending on the device used to request the page.

The same code is transmitted to all devices, and the client side transforms this into the different designs, using responsive design.

As long as each user sees the appropriate design, the choice between these implementation options should be an engineering decision and not a usability decision.

.net: Why have you made no mention of using Responsive Design?

JN: Because I was writing about user experience, not implementation * [emphasis mine]*. As mentioned above, responsive design is one of the ways to achieve different user interfaces for different devices.

Suggesting ”Build a separate mobile-optimized site,” again his very first guideline, screams implementation. So, based on the .net Magazine clarifications, we should revise his original guideline to be ”If you’re a very large, centralized organization with mobile use cases it behooves you to do… something mobile-friendly.”

And the kicker to all that? If you just read Jakob’s material and weren’t hooked into the people who were involved in the backlash you may never have found the clarification. You may have implemented his suggestions as a “best practice” (I mean, it’s Jakob freakin’ Nielsen), found a vendor, spent some money and… been stuck with a site and a mobile strategy that didn’t fit your content, your internal processes, or real use cases as the web on mobile evolves into the “just in time” internet.

Figuring out what mobile will mean to your institution requires time spent thinking critically about goals, technology, and then trying to understand how these new tools can match up to your existing processes and, honestly, the culture you already have at your institution. To succeed with mobile you’ll have to be willing to be critical, to fail, to reconfigure, to iterate, to learn and to develop your very own “best practices.” Unfortunately, there is no such thing as a turn-key solution or list of tips that will help you easily guide your institution into the new age. No matter what Jakob, or I, might say.

I understand that this article can and probably will come across as the pot calling the kettle black. I take strong stances myself. I do hope that I appropriately add caveats to what I write but maybe I don’t. When I talk to people about mobile and they question how we’ve implemented and learned so much I tell them something my father told me a long time ago about what he told students he was teaching in a brand-new math class, “I’m only a chapter ahead of you.” Seriously, all of this stuff is a moving target.

ua-parser-php v1.4.0 Released: Easier to Cron, Quick “redirect” Example, and UA updates

2012-05-21T00:00:00-04:00

I’ve pushed out v1.4.0 of ua-parser-php. ua-parser-php is the PHP library for the official ua-parser project. Why use ua-parser? If you need a simple library to slice & dice user agent strings into understandable components (e.g. browser, OS, device) then it’s the project for you. ua-parser-php goes a step further by also attempting to categorize browsers as mobile, tablet, computer, or spider.

Setting Up ua-parser-php With Cron

As the ua-parser team updates the YAML file and its regular expressions you will want to update your local copy of regexes.yaml. The easiest way to do this on a *nix system is to use cron. I’ve added some simple flags, -silent and -nobackup, to make it easier to set-up an intelligent cron job. -silent is very important and I highly encourage you to use the flag if you use ua-parser-php with cron. By default, ua-parser-php writes out process updates to the command line as it fetches the regexes.yaml file. When using cron this will end up as an email and will either fill the spool on the machine or your inbox.

So here are some examples of commands you can use with cron:

Quick “redirect” Example

Because the PHP version of ua-parser supports extra browser categorizations like isMobile you can use ua-parser-php as the basis for a simple redirect script. The following should show just how easy it can be:

Recent User-Agent Updates

Obviously, the big feature of ua-parser is matching user-agent strings and giving you usable data. The following user-agents have been added and tested:

Google Chrome Frame
Google Earth browser
Firefox Alpha builds
Raven for Mac browser (aka Robin)
Sogou Explorer
Tizen Browser (aka SLP Browser) from Samsung
WebKit Nightly builds (though slightly pointless)
better support for Firefox Mobile
better support for the Pale Moon browser
better support for Polaris 8.0
better support for Epiphany

Have you tried out ua-parser-php and found an incorrect match? Drop a note in the ua-parser issue list on GitHub.

Editor’s note: I have no idea if ‘cron’ can be used as a verb but, hey, what the hell.

RESS: An Evolution of Responsive Web Design

2012-05-16T00:00:00-04:00

I gave a talk at RefreshPittsburgh (@refreshpitt) last night that hopefully served as an introduction to RESS and Detector. I believe RESS can help developers address some of the realities of deploying Responsive Web Design-based sites so it was awesome to share the concept. I can’t thank Jason Head (@gjhead), Val Head (@valh), and Geoff Barnes (@texburgher) enough for giving me the opportunity to present. It was a really fun time with a good group both during and after the event and I can’t recommend Refresh Pitt enough. The other talk of the night, given by Patrick Fulton (@patrickfulton), reviewed Compass and was really informative. If you’re in Morgantown or Pittsburgh make sure you follow @refreshpitt on Twitter and attend the next event.

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:

RESS: An Evolution of Responsive Web Design from Dave Olsen

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

I’ll Be Presenting on RESS at Refresh Pittsburgh Tuesday, May 15th @ 6.30pm

2012-05-07T00:00:00-04:00

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

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.

ua-parser-php Now A Part of the Official ua-parser GitHub Repository

2012-05-02T00:00:00-04:00

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.

Share Your Knowledge: Present at HighEdWeb National or HighEdWeb Arkansas

2012-04-17T00:00:00-04:00

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.

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.

New Presentation: The Future-Friendly Campus

2012-04-11T00:00:00-04:00

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!

RESS, Server-Side Feature-Detection and the Evolution of Responsive Web Design

2012-02-21T00:00:00-05:00

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.

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?