Archive for the 'reading list' Category

Reading List

Wootarama! It’s my 100th reading list as the penultimate blogpost of this blog’s eleventh year. The Queen just sent me a telegram. You can send me Guinness or Laphroiag.

Reading List

Reading List ninety-nine. With a flake in it.

Reading List

Ooh,ooh, it’s the 98th Reading List (including last week’s Device Detection vs Responsive Web Design-themed list). Will I get to 100 before 2015?

Device Detection vs Responsive Web Design

This week’s reading list is devoted to Device Detection vs Responsive Web Design.

With all the cool kids getting into RWD these days, it’s time to have a look at the Device Detection companies again. Device Detection is the practice of matching a device’s UA string against a table of such strings and looking up certain characteristics of that device and then serving different websites accordingly.

Of course, the utility of such services is dependant on the quality of the look-up table: how many devices does it know about (all the ones in the world, ever?), how frequently it’s updated (have they added the Umbongo J2O TrouserPhone S+ that was released on Tuesday, yet?) and how accurate is that data (does the TrouserPhone S+ really have 178680979 X 7 pixel smellovision display?).They are, however, an order of magnitude more reliable than terrible CMS plugins or JavaScripts that were written years ago and which register IE11 as IE1, or don’t know Chrome exists. UA strings are comically unreliable, being the frontline in an unceasing battle between browser-sniffers who want to deny entry to certain browsers, and browser vendors who want their users to get a first-class experience.

Examples of Device Detection companies include scientamobile (WURFL), DeviceAtlas and 51Degrees. The databases owned by such companies do include device characteristics unavailable through client-side detection. For example, you can’t find out from JavaScript whether a device is actually a touchscreen device; the physical dimensions of a screen or the retail price of a device (which advertisers want to know, apparently – you only want to advertise yachts to gold iPhone or Umbongo J2O TrouserPhone S+ owners).

Mike Taylor, an ex-colleague of mine at Opera, now at Mozilla (and pathological hater of chickens) set up a collaborative document to collect use cases that people are trying to solve with UA detection (which can’t be solved by feature-detection), which is summarised by Karl Dubost (ex-Opera, now Mozilla) in User Agent Detection Use Cases.

Those who oppose Device Detection do so for philosophical reasons – it’s one web and we shouldn’t serve different content to different devices or browsers, or they are certain browser vendors: Internet Explorer, Firefox OS and Opera all have reasons to dislike browser sniffing or device detection (“this website is only available to iPad users”). Google uses device detection all the time on its properties, as do many other large companies.

The device detection companies have begun to issue reports comparing their products with responsive, client-side techniques. Here are three that I’ve seen this week:

They’re worth reading. Of course, case studies only go so far; every business, territory and site is different. One thing everyone agrees on is that performance matters – slow sites lead to fewer conversions. mobiForge has an article M-commerce insights: Give users what they want, and make it fast that claims

RWD sites were the slowest, on average, to load on mobile – 8.4 seconds – while dedicated mobile sites loaded fastest – in 2.9 seconds. Non-responsive desktop sites took 6.57 seconds to load.

I’d like to see proper A/B testing: a well-made responsive version of a site versus its “m-dot” equivalent, redirected from its canonical URL and assembled after a device look-up, across a variety of devices and network conditions. If we’re going to argue, it might as well be about data.

Update 1 Dec 2014: Here’s some initial research on the top 1,000 mobile websites: M dot or RWD. Which is faster? that concludes that “m dot” sites are 50% slower for time to first byte, and

RWD sites are VERY competitive on Visually Complete and SpeedIndex scores. The median values are within 5% for both metrics. Even though it appears that RWD is faster, there is enough fluctuation in the data that we should probably call it a dead heat.

Reading List

Reading List

Reading List

Reading List

Reading List

Pointer Events

Microsoft wrote a spec called Pointer Events API that unifies touch, stylus and mouse inputs, and implemented it in IE11 (partially in IE10). Firefox are implementing it too. After initial enthusiasm from Google, Chrome announced that it won’t support it, after all.

  • HTTP 203: Pointer Events – 4 min video in which Jank Architect and Longpoll Lewis explain why Chrome thinks the Pointer Events API smells.
  • Jacob Rossi of Microsoft disputes the claims (G+ link, sorry).
  • More discussion about the Pointer Events Smell video from @SlexAxton, @davemethvin (jQuery): “It all boils down to ‘Why is Chrome+IE+Firefox not enough for Pointer Events, but Chrome+Firefox enough for Touch Events extensions?'”

Other standards ‘n’ shiz

Reading List