Making the Most of Device Diversity BDConf Dallas, 2012 Ronan Cremin, CTO dotMobi @xbs Wednesday 10 October 12 

Wednesday 10 October 12 

How we got here Wednesday 10 October 12 

#bdconf Book, 800 AD 33cm 24cm cover pages Wednesday 10 October 12 

#bdconf Book, 2012 AD 33cm 24cm cover pages Wednesday 10 October 12 

#bdconf Radio, 1930 speaker tuner volume Wednesday 10 October 12 

#bdconf Radio, 2012 speaker tuner volume Wednesday 10 October 12 

#bdconf TV, 1950 screen controls Wednesday 10 October 12 

#bdconf TV, 2012 screen controls Wednesday 10 October 12 

#bdconf Previous media: relatively stable evolution • Previous media have evolved quite a bit in their lifetime • Sophistication • Lowering of production costs • Lower barriers to entry for consumers • But • User interaction models haven’t changed much in their lifetimes • Models & paradigms from the dawn of the media largely still apply • This has led to false sense of complacency with the web Wednesday 10 October 12 

But what about the web? Wednesday 10 October 12 

#bdconf PC, 1995 Wednesday 10 October 12 

#bdconf PC, 2000 Wednesday 10 October 12 

#bdconf PC, 2005 Wednesday 10 October 12 

#bdconf PC, 2012 1024 x 768 keyboard mouse Wednesday 10 October 12 

#bdconf PC: computing capability, physical interface richness 1990 year RAM MIPS screen size capability 2007 screen resolution richness of interface Wednesday 10 October 12 

#bdconf 1024 x 768 + keyboard + mouse = A4 of the web Wednesday 10 October 12 

#bdconf Web evolution engendered by device diversity 1990 2007 2012 2000 dark ages of the web —the monoweb age of enlightenment —the polyweb “peak app” Wednesday 10 October 12 

2002 mind the gap portable capable Wednesday 10 October 12 

2012 mobile = spectrum of device types Wednesday 10 October 12 

Physical screen size Input methods Viewing distance Physical context Pixel dimensions Tablet Desktop TV Mobile 176 x 220 to 800 x 1280 600 x 800 to 2048 x 1536 800 x 600 to 2560 x 1600 1280 x 720 to 1980 x 1080 0.3m 0.5m 0.7m 3m Contexts, interfaces, input methods defies easy classification 106x Wednesday 10 October 12 

Point 1—a new landscape • The emergence of new devices is changing the way we access the web • Unprecedented rate of change compared with previous media • Radically changed interfaces & use cases mean that web on mobile is more new medium, than differently sized one • Long period of stability, huge changes: everyone caught off guard ? ? Wednesday 10 October 12 

Lessons from new media Wednesday 10 October 12 

Example: television • The first television shows were people simply reading books, vaudeville shows • 20 years later: the first “TV- native” formats emerged • Soap operas • Sitcoms • 50 years later: reality TV Wednesday 10 October 12 

Example: desktop web • Many early websites mimicked print • images & image maps used in place of web-native content • 15+ years before the first “web- native” ideas were invented • sites that had no real precedent • things that were “inherently web” could’t really have been done with previous media • Facebook, Google maps • We’re still getting used to the idea that there isn’t really a “fold” on the web—scrolling is effortless Wednesday 10 October 12 

#bdconf History of adapting to new media • Content creators struggle to understand new media • Initial uses mimic those of previous media • New medium capabilities remain misunderstood and under-utilized • Experiences “native” to the new media emerge slowly— decades • Retro-fitting old content to new media stifles innovation • So what about the new web? Wednesday 10 October 12 

Web on mobile, new medium • Mobile web uses HTTP, HTML, CSS and JavaScript, just like the web we know • But it is effectively a new medium, and should be treated as such • This new medium runs on a vast array of devices, sizes shapes • New interfaces: touch, accelerometers, cameras, gyros, compass • New contexts: outdoors, on the move, supine 176 x 220 to 800 x 1280 0.3m Wednesday 10 October 12 

Wednesday 10 October 12 

Wednesday 10 October 12 

