Making the Web Work on Mobile
First presented by dotMobi CTO Ronan Cremin at BDConf 2012
How we got
here
Book, 800 AD
pages

33cm

24cm

cover
Book, 2012 AD
pages

33cm

cover

24cm
Radio, 1930

speaker

tuner

volume
Radio, 2012

speaker
tuner

volume
TV, 1950

screen
controls
TV, 2012

screen
controls
Previous media: relatively stable evolution
• Previous media have evolved quite a bit in their lifetime
– Sophistication
–...
But what
about
the web?
PC, 1995
PC, 2000
PC, 2005
PC, 2012
1024 x 768

keyboard

mouse
capability

PC: computing capability, physical interface richness

RAM

MIPS

richness of interface
screen size
screen res...
1024 x 768
+
keyboard
+
mouse
=

A4
“Letter”
of the web
Web evolution engendered by device diversity
dark ages of the web—
the monoweb

1990

age of enlightenment—
the polyweb

2...
2002

mind the
gap

portable

capable
2012

mobile =
spectrum of
device types
Contexts, interfaces, input methods
Point 1—a new landscape
• The emergence of new devices is changing the
way we access the web
• The rate of change is unpre...
Lessons from
new media
Example: television
• The first television shows
were people simply
reading books, vaudeville
shows
• 20 years passed befo...
Example: desktop web
•

Many early websites mimiced print
– images & imagemaps used in place of web-native content

•

15+...
Adapting to new media
• Content creators struggle to understand new
media
• Initial uses mimic those of previous media
• N...
Web on mobile, new medium
•

Mobile web uses HTTP, HTML, CSS and JavaScript,
just like the web we know

•

But it is effec...
portion of north ceiling
spandrel
corner pendentive
portion of south wall
corner pendentive
spandrel
portion of east wall
Good experiences are tailored, not
repurposed
•

Key lesson from previous media:

•

Good experiences are tailored to the
...
Point 2—design for the new medium
•

The new web isn’t problem to be solved, it’s an opportunity to be
embraced

•

Just w...
Embracing
the new web
Existing tool chain is still evolving

CMS

• Industry is still
grappling with the
changes
• Situation not going to
change...
The device is the canvas
• In this renaissance of the web, the
device is the canvas—from feature
phone to TV
• But the can...
Know your canvas—device awareness
•
•

•

The new medium is defined by the
devices that constitute it
Embracing the device...
Server-side
device
awareness
Device awareness: spawn of satan?
•

"Sniffing, as the practice has been called, is a fragile one, however.”

•

“Browser ...
Or best-of-breed tool?
Server-side device detection used by:
Claim: device detection is fra .
• Most common explanation: device DB goes out of date.
– Clearly untrue—the vendors of su...
device detection v media queries
media queries

server-side detection

