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
18. Web evolution engendered by device
diversity
1990 2007 20122000
dark ages of the web
—the monoweb
dark ages of the web
—the monoweb
age of enlightenment—
the polyweb
age of enlightenment—
the polyweb
26. 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
28. 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
29. 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
30. 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
31. 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
32.
33.
34. portion of north ceiling
portion of south wall
corner pendentive
portion of east wall
corner pendentive
spandrel
spandrel
35.
36. Good experiences are tailored,
not re-purposed
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
37. 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
39. Existing tool chain is still
evolving
• Most existing tools
are either:
– limited
– mired in monoweb
thinking
• Industry is still
grappling with the
changes
• Situation not going to
change any time
soon
AUTHORINGPUBLISHINGCMS
40. 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
41. 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
☐ big screen
☐ touch screen
☒ makes calls
☐ big screen
☐ touch screen
☐ makes calls
☒ big screen
☒ touch screen
☐ makes calls
☒ big screen
☒ touch screen
☐ makes calls
☒ big screen
☐ touch screen
☐ makes calls
☒ big screen
☐ touch screen
43. 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”
45. 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.
46. 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 1945RFC 1945
47. <?php
include './DA/Client.php';
$data = DeviceAtlasCloudClient::getDeviceData();
$width = $data['properties']['displayWidth'];
if (480 < $width) {
// smartphone view
} elseif (600 < $width) {
// narrow view
} elseif (800 < $width) {
// desktop view
} elseif (1024 < $width) {
// wide view
}
?>
@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 */
}
device detection v media queries
vs.
similar complexity levelssimilar complexity levels
media queriesmedia queries server-side detectionserver-side detection
50. 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
CONTEXTSINTERFACESSCREENS
51. Performance
• Each device gets only what it
needs, with 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)
728KB 4KB 4KB
124KB
53KB
46KB
53. 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 | NFC
– model, vendor, operating
system, version
mobile
device?
mobile
device?
has
camera?
has
camera?
supports
touch?
supports
touch?
54. 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
55. • Server-side device detection is only way
to get device statistics from sites
• Used by Omniture, Google Analytics,
Webtrends, IBM CoreMetrics etc.
Statistics and analytics
56. 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”
57. 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?
58. 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
60. 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
61. 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