Breaking Development: Making the Most of Device Diversity

by Luke Wroblewski September 24, 2012

In his Making the most of device diversity talk in Dallas, TX Ronan Cremin explained the need for and benefits of server-side detection techniques in modern Web design. Here's my notes from his talk:

  • The fundamentals of user interaction in mass media (radio, TV, print) have not changed over many users. The models and paradigms from the start of media still tend to apply today.
  • The Web was developed in the world of the personal computer, whose user interaction model has also not changed much over the past 20 years. Screen sizes & resolutions have barely changed as well.
  • 1024x768 + keyboard + mouse = the A4 (standard page size) of the Web. This was the mono-Web; where the Web was shackled by the richness of PCs.
  • As of 2007, we entered the polyweb: the age of publishing to everywhere. The device evolution has just gotten started and creates many new opportunities.

Device Diversity

  • Devices are only going to get smaller on one end and larger on the other but the Web is about more than screen size.
  • Screen size, pixel dimensions, input methods, viewing distance, and physical context differ per device.
  • TVs don’t necessarily have higher resolution than phones. So we can’t count on resolution alone to determine physical context (leaning back on couch, out and about, etc.).
  • There isn’t one common input method to interface with all devices. This is a big challenge.
  • The emergence of new devices is changing how we use the Web. Radically changed interfaces and use cases mean that the Web on mobile is quite different form the established norm of the PC Web. This has caught people off guard.
  • It took 20-50 years for the TV to get its groove: to figure out what worked for the media. Similarly, many early Web sites mimicked print. It took about 15 years to discover true Web forms.
  • Content creators struggle to figure out new mediums. It takes a long time to learn what you can do in a new medium like mobile.
  • You have to design experiences for the medium where they will be consumed. Good experiences are native, not converted. You can’t just retro-fit existing experiences. Let’s not wait 20 years to figure this out again.
  • This is an opportunity not a problem. The best way to cope is to cater to what has changed: the diversity of devices.
  • Today, the protocols are ready but the tools chains are holding us back. They are either getting in the way or just neutral. CMS tools are both an authoring and publishing problem.
  • We’re designing, building, and flying our own planes. It’s like the early days of the Web: build your own tools.
  • The device is the canvas but the canvas isn’t fixed. You need to know your canvas: what are you publishing to. The new Web is defined by the devices you are publishing to. Embracing the device is the best way to ensure a good experience: know the capabilities and limitations of each devices. How do you do that?

Server-side Device Detection

  • Server-side detection has a bad reputation but every top tier site on the Web uses some form of device detection on the server.
  • Claim: device detection is fragile –it won’t detect new devices reliably. This is clearly untrue because the system is being used by every major Web site. Most of the time you are using it, you don’t even know –it just works.
  • Claim: device detection is difficult. However, the complexity is equal to the complexity of media queries in responsive design solutions.
  • Claim: keeping a database up to date is hard but a simple script is easy to set up that can keep databases timely.
  • Claim: devices spoof themselves. 9,500 distinct devices, less than 5 nefarious ones (0.05%). So this is not really much of an issue.
  • If these things are true, why do people consider device detection to be wrong? From a historical perspective: tailoring responses in built into the fundamentals of the Web.
  • The perception of device detection probably stems from working around browser flaws in the early days of the Web. Don’t conflate this issue with the benefits of device detection today.

Server-side Benefits

  • Server-side detection gives you 100% control of what you send to each device. This gives you a huge expressive range: change input interfaces, loading time, rendering time, CPU overhead, battery drain, etc.
  • Responsive Web design alone doesn’t give you the tools you need to really optimize performance.
  • Leverage device capabilities: there are a lot of things Javascript feature detection can’t tell you: hardware, device type, does it have a camera, etc.
  • Control the site architecture: different views of single URL; different site or sub domain for each experience; and more.
  • However, some user settings can’t be known in advance on the server (cookie, orientation, iPhone versions, etc.).
  • Future friendly: device databases need to be updated. This creates external dependencies but we live in a world of dependencies: OSes, libraries, breakpoints, etc. Sensible defaults mean graceful degradation when faced with unknown devices.
  • Don’t forget present friendliness: support all available phones. Even if they don’t come up in analytics. Many don’t support Javascript and won’t show up in Javascript analytics tools.
  • Server-side detection is a very valuable tool. Use it in ways it makes sense and don’t be tainted by past perceptions.