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.
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
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
28.
29.
30. portion of north ceiling
spandrel
corner pendentive
portion of south wall
corner pendentive
spandrel
portion of east wall
31.
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:
36.
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”
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
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
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
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'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 & 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