Making the web work on mobile: DeviceAtlas
0 likes1,355 views
The presentation by Ronan Cremin at bdconf 2012 discusses the importance of adapting web design for a mobile-first approach, emphasizing that the mobile web represents a new medium distinct from traditional desktop environments. It outlines the need for tailoring experiences to the unique features and limitations of various devices, warning against merely repurposing desktop content for mobile use. With the evolution of devices, there is a call to leverage all available tools, including device detection, to create optimal user experiences as the landscape of web interaction continues to evolve.
![device detection v media queries
media queries
server-side detection
@media screen and (min-width: 480px) {
/* smartphone CSS */
}
<?php
include './DA/Client.php';
$data = DeviceAtlasCloudClient::getDeviceData();
$width = $data['properties']['displayWidth'];
@media screen and (min-width: 600px) {
/* narrow view CSS */
}
vs.
@media screen and (min-width: 800px) {
/* desktop CSS */
}
@media screen and (min-width: 1024px) {
/* wide CSS */
}
if (480 < $width) {
// smartphone view
} elseif (600 < $width) {
// narrow view
} elseif (800 < $width) {
// desktop view
} elseif (1024 < $width) {
// wide view
}
?>
similar complexity levels](https://image.slidesharecdn.com/makingthewebworkonmobile-131113041834-phpapp02/85/Making-the-web-work-on-mobile-DeviceAtlas-43-320.jpg)
Making the web work on mobile: DeviceAtlas
- 1. Making the Web Work on Mobile First presented by dotMobi CTO Ronan Cremin at BDConf 2012
- 10. 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 have not 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
- 12. PC, 1995
- 13. PC, 2000
- 14. PC, 2005
- 15. PC, 2012 1024 x 768 keyboard mouse
- 16. capability PC: computing capability, physical interface richness RAM MIPS richness of interface screen size screen resolution year 1995 2007
- 17. 1024 x 768 + keyboard + mouse = A4 “Letter” of the web
- 18. Web evolution engendered by device diversity dark ages of the web— the monoweb 1990 age of enlightenment— the polyweb 2000 2007 2012
- 20. 2012 mobile = spectrum of device types
- 21. Contexts, interfaces, input methods
- 22. Point 1—a new landscape • The emergence of new devices is changing the way we access the web • The rate of change is unprecedented compared to any previous media • Every indication suggests that the new diversity is just beginning • Radically changed interfaces and use cases mean that mobile web is effectively a new medium, not a differently sized one • After a long period of stability, huge changes a short time have caught everyone off guard
- 24. Example: television • The first television shows were people simply reading books, vaudeville shows • 20 years passed before the first “TV-native” formats emerged – Soap operas – Sitcoms • 50 years later: reality TV
- 25. Example: desktop web • Many early websites mimiced print – images & imagemaps 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
- 26. 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 take time to emerge • Retro-fitting old content to new media is a failure of imagination
- 27. 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 perhaps should be treated as such • This new medium runs on a vast array of devices • Demands that you are aware of their features and limitations to deliver the best experience • Let’s not forget the lessons from previous media— by force-fitting our desktop web to the new devices we’re repeating the error
- 30. portion of north ceiling spandrel corner pendentive portion of south wall corner pendentive spandrel portion of east wall
- 32. Good experiences are tailored, not repurposed • Key lesson from previous media: • Good experiences are tailored to the medium • Good experiences acknowledge and harness their container • Design for setting and context • Automatic conversion doesn’t work • One-size-fits-all isn’t good enough • It may “work” but it won’t excel
- 33. Point 2—design for the new medium • The new web isn’t problem to be solved, it’s an opportunity to be embraced • Just when things are getting exciting is not the time to look for silver bullet solutions • Previous new media suggest that experiences designed for each media work best • Let’s not limit our experiences of the new web to those we know from web desktop • The best way to cope with the changes is to cater for the bit that changed—the devices
- 35. Existing tool chain is still evolving CMS • Industry is still grappling with the changes • Situation not going to change any time soon PUBLISHING – limited – mired in monoweb thinking AUTHORING • Most existing tools are either:
- 37. The device is the canvas • In this renaissance of the web, the device is the canvas—from feature phone to TV • But the canvas is no longer fixed— no longer a valid assumption for the artist • The paint is still HTML, CSS and JavaScript, the protocol is still HTTP ..but the methods have to change
- 38. Know your canvas—device awareness • • • The new medium is defined by the devices that constitute it Embracing the device in question is best way to ensure a good experience Build an experience that suits the context & device: – Be aware of its features, harness them – Know its limitations, work around them • We need all of the help that we can get ☒ ☐ ☐ makes calls ☐ ☒ ☒ makes calls ☐ ☒ ☐ makes calls big screen touch screen big screen touch screen big screen touch screen
- 40. Device awareness: 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”
- 41. Or best-of-breed tool? Server-side device detection used by:
- 42. 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 • Device detection can be used badly, just like any technology. Bad implementation ≠ bad idea. • Clearly, if it really was fragile it would not be used by the industryleading web brands • Anybody who uses Facebook, Google etc. is enjoying the benefits of device detection • Silent evidence / confirmation error problem: its successes go unnoticed; its failures are very obvious
- 43. device detection v media queries media queries server-side detection @media screen and (min-width: 480px) { /* smartphone CSS */ } <?php include './DA/Client.php'; $data = DeviceAtlasCloudClient::getDeviceData(); $width = $data['properties']['displayWidth']; @media screen and (min-width: 600px) { /* narrow view CSS */ } vs. @media screen and (min-width: 800px) { /* desktop CSS */ } @media screen and (min-width: 1024px) { /* wide CSS */ } if (480 < $width) { // smartphone view } elseif (600 < $width) { // narrow view } elseif (800 < $width) { // desktop view } elseif (1024 < $width) { // wide view } ?> similar complexity levels
- 44. “Everyone pretends to be everyone else” • 12,000+ distinct devices, <5 nefarious masquerades (0.05%) • Remaining devices easily differentiable • Opera Mini sends headers for underlying device • Simply not true in mobile world “iPhone W88”
- 45. Claim: device detection is wrong • There is a lot of strong opinion about what’s right and wrong • But in fact device detection is designed into the web • Best understood with some historical context..
- 46. Response tailoring is built into HTTP 1.0 RFC 1945 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.
- 47. Response tailoring is built into HTTP 1.1 RFC 2616 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), AcceptCharset (section 14.2), Accept-Encoding (section 14.3), AcceptLanguage (section 14.4), and User-Agent (section 14.43).
- 48. W3C’s “one web” is often misunderstood Mobile Web Best Practices 1.0 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. http://www.w3.org/TR/mobile-bp/#OneWeb (2008)
- 49. 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.
- 52. 100% control of delivered content CONTEXTS INTERFACES SCREENS • 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
- 53. Performance • Each device gets only what it needs, with cascade of benefits: – Reduced loading time – Reduced rendering time – Reduced CPU overhead & battery drain 116KB 6KB 4KB • Remember, 3G or 4G signal ≠ bandwidth guarantee (congested cell, airport WiFi) 46KB 53KB 124KB
- 54. Performance of RWD-only sites 286Kb 286Kb 286Kb
- 55. Leverage device capabilities • JavaScript feature tests are very useful but: – don’t know what the device is – know only features related to browser (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?
- 56. Full control of site architecture • All options supported 1 site.com – 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) touch.site.com 2 site.com lite.site.com tv.site. com
- 57. Statistics and analytics • Server-side device detection is only way to get device statistics from sites • Used by Omniture, Google Analytics, Webtrends, IBM CoreMetrics etc.
- 58. Disadvantages • Some user settings can’t be known in advance e.g. cookie support, orientation • 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”
- 59. Future friendliness • Device databases need to be updated, there is external dependency – But so too do server OSes, libraries, media query breakpoints • 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? – Getting no feature phone traffic? How do you know?
- 60. Point 3—use all the tools available • In this new web environment you need all of the help you can get • There are no silver bullets, no holy grail—you should use all of the tools available to you • Device detection is a really useful tool in the developer’s tool box – All best-of-breed experiences are using it – Don’t let preconceptions from bygone era preclude great performance & expressive range – Works well in tandem with client-side approaches— fine tuning, user settings
- 61. Wrap up
- 62. Summary—the landscape • There are macro-level changes happening on the web, a web renaissance is beginning • New devices are 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 are just the beginning • The polyweb experience is becoming a differentiating factor for brands
- 63. Summary—the tools • There are many tools to help • Harnessing the full potential of the web requires knowledge of the device • Avail of all tools in the toolbox—no silver bullets • If you don’t you’re discarding useful information • Your competitors won’t make the same mistake
- 64. “Mobile gives the web wings” - Mary Meeker • But only if you use them
Editor's Notes
- #3: dotMobi started out in 2006 as a joint venture between these companies Our mission then, and still, is to help the growth of the mobile web - to raise the tide Became wholly owned subsidiary of Afilias in 2010. Afilias run roughly 20% of the DNS globally and run many of the top level domains. We have offices in Ireland, Philly, Toronto, China and London
- #4: So before we talk about making the most of device diversity it makes sense to look back to see how we got here—how did we cope with previous seismic shifts in media It’s quite instructional to look at this history and apply the lessons to where we are now, with the huge diversity coming to the web.
- #5: Approximately 10” long, 8” wide Binding, pages, a cover Text and pictures Writing on both sides of the page
- #6: Production methods have changed - authoring tools have changed - costs have changed, - the availability has changed but the core product is pretty much exactly the same as it was 1200 years ago The user interacts with this modern book identically to the older version. In the well over 1,000 years that books have been around, the user interaction with it has remained identical.
- #8: This would probably not be too alien to a person from 1930 .. because it’s very very similar in most ways It still has speaker, tuning dial and volume. User interaction and usage is pretty much exactly the same as the model from 80 years ago.
- #9: Finally TV, probably the most influential mass medium ever. Let’s look at how it has evolved
- #10: After about 5 decades of operation, the image has improved in the last decade and the device is slimmer and wider, but this is still fundamentally the same thing: a screen that you interact with more or less passively from across the room. Even the resolution was static until very recently. The programs have arguably gotten worse
- #12: So we’ve just seen 3 mass media for which the user interaction has scarcely changed one but What about this new mass medium, the web? The web is only about 20 years old How has it fared, by comparison? Well, the web has been inextricably intertwined with the evolution of the PC, on which it has traditionally depended. So let’s look at how the PC has evolved/ So how has the humble PC evolved over the lifetime of the web?
- #13: (In case it’s not obvious, I draw my own pictures, and I’m an engineer rather than an artist) The web was invented in about 1990 Big clunky PC The NeXT machine on which it was built had resolution 1120×832 Let’s have a look at the device on which the web runs—the humble PC—and chart its evolution over the decades that the web has existed
- #14: This was around the time that Amazon was getting really big and the dotcom boom was well under way at this point Moore’s Law ensured that this machine was way more powerful than the one from 1995 By this time we had JavaScript and Flash
- #15: PC has shrunken, the CPU is a lot faster We now have HTML 4, great browsers, streaming video and real multimedia on the PC
- #16: So even though the CPU power and memory of the PC have increased manyfold, and the software and content available to it have gotten vastly richer, the other aspects—the interface elements— have not: the screen is about the same size, the keyboard is identical, so too is the mouse
- #17: In a world where exponential is normal, we have something unusual—linear growth and an almost flat line So while this platform that the web is built on has improved radically in some respects, it has scarely improved at all in other respects
- #18: The fact that this has been true for essentially all of a web developer’s life has lulled us into a false sense of security Our entire toolchain, our entire publishing system and set of expectations has been lulled into a false sense of security: that the web is 1024x768 + keyboard + mouse Turkey example from the black swan
- #19: But this lack of evolution from an interface point of view was completely up-ended very recently. The web is finally escaping the PC prison, the shackles of a limited mobility, limited interface options We’re finally exiting the dark ages of the web, the age of gloomy green cathode ray tubes and floppy disks and nerds—when the web was fettered by limited hardware I call this the dark ages of the web because, while it seemed like it was booming, it wasn’t yet close to reaching its potential. It was only getting started. Jeremy Keith: consensual hallucination
- #20: So, in summary, for a couple of decades we’ve had the situation depicted above. Most people figured that they could forget about everything left of this gap, and thats what they did Apart from Japan
- #21: But now look what’s happened. Our comfort zone has been rocked by the addition of countless devices with different form factors and capabilities .. and this isn’t just about mobile web—I’m using the term very loosely. It’s also about TV. “Mobile web” has come to mean “non PC” web.
- #22: And it isn’t just a question of size, this table summarizes the difference Galaxy Note vs T39: 547 iPad 3 vs T39: 2500 So it is coping with this vast new array of interactions and target devices that people suddenly need help with. Pixel density Nobody has yet come up with a good way to classify these device types and interaction models, let alone deal with. It absolutely defies easy classification. There is no one scheme that works across the board. SO THIS MY FIRST IMPORTANT POINT—THE WEB HAS SUDDENLY CHANGED WITH A SPEED THAT WE HAVE NEVER SEEN IN A MASS MEDIA BEFORE. THESE CHANGES ARE ARE TO HARD TO DEAL WITH.
- #24: So with in this new enlightenment period of the web, what can we learn from the evolution of previous media?
- #25: Telivision was born in the 1920’s but really became popular much later In1936 the BBC began transmitting the world's first public regular high-definition service The first TV-native broadcasts were the ones that really used the medium to its full advantage: People reading the news, people reading books So it was about 20-50 years before the medium really found its groove
- #26: These examples here are Apple’s and Dell’s websites from the late 90’s
- #28: But I don’t just mean the mobile web, I mean the “broader web”—the web that isn’t just desktop. TVs and cars, for example
- #29: I struggle to communicate to people what I feel about the retro-fitting approach to this new medium and why automatic approachs are wrong but I’ll try a couple of examples to demonstrate what I mean Nobody disputes that this is a good painting
- #30: But the same thing retro-fitted to a new frame isn’t nearly so compelling Can you really take something that’s good and shoe-horn it into a new setting in the hope that it will work?
- #31: Equally nobody would dispute that this sequence of pictures and descriptions is a poor representation of ....
- #32: Experiences need to be designed for their setting and context and physical media I don’t mean to suggest that every multi-device website equals the Sistine chapel, but let’s not limit our imagination to the capabilities of the previous media. This painting was’t converted from some other experience, it was designed to fit this exact canvas. That’s why it’s great.
- #34: (Or do you want to cling to vaudeville shows and reading books on tv?)
- #35: So how do you in fact solve this problem of the newly diverse web? This is obviously a huge problem (as evidenced by this conference), so we need all the help we can get But the problem is worth solving because the opportunity is huge—6 billion mobile devices, many more coming
- #36: There are loads of tools available but pretty much all of them are still mired in the mono web. They’re going to take a long time to change, because it’s really hard. Yes, there are plug-ins for Wordpress etc., but they’re not really embracing the problem in a holistic way So for now, you’re on your own.
- #37: Like the early aviation pioneers, we’re sort of on our own here, faces covered with oil, hand-starting engines We have to build and use our own tools, like the early days of the web all over again Client-side librariesjQuery MobileSencha TouchJavaScript feature testsModernizrMedia queriesWe need all the help we can get
- #38: But in this new world there is one thing that is abundantly clear—the single most important thing: the device is the canvas
- #39: And to maximise that canvas is to make embrace the new possibilties
- #40: There are many tools available to help you with this problem. The rate of change is such that no one tool can fix this problem—there’s no silver bullet One tool that can help you a lot is device detection. This tool has been overlooked a lot
- #41: On the one had you get all this anger and religion Certain people have been hurt by device detection in the past but don’t confuse the weapon with the motivation.
- #42: But on the other hand, everyone is using it So what gives? Why is this awful, unworkable, unreliable, evil solution being used by everyone, most of all the biggest internet brands that care most about their mobile experience? Even desktop sites use it—most software download pages also use it to default to the right options So I’ll go through a couple of the purported issues and address them one by one and try to understand why it was overlooked
- #43: So let’s have a look at the various claims. I want to correct some some of the visceral reactions that people have. Fragile: It would be like suggesting that a car company’s cars don’t go. It’s dumb to suggest that this is a problem. You will sometimes see people on twitter saying that they’ve had bad experience as a result of a misdetection, seizing upon it with glee as a victory. Bad a bad implemention is not the same as a bad idea. This is like saying I had a bad bottle of wine once, therefore all wine is bad. People rejoice when it fails. Confirmation error: people seek instances that confirm their beliefs
- #44: Maybe the reason that all these brands are using it is that they have tons of resources From a coding logic point of view, these two chunks of code are more or less the same The only difference is where they run I agree that one is more client side skills, the other more server-side. Tastes vary but it’s difficult to argue that one approach is more difficult thatn the other
- #45: Again, your skills may vary but I posit that this is not difficult for an administrator/programmer
- #46: There are degrees of masquerade, this is about the devices that truely try to be somebody else Anyone who says this simply doesn’t know what they’re talking about This is one of the masquerading devices here—a grey market Chinese device One of the other ones was the original Palm Pre A huge number of devices do indeed have the “Mozilla” pre-amble, but that’s OK
- #47: .. so let’s look into this a little more. This is probably the most insideous & pernicious claim. So, evil according to what morality?
- #48: Wrong according to who? There seems to a tacit agreement that this is true, but where did this originate? Certainly not with Tim Berners-Lee These documents are very carefully written and it could hardly be clearer The sceptic might then wonder if they’d made a mistake and regretted this text?
- #49: Maybe they meant something else? Perhaps in their excitement over the new protocol they made a naive mistake So then the sceptic might say “well, didn’t the W3C decide that one web was the right way and hence user agent detection is evil?”
- #50: Often taken to mean that everyone gets the same thing This is a really carefully worded paragraph, published in 2008
- #51: By any reasonable measure, the more modern usage of detection us surely reasonable as well as useful Both physical and software capabilities need to be catered to
- #53: More of an investigative tool than a test tool
- #54: From a web publishing point of view the killer advantage of server-side device detection is..
- #55: To do anything else is like trying to make a truck-car or a airplane-car It’s just not pragmatic This is what’s possible if you use all the best tools YouTube Featherlite example
- #57: Not knowing the device type is surely a fatal flaw in delivering a rich experience Devices are supposed to have “Mobile Safari” in their UAs, but don’t consistently do so
- #60: We’re not religious about this, we just think it is one of many techniques But why is the future friendly thing such a big deal? We’re happy to to update our OSes, our software, our programming languages, our break points? Why is this any different? Just like with RWD, sensible defaults With the new web maybe server-side skills are the new normal
- #61: Feature phones: at least make sure that you’re not getting traffic from these devices
- #62: If you use only half of the tools you’re going to deliver sub standard experiend There’s never one best solution—you can’t make a good plane-car or truck-car