@media screen and (min-width: 480px) {
/* smartphon...
“Everyone pretends to be everyone else”
• 12,000+ distinct devices,
<5 nefarious
masquerades (0.05%)
• Remaining devices e...
Claim: device detection is wrong
• There is a lot of strong
opinion about what’s
right and wrong
• But in fact device
dete...
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-A...
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 f...
W3C’s “one web” is often misunderstood
Mobile Web Best Practices 1.0

One Web means making, as far as is reasonable, the s...
So where does the perception come from?
•

Mostly stems from working around
browser flaws in early days of web

•

Importa...
Being
device
aware
prism.mobiforge.com
100% control of delivered content
CONTEXTS
INTERFACES
SCREENS

• Send only what you need
to each
device/experience
• Huge ...
Performance
• Each device gets only what it
needs, with cascade of
benefits:
– Reduced loading time
– Reduced rendering ti...
Performance of RWD-only sites

286Kb

286Kb

286Kb
Leverage device capabilities
•

JavaScript feature tests are very useful
but:
– don’t know what the device is
– know only ...
Full control of site architecture
•

All options supported

1

site.com

– Multiple different views on single
URL
– Differ...
Statistics and analytics
• Server-side device detection is only way to get
device statistics from sites
• Used by Omniture...
Disadvantages
• Some user settings can’t be known in
advance e.g. cookie support, orientation
• Server-side skills require...
Future friendliness
• Device databases need to be updated, there
is external dependency
– But so too do server OSes, libra...
Point 3—use all the tools available
• In this new web environment you need all of the help
you can get
• There are no silv...
Wrap up
Summary—the landscape
• There are macro-level changes happening on the web, a web
renaissance is beginning

• New devices ...
Summary—the tools

• There are many tools to help
• Harnessing the full potential of the web requires
knowledge of the dev...
“Mobile gives the web wings”
- Mary Meeker

• But only if you use them
http://deviceatlas.com/

http://gomobi.info/

http://deviceatlas.com/fut
ureofthemobileweb
@device_atlas
Making the web work on mobile: DeviceAtlas
Making the web work on mobile: DeviceAtlas
Making the web work on mobile: DeviceAtlas
Making the web work on mobile: DeviceAtlas
Making the web work on mobile: DeviceAtlas
Upcoming SlideShare
Loading in …5
×

Making the web work on mobile: DeviceAtlas

1,146 views

Published on

With the explosion of new types of connected devices, there is a whole new challenge for companies to deliver the right experience across a huge range of devices.

Is it possible to magically create content that suits all devices and use cases automatically? This is not possible with any other medium, why should the web be different?

•How do big online brands adapt their websites to work on different devices
•What specific technology approaches are used to accomplish this.
•Case Studies of leading webco’s who adapt content according to device type; Google, Netflix, Amazon - a look at what goes on behind the scenes
•What is the best way to deliver different experiences to different classes of devices

This presentation was originally presented by Ronan Cremin, CTO dotMobi at BDConf 2012 focusing on the strategies major web players employ to make the web work on all devices and platforms.

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,146
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • 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.
  • Approximately 10” long, 8” wide
    Binding, pages, a cover
    Text and pictures
    Writing on both sides of the page
  • 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.
  • 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.
  • Finally TV, probably the most influential mass medium ever.
    Let’s look at how it has evolved
  • 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
  • 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?
  • (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
  • 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
  • PC has shrunken, the CPU is a lot faster
    We now have HTML 4, great browsers, streaming video and real multimedia on the PC
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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.
  • So with in this new enlightenment period of the web, what can we learn from the evolution of previous media?
  • Telivision was born in the 1920’s but really became popular much later
    In1936 the BBC began transmitting the world&apos;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
  • These examples here are Apple’s and Dell’s websites from the late 90’s
  • 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
  • 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
  • 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?
  • Equally nobody would dispute that this sequence of pictures and descriptions is a poor representation of ....
  • 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.
  • (Or do you want to cling to vaudeville shows and reading books on tv?)
  • 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
  • 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.
  • 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
  • But in this new world there is one thing that is abundantly clear—the single most important thing: the device is the canvas
  • And to maximise that canvas is to make embrace the new possibilties
  • 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
  • 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.
  • 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
  • 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
  • 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
  • Again, your skills may vary but I posit that this is not difficult for an administrator/programmer
  • 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
  • .. so let’s look into this a little more.
    This is probably the most insideous &amp; pernicious claim.
    So, evil according to what morality?
  • 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?
  • 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?”
  • Often taken to mean that everyone gets the same thing
    This is a really carefully worded paragraph, published in 2008
  • 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
  • More of an investigative tool than a test tool
  • From a web publishing point of view the killer advantage of server-side device detection is..
  • 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
  • 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
  • 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
  • Feature phones: at least make sure that you’re not getting traffic from these devices
  • 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
  • Making the web work on mobile: DeviceAtlas

    1. 1. Making the Web Work on Mobile First presented by dotMobi CTO Ronan Cremin at BDConf 2012
    2. 2. How we got here
    3. 3. Book, 800 AD pages 33cm 24cm cover
    4. 4. Book, 2012 AD pages 33cm cover 24cm
    5. 5. Radio, 1930 speaker tuner volume
    6. 6. Radio, 2012 speaker tuner volume
    7. 7. TV, 1950 screen controls
    8. 8. TV, 2012 screen controls
    9. 9. 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
    10. 10. But what about the web?
    11. 11. PC, 1995
    12. 12. PC, 2000
    13. 13. PC, 2005
    14. 14. PC, 2012 1024 x 768 keyboard mouse
    15. 15. capability PC: computing capability, physical interface richness RAM MIPS richness of interface screen size screen resolution year 1995 2007
    16. 16. 1024 x 768 + keyboard + mouse = A4 “Letter” of the web
    17. 17. Web evolution engendered by device diversity dark ages of the web— the monoweb 1990 age of enlightenment— the polyweb 2000 2007 2012
    18. 18. 2002 mind the gap portable capable
    19. 19. 2012 mobile = spectrum of device types
    20. 20. Contexts, interfaces, input methods
    21. 21. 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
    22. 22. Lessons from new media
    23. 23. 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
    24. 24. 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
    25. 25. 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
    26. 26. 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
    27. 27. portion of north ceiling spandrel corner pendentive portion of south wall corner pendentive spandrel portion of east wall
    28. 28. 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
    29. 29. 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
    30. 30. Embracing the new web
    31. 31. 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:
    32. 32. 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
    33. 33. 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
    34. 34. Server-side device awareness
    35. 35. 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”
    36. 36. Or best-of-breed tool? Server-side device detection used by:
    37. 37. 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
    38. 38. 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
    39. 39. “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”
    40. 40. 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..
    41. 41. 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.
    42. 42. 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).
    43. 43. 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)
    44. 44. 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.
    45. 45. Being device aware
    46. 46. prism.mobiforge.com
    47. 47. 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
    48. 48. 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
    49. 49. Performance of RWD-only sites 286Kb 286Kb 286Kb
    50. 50. 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?
    51. 51. 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
    52. 52. 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.
    53. 53. 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”
    54. 54. 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?
    55. 55. 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
    56. 56. Wrap up
    57. 57. 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
    58. 58. 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
    59. 59. “Mobile gives the web wings” - Mary Meeker • But only if you use them
    60. 60. http://deviceatlas.com/ http://gomobi.info/ http://deviceatlas.com/fut ureofthemobileweb @device_atlas

    ×