portion of north ceiling portion of south wall corner pendentive portion of east wall corner pendentive spandrel spandrel Wednesday 10 October 12 

Wednesday 10 October 12 

Good experiences are native, not converted • Key lesson from previous media: • Good experiences are native to the medium • Good experiences acknowledge and harness their container • Retro-fitting doesn’t work—let’s not force-fit our desktop web to the new devices • Let’s not wait 20 years to work out how to use newly diverse web Wednesday 10 October 12 

#bdconf Point 2—design for the new medium • Not a problem, an opportunity • Things are blossoming—not the right time to seek silver bullets • Let’s not limit our experiences of the new web to those we know from web desktop • Previous experience: natively designed experiences work best • The best way to cope with the changes is to cater for the aspect that changed—the devices Wednesday 10 October 12 

Embracing the new web Wednesday 10 October 12 

Protocols ready, tool chains unwilling • HTTP is ready but.. • Most existing tools are either: • not helpful (neutral), or, • mired in monoweb thinking • Industry is still grappling with the changes • Situation not going to change any time soon. AUTHORING PUBLISHING CMS Wednesday 10 October 12 

Wednesday 10 October 12 

The device is the canvas • In this renaissance of the web, the device is the canvas—from feature phone to TV • But the canvas isn’t fixed— this is no longer a valid assumption for the artist • The paint is still HTML, CSS and JavaScript, the protocol is still HTTP ..but the techniques have to change Wednesday 10 October 12 

Know your canvas—device awareness • The new web is defined by the devices that constitute it • Embracing the device in question is best way to ensure a good experience • Craft experiences to suit the context & device: • Be aware of its features, harness them • Know its limitations, work around them • How can we achieve this? ☒ makes calls ☐ big screen ☐ touch screen ☐ makes calls ☒ big screen ☒ touch screen ☐ makes calls ☒ big screen ☐ touch screen Wednesday 10 October 12 

Server-side device detection Wednesday 10 October 12 

#bdconf Device detection: spawn of satan? • "Sniffing, as the practice has been called, is a fragile one, however.” • “Browser sniffing has a justifiably bad reputation” • “Flawed concept” • “Browser sniffing doesn't work” • “There are too many browsers to handle” • “..the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded” • “it’s simply not necessary, besides being wrong on a fundamental level” • “Nearly everybody did it. And everybody was wrong. Not `there’s something to say for it but sometimes you don’t need it’ wrong, but just plain `you have no clue what you’re doing’ wrong” Wednesday 10 October 12 

Or best-of-breed tool? Used by.. Wednesday 10 October 12 

#bdconf Claim: device detection is fra . • Most common explanation: device DB goes out of date. • Clearly untrue—the vendors of such solutions vendors very existence depends on this not happening • Anybody who uses Facebook, Google etc. is enjoying the benefits of device detection • Clearly, if it really was fragile it would not be used by the industry-leading web brands • Silent evidence / confirmation error problem: its successes go unnoticed; its failures are very obvious • Device detection can be used badly, just like any technology. Bad implementation ≠ bad idea. gile Wednesday 10 October 12 

@media screen and (min-width: 480px) { /* smartphone CSS */ } @media screen and (min-width: 600px) { /* narrow view CSS */ } @media screen and (min-width: 800px) { /* desktop CSS */ } @media screen and (min-width: 1024px) { /* wide CSS */ } Claim: device detection is difficult similar complexity levels media queries server-side detection vs. Wednesday 10 October 12 

Claim: database difficult to keep up to date $ crontab -l 0 4 * * * curl -s "http://domain.com/getData.php? licencekey=123" > data.zip && unzip data.zip @ 4am every morning get file unzip it Wednesday 10 October 12 

“Everyone pretends to be everyone else” • 9,500 distinct devices, less than 5 nefarious masquerades (0.05%) • Remaining devices easily differentiable • Opera Mini sends headers for underlying device • Conclusion—simply not true in mobile world. “iPhone W88” Wednesday 10 October 12 

Claim: device detection is wrong • Much strong opinion about what’s right and wrong • Best understood with some historical context.. Wednesday 10 October 12 

