1
Introduction
1.1
Purpose
of
the
Document
This
document
sets
out
a
series
of
recommendations
designed
to
improve
the
user
experience
promote
more
effective
delivery
of
the
Web
on
content
to
mobile
devices.
Each
recommendation
is
discussed
in
context
and
brief
explanatory
notes
are
provided.
The
recommendations
are
offered
to
creators,
maintainers
and
operators
of
Web
sites
all
participants
in
the
mobile
value
chain
and
are
intended
as
the
basis
for
assessing
conformance
to
the
mobileOK
trustmark,
which
trustmark.
The
mobileOK
trustmark
is
described
in
the
Mobile
Web
Best
Practices
Working
Group
Charter
and
is
not
developed
in
this
document.
mobileOK
and
techniques
for
implementing
the
Best
Practice
recommendations
will
be
discussed
in
companion
documents.
1.2
How
the
Best
Practices
are
Organized
The
document
is
organized
as
follows:
Introduction.
Describes
the
audience,
purpose
and
scope
of
the
document.
Requirements.
An
illustration
of
the
type
of
problems
that
the
Best
Practices
are
intended
to
ameliorate.
Delivery
Context.
Discusses
the
environment
within
which
mobile
access
to
the
Web
is
realized,
with
particular
reference
to
adaptation.
Overview
of
Best
Practices.
A
discussion
of
the
organization
of
the
Best
Practices,
and
sources
from
which
they
were
derived.
Best
Practices.
The
statements
themselves.
Conformance
and
mobileOK.
A
brief
conformance
statement
and
reference
to
the
mobileOK
documentation.
Appendices
Acknowledgements
References
1.3
Audience
Readers
of
this
document
are
expected
to
be
familiar
with
the
creation
of
Web
sites,
and
to
have
a
general
familiarity
with
the
technologies
involved,
such
as
Web
web
servers
and
HTTP.
Readers
are
not
expected
to
have
a
background
in
mobile-specific
technologies.
Our
intention
is
to
make
it
clear
to
all
involved
what
the
Best
Practices
best
practices
are,
and
hence
establish
a
common
basis
of
understanding.
As
a
result
of
wishing
to
be
clear
to
those
not
already
involved
in
the
development
of
mobile
friendly
content,
some
of
our
statements
may
appear
to
be
obvious
or
trivial
to
those
with
experience
in
this
area.
The
document
is
not
targeted
solely
at
developers;
others,
developers
and
others
such
as
interaction
and
graphic
designers
are
encouraged
to
read
it.
1.2.1
Participants
in
the
Mobile
Value
Chain
Participants
in
the
mobile
value
chain
include:
-
Web
Site
Developers
Original
content
developers
together
with
portal
operators
and
other
aggregators
of
content
who
deliver
non-original
content
to
mobile
and
other
users.
-
Mobile
Network
Operators
Who
may
transform
content
when
it
passes
from
the
Internet
to
their
networks,
and
who
may
in
addition
operate
portals.
-
Browser
and
Delivery
Platform
Developers
Who
realize
content
for
users
to
perceive.
-
Authoring
Tool
Developers
Developers
of
tools
to
assist
with
content
production
(authoring).
-
Content
Manipulation
Tools
Developers
Developers
of
tools
to
assist
with
content
serving
and
repurposing.
-
Conformance
Testers
Those
involved
in
the
production
and
execution
of
testing
processes.
1.4
1.3
Scope
The
scope
of
these
Best
Practices
is
laid
out
in
"Scope
of
Mobile
Web
Best
Practices"
[Scope]
.
In
summary,
summary
this
document
refers
primarily
to
the
extension
of
Web
web
browsing
onto
mobile
devices.
The
Best
Practice
recommendations
refer
to
delivered
content.
While
they
are
clearly
relevant
to
the
processes
of
content
creation
and
rendering
on
devices,
they
are
not
intended
to
be
Best
Practices
for
those
activities.
As
the
goal
of
the
document
is
to
specify
Best
Practices
for
delivery
to
mobile
devices,
statements
that
do
not
have
a
specific
mobile
aspect
are
not
included.
In
particular,
particular
many
Web
Content
Accessibility
[WCAG]
guidelines
are
general
to
all
forms
of
Web
access
and
are
not
repeated
here
unless
they
have
a
specific
mobile
interpretation.
Examples
of
general
good
practice
which
have
a
specific
mobile
interpretation
include
"Error
Messages"
'Error
Messages'
and
"Color".
'Color'.
1.4.1
1.3.1
Phasing
As
discussed
in
the
Scope
document
[Scope]
there
are
many
aspects
to
Mobile
Web
Best
Practices.
At
present,
for
For
example,
at
present,
the
design
and
construction
of
many
Web
sites
and
pages
make
for
a
poor
user
experience
when
they
are
viewed
on
a
mobile
device.
The
quality
While
improving
those
Web
sites
is
only
one
aspect
of
improving
the
user's
Web
experience
via
a
mobile
device
depends
significantly
on
user
experience,
significant
improvements
can
be
achieved
in
this
way,
hence
the
usability
of
Web
sites,
of
browsers,
and
first
phase
of
the
device
itself.
Although
browser
usability
and
device
usability
are
important
(for
reading,
navigating,
and
interacting
work
is
concerned
with
content),
this
document
focuses
primarily
on
Best
Practices
providing
guidelines
for
improving
site
usability.
Web-site
and
content
developers.
In
future
phases
other
aspects
may
be
considered
-
e.g.
Best
Practices
best
practices
as
applied
to
adaptation
and
devices.
Also
in
future
phases
the
scope
of
the
recommendations
may
be
extended
beyond
"Traditional
'Traditional
Web
Browsing"
Browsing'
into
fields
such
as
multimodal
interaction.
1.3.2
Usability
There
are
three
aspects
of
mobile
usability
-
namely
site,
device,
and
browser
usability.
All
three
together
contribute
to
the
user
experience.
These
three
aspects
are
defined
as
follows:
Site
usability
relates
to
the
structure,
content
and
layout
rules
of
a
site
and
is
a
measure
of
the
effectiveness
of
the
mobile
web
site.
Device
usability
pertains
to
the
capability
of
the
equipment
being
used
easily
and
effectively.
"Easily"
refers
to
a
specified
level
of
acceptability
and
comfort
of
use;
"Efficiency"
relates
to
the
resources
expended
in
relation
to
the
accuracy
and
completeness
with
which
users
achieve
their
goals.
In
particular,
device
usability
focuses
on
keypad
design,
display,
fast
browser
access
and
UI
styles.
Browser
usability
defines
the
ease
of
using
a
browser
effectively
namely
performing
the
three
functions
reading,
navigating
or
interacting.
The
ease
of
interaction,
page
rendering,
caching
etc.
are
issues
that
are
frequently
used
to
judge
browser
usability.
While
recognizing
the
contribution
of
device
and
browser
usability
to
the
overall
user
experience,
this
document
focuses
on
site
usability.
1.3.3
One
Web
The
recommendations
in
this
document
are
intended
to
improve
mobile
experience
of
the
Web
on
mobile
devices.
While
the
recommendations
are
not
specifically
addressed
at
the
desktop
browsing
experience
it
must
be
understood
that
they
are
made
in
the
context
of
wishing
to
work
towards
'One
Web'.
As
discussed
in
[Scope]
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
way
across
all
devices.
Some
services
and
information
are
more
suitable
for
and
targeted
at
particular
user
contexts.
Some
services
have
a
primarily
mobile
appeal
(location
based
services,
for
example).
Some
have
a
primarily
mobile
appeal
but
have
a
complementary
desktop
aspect
(perhaps
for
complex
configuration
tasks).
Still
others
have
a
primarily
desktop
appeal
but
a
complementary
mobile
aspect
(possibly
for
alerting).
Finally
there
will
remain
some
Web
applications
which
have
a
primarily
desktop
appeal
(lengthy
reference
material,
rich
images,
perhaps).
It
is
likely
that
application
designers
and
service
providers
will
wish
to
provide
the
best
possible
experience
in
the
context
in
which
their
service
has
the
most
appeal.
However,
while
services
may
be
most
appropriately
experienced
in
one
context
or
another,
it
is
considered
best
practice
to
provide
a
reasonable
experience
irrespective
of
the
device,
and
as
far
as
is
possible,
not
to
exclude
access
from
any
particular
class
of
device.
From
the
perspective
of
this
document
this
means
that
services
should
be
available
as
some
variant
of
HTML
over
HTTP.
1.4
Default
Delivery
Context
The
recommendations
refer
to
delivered
content.
Given
the
range
of
different
mobile
device
types
which
have
different
properties
and
different
features
the
Best
Practices
Working
Group
has
defined
a
Default
Delivery
Context
.
Delivery
Context
is
used
with
the
specific
meaning
defined
in
the
Device
Independence
Glossary
[DIGLOSS]
.
The
document
makes
reference
to
the
Default
Delivery
Context
in
two
ways:
If
the
delivered
content
does
not
result
from
an
adaptation
process
-
e.g.
the
content
is
statically
defined
as
HTML
stored
in
files
-
then
the
delivered
content
should
be
suitable
for
the
Default
Delivery
Context
and
should
comply
with
the
Best
Practice
Statements.
If
an
adaptation
process
is
used,
then
information
that
is
known
about
the
Delivery
Context
can
be
used
to
vary
the
delivered
content
to
make
it
more
suitable
for
that
Delivery
Context
or
to
provide
an
enhanced
user
experience.
The
default
delivery
context
is
defined
as
follows:
-
Usable
Screen
Width
120
Pixels.
-
Mark
Up
Language
Support
XHTML
-
Basic
Profile.
-
Character
Encoding
UTF-8.
-
Image
Format
Support
JPEG
GIF
89a
(non-interlaced,
non-transparent,
non-animated).
-
Maximum
Total
Page
Weight
20k
Bytes.
-
Colors
Web
safe.
-
Style
Sheet
Support
External
CSS
Level
1,
with
internal
definition
of
style
and
font
properties.
1.5
Relationship
to
other
Best
Practices
best
practices
and
recommendations
These
recommendations
are
in
part
derived
from
the
Web
Content
Accessibility
Guidelines
[WCAG]
.
As
noted
above,
WCAG
guidelines
are
supplementary
to
the
Mobile
Web
Best
Practices,
whose
scope
is
limited
to
matters
that
have
a
specific
mobile
relevance.
This
document
builds
on
some
of
the
concepts
described
by
the
Device
Independence
Working
Group
(DIWG)
in
the
Device
Independence
Principles
[DIP]
.
The
document
also
discusses
the
notion
of
device
and
delivery
channel
characteristics,
which
the
DIWG
has
named
described
in
terms
of
a
"Delivery
Context"
[DCODI]
.
In
addition,
the
document
uses
some
terminology
from
DIWG's
Glossary
of
Terms
for
Device
Independence
[DIGLOSS]
.
The
BPWG
will
develop
a
companion
document
describing
techniques
[Techniques]
by
which
the
Best
Practice
best
practice
statements
in
this
document
can
be
implemented.
1.6
Longevity
and
Versioning
How
the
Best
Practices
are
Organized
The
Best
Practices
have
been
written
at
a
level
document
is
organized
as
follows:
Introduction.
Describes
the
audience,
purpose
and
scope
of
generality
that
allows
them
to
be
applicable
across
a
range
the
document.
Requirements,
An
illustration
of
markup
languages.
They
have
been
written
with
enduring
properties
the
type
of
mobile
access
problems
that
the
Best
Practices
are
intended
to
ameliorate.
Architecture.
Discusses
the
Web
in
mind.
While
environment
within
which
the
factors
identified
in
3.7
Default
Delivery
Context
,
such
as
screen
dimensions,
will
change
over
time,
it
seems
likely
that
mobile
web
is
realized,
with
particular
reference
to
adaptation.
Overview
of
Best
Practices.
A
discussion
of
the
distinguishing
features
organization
of
mobile
access
such
as
cost
the
best
practices,
and
difficulty
of
input
will
remain
issues.
sources
from
which
they
were
derived.
-
This
document
will
be
reviewed
from
time
to
time.
When
necessary,
an
updated
version
will
be
released
with
clear
documentation
as
Best
Practices.
The
statements
themselves.
Conformance
and
mobileOK.
A
brief
conformance
statement
and
pointer
to
the
changes
that
have
been
introduced.
mobileOK
documentation.
Annexes
Acknowledgements
References
2
Requirements
This
section
discusses
the
requirements
of
the
Mobile
Web
Best
Practice
statements
in
section
5.
The
statement
of
requirements
is
intended
to
be
illustrative
rather
than
exhaustive
or
complete.
2.1
Presentation
Issues
Today,
Many
Web
pages
today
are
laid
out
for
with
presentation
on
desktop
size
displays,
displays
in
mind,
and
exploit
capabilities
make
use
of
the
facilities
provided
by
desktop
browsing
software.
Accessing
such
a
Web
page
on
a
mobile
device
often
results
in
a
poor
poor,
or
unusable
experience.
Contributing
factors
include
pages
to
this
poor
experience
is
that
the
content
does
not
being
laid
lay
out
as
intended.
Because
intended,
and
because
of
the
limited
screen
size
and
the
limited
amount
of
material
on
the
page
that
is
visible
to
the
user,
things
that
are
intended
to
be
viewed
together
are
not
presented
together
-
context
and
overview
are
lost.
Because
of
the
limited
screen
size,
size
the
subject
matter
of
the
page
may
require
considerable
scrolling
to
be
visible,
especially
if
the
top
of
the
page
is
occupied
by
images
and
navigation
links.
In
these
cases
the
user
gets
no
immediate
feedback
as
to
whether
their
retrieval
has
resulted
in
the
right
content.
It
is
particularly
important
in
the
mobile
context
to
help
the
user
create
a
mental
image
of
the
site.
This
can
be
assisted
by
adopting
a
consistent
style
and
contrariwise
can
be
considerably
diminished
by
an
uneven
style.
2.2
Input
Mobile
device
input
is
often
difficult
hard
when
compared
with
use
of
a
desktop
device
equipped
with
a
keyboard.
Mobile
devices
such
as
phones
often
have
only
a
very
limited
keypad,
with
small
keys,
and
there
is
frequently
no
pointing
device.
One
of
the
difficulties
of
the
mobile
Web
web
is
that
URIs
are
very
difficult
hard
to
type.
Lengthy
type,
and
lengthy
URIs
and
those
that
contain
a
lot
of
punctuation
are
particularly
difficult
hard
to
type
correctly.
Because
of
the
limitations
of
screen
and
of
input,
forms
are
hard
to
fill
in.
This
is
in,
both
because
navigation
between
fields
may
not
occur
in
the
expected
order
and
because
of
the
difficulty
in
typing
into
the
fields.
While
many
modern
devices
provide
back
buttons,
some
do
not,
and
in
some
cases,
where
back
functionality
exists,
users
may
not
know
how
to
invoke
it.
This
means
that
it
is
often
very
hard
to
recover
from
errors,
broken
links
and
so
on.
2.3
Bandwidth
and
Cost
Mobile
networks
can
be
slow
compared
with
fixed
data
connections
and
often
have
a
measurably
higher
latency.
This
can
lead
to
long
retrieval
times,
especially
for
lengthy
content
and
for
content
that
requires
a
lot
of
navigation
between
pages.
Mobile
data
transfer
often
costs
money.
The
fact
that
mobile
devices
frequently
support
only
limited
types
of
content
means
that
a
user
may
follow
a
link
and
retrieve
information
that
is
unusable
on
their
device.
Even
if
the
content
type
can
be
interpreted
by
their
device
there
is
often
an
issue
with
the
experience
not
being
satisfactory
-
for
example,
example
larger
images
may
only
be
viewable
in
small
pieces
and
require
considerable
scrolling.
Web
Requests
for
web
pages
can
contain
result
in
the
delivery
of
content
that
the
user
has
not
specifically
requested
-
especially
advertising
and
large
site
images.
In
the
mobile
world
this
extra
material
contributes
to
poor
usability
and
may
add
considerably
to
the
cost
of
the
retrieval.
2.4
User
Goals
Mobile
users
typically
have
different
interests
to
users
of
fixed
or
desktop
devices.
They
are
likely
to
have
more
immediate
and
goal-directed
intentions
than
desktop
Web
web
users.
Their
intentions
are
often
to
find
out
specific
pieces
of
information
that
are
relevant
to
their
context.
An
example
Examples
are
frequently
given
of
such
a
goal-directed
application
might
be
travel
related
applications,
where
the
user
requiring
might
require
specific
information
about
schedules
for
a
journey
they
schedules.
Other
examples
are
currently
undertaking.
frequently
given
of
time
filling
entertainment
applications,
where
people
are
filling
otherwise
dead
time
while
traveling.
Equally,
On
the
other
hand,
mobile
users
are
typically
less
interested
in
lengthy
documents
or
in
browsing.
The
ergonomics
of
the
device
are
frequently
unsuitable
for
reading
lengthy
documents,
and
users
will
often
only
access
such
information
from
mobile
devices
as
a
last
resort,
because
more
convenient
access
is
not
available.
2.5
Advertising
Developers
of
commercial
Web
web
sites
should
note
that
different
commercial
models
are
often
at
work
when
the
Web
is
accessed
from
mobile
Mobile
devices
as
compared
with
desktop
devices.
For
example,
some
mechanisms
that
are
commonly
used
for
presentation
of
advertising
material
do
not
work
well
on
small
devices
and
are
therefore
contrary
to
the
Best
Practice
recommendations.
Recommendations.
It
is
not
the
intention
of
the
MWI
to
limit
or
to
restrict
advertising;
rather
it
is
the
intention
that
the
user
experience
of
the
site
as
a
whole,
including
advertising,
if
any,
is
as
effective
as
possible.
2.6
Device
Limitations
As
noted
above,
the
restrictions
imposed
by
the
keyboard
and
the
screen
typically
require
a
different
approach
to
page
design
than
that
used
for
desktop
devices.
As
detailed
in
the
Scope
document
[Scope]
,
various
other
limitations
may
apply
to
mobile
devices,
and
these
have
an
impact
on
the
usability
of
the
Web
from
a
mobile
device.
Mobile
browsers
often
do
not
support
scripting
or
plug-ins,
which
means
that
the
range
of
content
that
they
support
is
limited.
In
many
cases
the
user
has
no
choice
of
option
as
to
which
browser
to
use,
and
upgrading
it
in
many
cases
upgrade
of
the
browser
is
not
possible.
Some
activities
associated
with
rendering
Web
web
pages
are
computationally
intensive
-
for
example
re-flowing
pages,
laying
out
tables,
processing
unnecessarily
long
and
complex
style
sheets
and
handling
invalid
markup
mark
up
[T-MOB]
.
Mobile
devices
There
is
typically
have
quite
limited
processing
power
available
to
carry
out
such
computations,
which
means
that
page
rendering
may
mean
they
take
a
noticeable
time
to
complete.
As
well
as
introducing
a
noticeable
delay,
such
processing
uses
Such
computations
also
use
more
power
as
does
communication
with
and
deplete
the
server.
battery.
Reducing
the
amount
of
communication
can
conserve
charge.
Many
devices
have
limited
memory
available
for
pages
and
images,
and
exceeding
their
memory
limitations
results
in
incomplete
display
and
can
cause
other
problems.
2.7
Advantages
In
discussing
the
limitations
of
mobile
devices
for
delivery
of
Web
content
it
is
easy
to
lose
sight
of
the
fact
that
they
are
extremely
popular
and
very
common.
This
popularity
largely
stems
at
present
from
them
their
being:
-
personal
personal,
-
personalizable
-
portable
- connected
and
increasingly
multi-functional
multi-function
beyond
their
original
purpose
of
voice
communications.
In
addition
to
Beyond
these
factors,
the
advantages
of
mobile
devices
will
increasingly
include:
By
way
of
As
an
illustration
of
some
of
these
factors:
First,
unlike
the
fixed
Web,
the
mobile
Web
can
will
go
where
you
go.
You
do
not
No
longer
will
you
have
to
remember
to
do
something
on
the
Web
when
you
get
back
to
your
computer.
You
can
do
it
immediately,
within
the
context
that
made
you
want
to
use
the
Web
in
the
first
place.
Moreover,
with
mobile
devices
appearing
in
all
shapes
and
forms,
and
with
a
growing
variety
of
features
like
location
technology,
cameras,
voice
recognition,
touch
screens
etc,
the
Web
can
reach
a
much
wider
audience,
and
at
all
times
in
all
situations.
It
has
the
opportunity
to
reach
into
places
where
wires
cannot
go,
to
places
previously
unthinkable
(e.g.
providing
medical
info
to
mountain
rescue
scenes)
and
to
accompany
everyone
as
easily
as
they
carry
the
time
on
in
their
wristwatches.
Finally,
today,
many
more
people
have
access
to
mobile
devices
than
access
to
a
desktop
computer.
This
is
likely
to
be
very
significant
in
developing
countries,
where
Web-capable
web-capable
mobile
devices
may
play
as
similar
a
similar
role
in
for
deploying
wide-spread
Web
access
as
the
mobile
phone
has
played
for
providing
"plain
old
telephone
service".
3
Delivery
Context
Model
Architecture
Delivery
Context
is
used
with
the
specific
meaning
defined
in
the
Device
Independence
Glossary
[DIGLOSS]
.
3.1
One
Web
The
recommendations
in
this
document
are
intended
to
improve
the
experience
of
the
Web
on
mobile
devices.
While
the
recommendations
are
not
specifically
addressed
at
the
desktop
browsing
experience,
it
must
be
understood
that
they
are
made
in
the
context
of
wishing
to
work
towards
"One
Web".
As
discussed
in
the
Scope
document
[Scope]
,
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
(see
5.1.1
Thematic
Consistency
of
Resource
Identified
by
a
URI
).
Some
services
have
a
primarily
mobile
appeal
(location
based
services,
for
example).
Some
have
a
primarily
mobile
appeal
but
have
a
complementary
desktop
aspect
(for
instance
for
complex
configuration
tasks).
Still
others
have
a
primarily
desktop
appeal
but
a
complementary
mobile
aspect
(possibly
for
alerting).
Finally
there
will
remain
some
Web
applications
that
have
a
primarily
desktop
appeal
(lengthy
reference
material,
rich
images,
for
example).
It
is
likely
that
application
designers
and
service
providers
will
wish
to
provide
the
best
possible
experience
in
the
context
in
which
their
service
has
the
most
appeal.
However,
while
services
may
be
most
appropriately
experienced
in
one
context
or
another,
it
is
considered
best
practice
to
provide
as
reasonable
experience
as
is
possible
given
device
limitations
and
not
to
exclude
access
from
any
particular
class
of
device,
except
where
this
is
necessary
because
of
device
limitations.
From
the
perspective
of
this
document
this
means
that
services
should
be
available
as
some
variant
of
HTML
over
HTTP
(see
3.7
Default
Delivery
Context
).
3.2
Background
to
Adaptation
The
widely
varying
characteristics
of
mobile
devices
can
make
it
difficult
for
a
Web
site
to
provide
an
acceptable
user
experience
across
a
significant
range
of
devices.
clients.
For
example
different
devices
clients
support
different
markup
features
features,
and
the
different
screen
sizes
may
demand
different
sized
images.
Consequently,
it
is
very
common
when
delivering
content
to
mobile
devices
clients
to
vary
the
details
of
the
markup,
format
of
images,
image
sizes,
color
depths
and
so
on
to
suit
the
characteristics
of
the
device
client
in
question.
The
process
of
altering
content
in
this
way
to
enhance
the
user
experience
on
particular
devices
is
referred
to
as
Content
Adaptation
content
adaptation
.
We
do
not
describe
The
remainder
of
this
section
briefly
describes
content
adaptation
in
detail
in
order
to
provide
a
background
for
this
document.
For
a
more
detailed
description,
readers
are
referred
to
the
Device
Independence
Principles
[DIP]
.
In
addition,
the
sister
group
of
the
Best
Practices
Working
Group,
group
-
the
Device
Descriptions
Working
Group
,
Group,
is
currently
defining
requirements
for
a
repository
of
mobile
device
client
characteristics
that
are
relevant
to
content
adaptation.
3.3
3.1
Adaptation
Implementation
Model
There
are
is
quite
a
number
wide
spectrum
of
different
implementation
models
for
content
adaptation.
On
the
one
hand,
hand
adaptation
may
be
quite
simple
simple,
and
consist
of
determining
the
device
type
and
choosing
the
most
appropriate
set
of
previously
prepared
content
to
match
the
device
characteristics.
At
the
other
extreme
it
may
be
carried
out
in
a
completely
dynamic
way,
with
content
formatted
at
the
time
of
retrieval,
taking
into
account
not
only
statically
determined
properties,
such
as
screen
dimension,
but
also
dynamically
determined
properties,
such
as
the
temporary
attachment
of
a
fully
featured
keyboard.
Adaptation
can
be
carried
out
in
a
number
of
different
points
in
the
delivery
of
content
to
the
device
client
[DCODI]
:
Server
Side
adaptation
implies
that
the
content
is
delivered
by
the
originating
content
server
or
application.
In-Network
In
Network
adaptation
is
where
the
content
is
altered
as
it
passes
through
one
or
more
network
components.
Some
network
operators,
for
example,
compress
images
before
they
are
passed
over
the
air
to
the
mobile
device.
client.
Client
Side
adaptation
consists
of
the
device
client
accepting
content
and
displaying
it
in
an
appropriate
way
for
its
characteristics.
Whatever
the
adaptation
model
at
work,
appropriately
to
the
process
of
adaptation
should
not
diminish
accessibility.
device's
characteristics.
3.4
3.2
Assumptions
about
Adaptation
In
phase
1
(See
1.4.1
Phasing
)
it
is
assumed
that
content
adaptation,
if
any,
is
carried
out
Server
Side.
Future
phases
may
consider
the
implications
of
content
adaptation
elsewhere,
especially
the
issues
concerning
the
around
granting
of
authority
to
third
parties
to
carry
out
adaptation,
prohibiting
adaptation
and
so
on.
Later
phases
may
also
address
the
issues
around
the
possibility
of
multiple
adaptation
adaptations
-
i.e.
the
possibility
that
adaptation
can
be
applied
at
in
more
than
one
point
place,
and
that
In-Network
In
Network
adaptation
may
occur
more
than
once.
It
is
also
assumed
that
it
is
possible
to
create
a
site
that
is
consistent
with
the
Best
Practice
recommendations
best
practice
recommendations,
without
carrying
out
adaptation
at
all.
However
it
is
likely
that
a
more
sophisticated
and
enhanced
user
experience
will
be
achieved
if
adaptation
is
used.
3.5
Establishing
Context
Providing
variations
on
the
user
experience
that
are
appropriate
in
different
cases
requires
the
content
provider
to
know
a
significant
amount
about
the
characteristics
of
the
device,
the
properties
of
the
browser
in
use
and
the
transparency
of
the
network
connection
to
the
device.
For
simple
sites
that
present
an
interface
which
is
similar
across
a
broad
range
of
contexts
the
need
for
such
information
is
diminished
when
compared
with
a
sophisticated
site
that
has
an
optimized
navigation
structure,
presents
different
size
images
or
carries
out
other
adaptations
to
suit
the
particular
delivery
context.
There
are
several
methods
by
which
a
content
provider
can
discover
information
about
the
delivery
context,
such
as
CC/PP,
UAPROF,
CSS
Media
Queries
and
various
outputs
of
the
Device
Independence
Working
Group
.
The
companion
Techniques
[Techniques]
document
describes
these
methods.
3.6
Choice
of
User
Experience
In
the
interests
of
"One
Web"
(see
3.1
One
Web
)
considerations,
the
content
provider
may
choose
to
allow
the
user
to
select
from
broad
categories
such
as
mobile
or
desktop
presentation,
where
these
are
distinguished
in
the
application.
If
the
presentation
option
has
been
determined
automatically,
the
content
provider
may
choose
to
allow
the
user
order
to
override
determine
the
automatic
determination.
Where
a
choice
of
presentations
is
available,
appropriate
adaptation
it
is
good
practice
necessary
to
record
determine
the
user's
preferences
and
to
allow
them
to
be
changed.
Given
an
appropriate
server
environment,
it
is
unlikely
device
that
is
accessing
the
content
provider
will
be
unable
service.
Sometimes
it
is
not
possible
to
find
out
anything
about
determine
the
delivery
context.
However
this
can
happen,
device
type,
either
because
details
of
the
delivery
context
are
device
does
not
available
present
this
information
to
the
server
at
all,
or
in
sufficient
detail
detail,
or
because
the
server
does
not
provide
the
ability
to
inspect
and
act
on
the
information
provided.
In
this
case
a
"reasonable
default
experience"
should
be
provided.
The
details
of
the
default
experience
depend
upon
a
number
of
factors
including,
but
not
limited
to,
the
geographic
region
in
which
the
service
is
offered
and
the
primary
intention
of
the
service
(e.g.
considering
whether
the
service
is
primarily
desktop
focused
vs.
primarily
mobile
focused).
In
order
to
allow
content
providers
to
share
a
consistent
view
of
a
default
mobile
experience
the
BPWG
has
defined
the
Default
Delivery
Context
(see
3.7
Default
Delivery
Context
).
This
allows
providers
to
create
appropriate
experiences
in
the
absence
of
adaptation
and
provides
a
baseline
experience
where
adaptation
is
used.
The
Default
Delivery
Context
has
been
determined
by
the
BPWG
as
being
the
minimum
delivery
context
specification
necessary
for
a
reasonable
experience
of
these
cases
the
Web.
It
is
recognized
that
devices
that
do
not
meet
this
specification
can
provide
a
reasonable
experience
of
other
non-Web
services.
It
is
also
recognized
that
this
specification
content
provider
is
made
against
the
background
of
demographic,
cultural
and
economic
assumptions.
Content
providers
may
choose
to
provide
services
that
demand
a
different
or
lower
delivery
context
specification,
but
should
try
expected
to
provide
an
experience
that
exploits
the
capabilities
of
assume
the
Default
Delivery
Context
default
delivery
context,
as
discussed
in
order
to
provide
the
best
possible
experience
for
that
context.
Introduction
to
this
document.