On Adaptive Design

This post originally appeared on the Storm ID blog.

There’s some confusion from some of our clients about what adaptive design really is and if, when and how it should be used. Responsive design is all but the industry standard at this point, but what about adaptive?

Originally the term adaptive design was used to describe layouts which were very similar to responsive layouts, but with fixed widths instead of fluid widths. Some designers really liked that as it meant you could control line lengths and image sizes and that was handy when the industry was starting to get to grips with how all this new stuff worked. The main downside was that if you viewed these layouts in a browser window which was in between these breakpoints, you could have a lot of ‘wasted’ screen space. The experience didn’t feel native to the device you were holding, which is the whole point of responsive design. For example we saw some tablets that were less wide than an iPad and the designer had only added breakpoints for iPhone size and iPad size screens, so you saw the ‘mobile’ sized site with lots of space either side. This method didn’t lend itself well to the fluidity of the web and the mass of different device sizes. You had to use breakpoints that made sense for your current traffic which may not make sense in a few months when Apple or Samsung or Amazon bring out their new device with a different screen size.

The adaptive design that is talked about in many articles at the moment largely relies on Javascript (JS) to add in components to the document based on what it thinks it knows about your device. This can work, but has a couple of possible problems that are showstoppers for me.

Some articles advocate using JS to find your screen size. This is generally fine technically, but there can be problems with that. Screen size ≠ browser window size ≠ context ≠ device type.

Some advocate browser sniffing, where JS detects parts of the user agent string of your browser. This can cause huge problems. For various reasons, browsers often lie about what they are. This method doesn’t allow for new classes of device either, without development updates.

OkCupid have a different use for browser sniffing.

Another big problem with many of these articles is that these techniques absolutely require JS. That’s not too bad if it’s server side (run on the website’s server before sending the page to the browser), but if it’s client side (run by the end user’s browser as the page is delivered) then this can and will cause problems. Web browsers operate in a fundamentally hostile environment. If the end user’s browser has JS turned on, and if JS runs successfully and in a timely fashion, then they may be delivered a relevant page, with the caveats above. If JS is turned off (unlikely but possible) or JS fails to run (device is struggling, internet connection is slow or fails) then, in many cases the user will be left with a sub-standard experience, or no experience at all in some cases. And slow connections are not just for mobiles. Think cafes with 50 customers and a weak router, or small internet cafes, or some rural areas, or people who have to deal with ISP problems all the time. Our company build large scale, award winning digital products, but we can’t get decent wifi in one of our meeting rooms, and we spent the first week in our new office with a connection that was only okay if no one started a YouTube video or Spotify.

This is what squarespace.com looks like if JS is turned off or fails.

Running this stuff on the server and delivering components according to what it thinks it knows can be good idea in theory, though. Capital One talk about doing this with their sites, promoting different products to different device classes and locations. If you have a strong in-house team, both in development and marketing, and can tweak that regularly and test heavily, you could have . This can also have downsides. Many people will try to tell you that on a small screen you should change content because small screen = mobile = on the go. We know from (bitter) experience that this is not necessarily true any more, as more people move to not owing a traditional computer at all. On many of the kind of sites we produce, all content is as relevant on small screens as larger screens, so messing with that seems like a bad idea. Make an element less prominent, but removing it all together will just frustrate the people who need that element and only have mobile device (at least at that moment). How many times have you sat on your sofa and looked for something online on your smartphone, only to give up because the feature you need is missing, and getting up to switch on your laptop seems like a lot of effort?

Be careful about SEO. Google is putting less importance on content which is not visible by default on a page, such as tabs and ‘read more’ content. This could easily be applied to content that doesn’t appear for all users. So be careful about selectively adding content that might be important.

Delivering different assets from the server depending on screen size is also a good idea in theory, as it means your browser only downloads what it needs to which cuts down on bandwidth, increases page speed and in turn engagement and sales. However, there are new HTML image specs which are usable in Chrome, iOS, Safari and Opera now, and are polyfill-able in other browsers, which basically do the same things with a bit more flexibility. They take away the need for fancy server configs too, which is especially great for prototyping.

The last, and perhaps most important point: What these articles talk about as adaptive design could fit into responsive design. The two are not mutually exclusive at all. Responsive design goes way beyond just fluid layouts that change at different screen sizes. It’s also about performance and progressive enhancement, both of which are part of what they talk about adaptive design being. But that’s another big blog post in itself.

The main thing is to use common sense and think about all kinds of users. Use progressive enhancement to first make it work, then make it work better. Don’t rely on a user having all the technology that you hope they do, and have it working fully every single time. Be inclusive.

More