Response tailoring is built into HTTP 1.0 RFC 1945 (HTTP 1.0), T. Berners-Lee, 1996 10.15 User-Agent The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. RFC 1945 Wednesday 10 October 12 

RFC 2616 (HTTP 1.1) T. Berners-Lee et al, 1999 HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent capabilities and user preferences: Accept (section 14.1), Accept- Charset (section 14.2), Accept-Encoding (section 14.3), Accept- Language (section 14.4), and User-Agent (section 14.43). Response tailoring is built into HTTP 1.1 RFC 2616 Wednesday 10 October 12 

http://www.w3.org/TR/mobile-bp/#OneWeb (2008) One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts. W3C’s “one web” is often misunderstood Mobile Web Best Practices 1.0 Wednesday 10 October 12 

So where does the perception come from? • Mostly stems from working around browser flaws in early days of web • Important not to conflate two uses cases for detection: • Working around browser defects (historical) • Catering to devices with radically differing capabilities (modern) • The former usage may be objectionable, but the latter surely is not • Don’t let historical misuse prevent you from using a useful tool vs. Wednesday 10 October 12 

Benefits of device detection Wednesday 10 October 12 

100% control of delivered content • Send only what you need to each device/experience • Huge expressive range— from feature phones to televisions • Change design, input mechanisms, image sizes, everything for each device type CONTEXTS INTERFACES SCREENS Wednesday 10 October 12 

Performance • Each device gets only what it needs, attendant cascade of benefits: • Reduced loading time • Reduced rendering time • Reduced CPU overhead & battery drain • Remember, 3G or 4G signal ≠ bandwidth guarantee (congested cell, airport WiFi) • Respect visitors’ data plans 116Kb 6Kb 4Kb 124Kb 53Kb 46Kb iPhone Nokia 6300 Curve Wednesday 10 October 12 

Perfomance of RWD-only sites 286Kb 286Kb 286Kb iPhone Nokia 6300 Curve Wednesday 10 October 12 

Perfomance of RWD-only sites 500Kb 500Kb 500Kb iPhone Nokia 6300 Curve Wednesday 10 October 12 

Leverage device capabilities • JavaScript feature tests are very useful but: • you don’t know what the device is • you know only browser features (not device) • Properties unknowable via JavaScript feature tests: • device type: mobile | desktop | tablet | TV | e-reader | set- top box • hardware features: camera | screen colour depth • model, vendor, operating system, version mobile device? has camera? supports touch? Wednesday 10 October 12 

Availing of features • Thought experiment • What would be the first question a designer would ask when creating a new UX? • So why treat the web any differently? Wednesday 10 October 12 

Full control of site architecture • All options supported • Multiple different views on single URL • Different site / sub-domain for each experience • Full flexibility over experience & content served in each case • Easy to add additional segmentation without compromising other experiences • Easier testing—different device experiences can be isolated • Big differences between form factors is easy (feature phone vs. TV) site.com site.com touch.site.com tv.site. com lite.site.com 1 2 Wednesday 10 October 12 

• Server-side device detection is only way to get useful device statistics from sites • Used by Omniture, Google Analytics, Webtrends, IBM CoreMetrics etc. Opera/9.80 (Android; Opera Mini/6.5.26571/26.1305; U; pl) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT) ::ELNSB50:: Mozilla/5.0 (Windows; U; fr-FR) AppleWebKit/523+ (KHTML, l Ericsson R380 v0.0 (compatible; YOSPACE SmartPhone Emulato Mozilla/5.0 (compatible; MSIE 9.0; AOL 9.7; AOLBuild 4343. Mozilla/4.0 (compatible; MSIE 6.0; Symbian OS; Nokia 5320/ SIE-C3I/2.0 UP/4.1.9 UP.Browser/4.1.9-XXXX Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; {DB258E Opera/9.80 (BREW; Opera Mini/6.143/26.1305; U; id) Presto/ Mozilla/5.0 (compatible; MJ12bot/v1.4.0; http://www.majest iBrowser/Mini2.2 (Maui) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; BT Mozilla/5.0 (X11; U; Linux armv7l; en-US) AppleWebKit/533. Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; 96 Mozilla/5.0 (compatible; NerdByNature.Bot; http://www.nerd Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.8.1) Opera/9.80 (J2ME/MIDP; Opera Mini/4.1.13572/26.1305; U; ru Opera/9.30 (Nintendo Wii; U; ; 3642; fr) Opera/9.80 (J2ME/MIDP; Opera Mini/4.4.28002/26.1305; U; en Wget/1.12 (linux-gnu)|OriginalIP:74.112.131.201 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; TheFree Nguy?n L??ng UNTRUSTED/1.0 Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; NOOK BNRV200 Opera/9.80 (Series 60; Opera Mini/6.24323/26.1305; U; en) 1Opera/9.80 (J2ME/MIDP; Opera Mini/4.2.16320/26.1305; U; e Wget/1.10.2|OriginalIP:216.183.81.221 Mozilla/4.0 (compatible :: MSIE 7.0 :: Windows NT 5.1 :: |OriginalIP:66.118.218.86 Mozilla/5.0 (Windows; U; es_ES) AppleWebKit/530.19.2 (KHTM SGH-Z140 SHP/VPP/R5 SMB3.1 SMM-MMS/1.2.0 profile/MIDP-2.0 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; BT Opera/9.80 (Series 60; Opera Mini/6.1.25580/26.1305; U; tr Mozilla/4.0 (compatible; MSIE 7.4; Windows NT 5.1; .NET CL Mozilla/4.0 (compatible; MSIE 7.2; Windows NT 5.1; .NET CL Mozilla/5.0 (Series40; Nokia3120classic/10.00; Profile/MID Opera/9.80 (J2ME/MIDP; Opera Mini/4.2.21628/26.1305; U; es AppEngine-Google; (+http://code.google.com/appengine; appi AppEngine-Google; (+http://code.google.com/appengine; appi sam335[TF268435459606237430000000016412330640] UP.Browser/ Statistics and analytics Wednesday 10 October 12 

#bdconf Disadvantages of server-side detection • Some user settings can’t be known in advance e.g. cookie support, orientation, detecting iPhone versions etc. • Server-side skills required (a new reality for the web?) • Cost—detection solutions have annual licensing fees • Device data must be updated • single biggest issue • not “future friendly” Wednesday 10 October 12 

Future friendliness • Device databases need to be updated, there is external dependency • But so too do server OSes, libraries, media query breakpoints • Also, sensible defaults mean graceful degradation when faced with unknown devices • Don’t forget present-friendliness • Are you supporting all currently available devices? Including feature phones? • Don’t care, getting no feature phone traffic? Are you sure? Wednesday 10 October 12 

Point 3—use all the tools available • In this new web landscape you need all of the help you can get • There are no silver bullets yet—so use everything available to you • Device detection is a fantastically powerful tool • Don’t let perceptions from bygone era preclude great performance & expressive range • Not either/or—works well in tandem with client-side approaches—fine tuning layout, user settings • All best-of-breed experiences are using it Wednesday 10 October 12 

Wrap up Wednesday 10 October 12 

Summary—the landscape • There are macro-level changes happening on the web, a web renaissance is beginning • New devices are finally enabling the web to reach its full potential • The new capabilities effectively engender a new medium • Every indication that this diversity will increase over time —phones & tablets are just the beginning • The web experience in this new landscape is becoming a differentiating factor for brands Wednesday 10 October 12 

Summary—the tools • Harnessing the web’s full potential requires knowledge of the canvas, the device • Embrace all tools in the toolbox— there are no silver bullets • If you don’t you’re discarding useful information • Don’t compete with half the available tools— your competitors won’t make same mistake Wednesday 10 October 12 

Take flight, light-winged Dryad of the trees “Mobile gives the web wings” - Mary Meeker Wednesday 10 October 12 

#bdconf hydra.mobiforge.com Wednesday 10 October 12 

http://deviceatlas.com/ futureofthemobileweb http://deviceatlas.com/ Ronan Cremin rcremin@afilias.info @xbs http://gomobi.info/ Wednesday 10 October 12