日本語ホームページ
Japanese
website
简体中文首页
Chinese
website
Types
of
documents
W3C
publishes
Copyright
2008
Translations
of
W3C
standards
and
drafts
Reviews
and
public
feedback
(
MIT
Liaisons
,
ERCIM
Promote
web
standards
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
A
variety
This
document
specifies
Best
Practices
for
delivering
Web
content
to
mobile
devices.
The
principal
objective
is
to
enable
development
and
delivery
of
groups
develop
great
Web
Standards,
guidelines,
or
supporting
materials.
applications
on
mobile
devices,
through
recommendations
for
exploitation
of
mobile
device
capabilities
and
delivery
context.
The recommendations refer to applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.
The recommendation is primarily directed at creators, maintainers and operators of Web applications. 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 servers, HTTP, and Web 2.0 technologies. Readers are not expected to have a background in mobile-specific technologies.
Interest
Groups
(to
be
filled
in
later)
Business
Groups
(to
be
filled
in
later)
Invited
Experts
(to
be
filled
in
later)
Positive
work
environment
(to
be
filled
in
later)
W3C
works
at
the
nexus
This
document
sets
out
a
series
of
core
technology,
industry
needs,
recommendations
designed
to
enable
development
and
societal
needs.
delivery
of
great
Web
applications
on
mobile
devices.
The
recommendations
are
offered
to
get
involved
creators,
maintainers
and
operators
of
Web
applications.
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 address.
Delivery Context. Discusses the environment within which mobile access to Web applications 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. A brief conformance statement.
Appendices
Sources
Related Reading
Acknowledgements
References
Master
Readers
of
this
document
are
expected
to
be
familiar
with
the
creation
of
Web
fundamentals,
use
applications,
and
to
have
a
general
familiarity
with
the
technologies
involved,
such
as
Web
servers,
HTTP,
and
Web
2.0.
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
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
developer
tools,
statements
may
appear
to
be
obvious
or
contribute
code.
trivial
to
those
with
experience
in
this
area.
The document is not targeted solely at developers; others, such as interaction and graphic designers, and tool developers, are encouraged to read it.
These recommendations (BP2) follow in the footsteps of the Mobile Web Best Practices 1.0, (BP1), for which the scope was laid out in "Scope of Mobile Web Best Practices" [Scope] . In summary, BP1 refered primarily to the extension of Web browsing onto mobile devices.
BP2 extends the focus to Web applications generally, which means an application that is accessed and presented via Web technologies. Web applications represent a spectrum of services and content, at the simple end of which are typical Web browsing sites, presented in browsers, which were the focus of BP1. The BP2 focus includes further recommendations for addressing delivery context issues and for use of advanced Web technologies, which apply both to browsers and non-browser web runtime environments.
The recommendations refer to applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.
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,
many
Web
Content
Accessibility
fundamentals
[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"
and
"Color".
As
discussed
in
the
Scope
document
[Scope]
there
are
many
aspects
to
Mobile
Web
Best
Practices.
BP2
represents
the
second
phase
of
W3C
standards
the
Best
Practices
development,
i.e.
beyond
"Traditional
Web
Browsing".
The
BP2
is
not
intended
as
a
landscape
document,
e.g. a
general
survey
of
technologies
and
drafts
related
issues
in
the
mobile
context.
Recommendations
are
included
here
if
they
meet
specific
criteria:
These
recommendations
follow
in
the
footsteps
of
the
BP1,
and
media
as
such
are
in
part
derived
from
the
Web
Content
Accessibility
Guidelines
[WCAG]
Events
.
The
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 discusses device and delivery channel characteristics, which the DIWG has named "Delivery Context" [DCODI] . In addition, the document uses some terminology from DIWG's Glossary of Terms for Device Independence [DIGLOSS] .
The
Best
Practices
have
been
written
at
a
level
of
conduct
generality
that
allows
them
to
be
applicable
across
a
range
of
Web
technologies. They
have
been
written
with
mobile
user
experience
aspects
in
mind,
which
over
time
will
change,
but
should remain
relevant
as
technology
evolves.
This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.
Understand
our
values
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.
Personalization
is
an
important
capability
in
the
mobile
environment,
given
the
extra
effort
necessary
to
interact
with
services,
and
principles,
learn
our
history,
look
into
our
policies,
meet
our
people.
the
limited
output
capabilities
of
mobile
devices.
Personalization
increases
the
value
of
content
and
services
to
users.
However,
conventional
methods
to
achieve/maintain
personalization
(e.g.
user
input,
HTTP
redirect,
cookies)
are
problematic
given
mobile
context
limitations.
The
overall
goal
for
personalization
in
the
mobile
context
is
to
use
user-friendly
methods.
Security is important to address in the mobile environment, due to more frequent dependence upon personalized information. While this information is essential to increasing service value, its use represents a security and/or privacy risk. The overall goal for security is to protect any personally identifiable information, and especially user identifiers or keys to user identity.
Applications should ensure the user is aware of sensitive functions, i.e. that may affect the service experience, and is offered some options for user control.
HTTP cookies and redirection fulfill useful purposes in the mobile context. Cookies support statefulness and personalization in browsers, two considerations which can simplify the user experience and add value to content and services. Redirect supports server-server interaction via the browser, which is often essential for distributed services which rely upon partitioning of service functions across different servers.
As related to web applications in general, cookies and redirect may play less of a role in maintaining statefulness and personalization. Application-specific methods may be used, and may include use of more advanced technologies that are not available to some browsers. However, support for statefulness and personalization will still need to consider similar issues, e.g. state preservation/recovery and traffic overhead. As well, distributed services may still rely upon redirect for web applications.
The overall goal is to set reasonable expectations on the impact for use of cookies and redirect in service delivery to browsers and web applications, and to address alternatives for maintaining statefulness and personalization.
Web applications that autonomously interact with network-based services can have a very significant impact on service cost. These costs can be borne by the user and/or network service provider. Users with "bucket" or per-KB service plans can find themselves responsible for huge charges. Network service providers can bear these costs for users that subscribe to unlimited service plans, and as a result may restrict the types of applications available to users with such plans.
The overall goal is that users are informed of the potential impact of application operation, and that regardless of the user's service plan, applications use network resources conservatively.
- help spread the one web mentality
-
setting
up
a
device-optimized
viewport
-
e.g.,
size
pop-ups/layers
to
fit
on
screen
-
use
of
pop
up
menus,
conservative
use
of
XMLHttpRequest,
adapating
to
screen
orientation
events
-
techniques
to
detect
screen
orientation
-
usability
features
-
in
the
absence
of
multiple
overlapping
windows
-
image
cropping
and
resizing
-
what
to
expect
devices
to
be
capable
of
in
the
mobile
web
context
-
variability
of
certain
features,
support
differences
that
make
a
difference
to
content
and
legal
information
application
authors,
point
out
what
the
typical
variations
might
be
and
what
could
be
done
to
exploit
these
-
less
advanced
delivery
contexts
-
e.g.,
slower
networks,
less
advanced
devices
-
data
roaming
-
context
awareness,
including
device-dependent
aspects
e.g.
location,
roaming
context
- solve the top left navigation problem
The focus of the BP2 document is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), esp Mobile Widgets
Please
log
Audience
of
BP2
document
will
include
CPs
as
well
as
Ajax
and
other
toolkit
developers.
Document will include a descriptive passage about mobile context (including device, browser, network) we are talking about.
The functional area that is addressed by the statements.
One
or
more
Best
Practice
statements,
identified
in
using
your
W3C
Account.
If
you
have
registered
one
the
following
way:
[EXAMPLE] This is a Best Practice statement.
An explanation of the significance of the statements under this heading.
A discussion of techniques and some suggestions as to how to implement.
The aspects of the delivered content that an external validator could examine to assess conformance with the Best Practice statements. This section is not present for process related statements.
In
this
section
it
is
noted
whether
the
statement
is
Machine
Testable
(Automated
testing
is
possible)
or
several
second
factors,
you'll
Human
Testable
(Testing
requires
human
assessment).
Some
Best
Practices
are
partially
machine
testable,
i.e.
based
on
the
result
of
an
automated
test,
some
human
interaction
may
be
prompted
for
them
as
required.
In
such
cases
both
a
second
step.
Machine
Testable
and
a
Human
Testable
statement
are
present.
Don't
have
an
account?
Create
one
.
Some
Best
Practice
statements
use
words
such
as
"minimize"
and
"avoid"
which
are
intentionally
non-prescriptive.
This
is
in
order
to
provide
guidance
while
leaving
room
to
accommodate
a
wide
variety
of
applications
whose
requirements
cannot
be
anticipated.
It
also
allows
creativity
and
diversity
within
the
same
Best
Practice
framework.
Where appropriate, references to related WCAG points and other immediate references from the preceding text.
Personalized services should be capable of basing personalization upon information obtained directly from the user-agent or network entities, e.g. through HTTP headers or message body.
Personalized services that rely upon manual entry of information should preserve that information to avoid the need to re-enter it upon each site access, over a 24-hour period at least.
If the user must be asked to enter account information, personalized services should simplify what they have to enter, e.g. for email addresses, assume the domain (if possible) or offer well-known options as radio buttons.
Personally identifiable information (e.g. user identity or information usable as a key to user identity) should be accepted or sent securely, i.e. over secure transport (HTTPS), or securely hashed if sent over non-secure transport.
Users should be informed if applications will make automatic data requests that can impact service cost.
Users should be informed of impacts to device memory (for application code and data) due to installation and use of applications.
Users should be informed about the types of personal information (data or contextual information, e.g. location) that will be used by the application, and exchanged over network connections.
Informational notices should be provided during application selection, install, on first runtime, or first use of sensitive functions.
Informational notices should provide an estimate of the impact so the user can determine its significance.
Users should be given easy-to-use controls to personalize application behavior, e.g.
If user control over sensitive application functions is not provided, users should be given the chance to opt-out for the function, or to terminate the application.
User control preferences should be saved by the application to avoid the need to reenter them each time the application is used.
If personalized services use cookies, they should be capable of recovering the cookie-based information without requiring user information reentry, e.g. if the user-agent cookie cache is cleared.
If achieving personalization via redirect-based APIs, personalized services should use redirect in an efficient manner to reduce latency and data overhead, and require no more than two redirects to obtain the necessary information.
Web applications that autonomously interact with network-based services should be designed to minimize the overhead of network traffic for such automatic functions. Such web applications are refered to here as "autonomously interacting web applications".
Autonomously interacting web applications should support content compression, e.g. HTTP 1.1 gzip/deflate compression, for both upload and download operations.
Autonomously interacting web applications should support user control over the intensity of the network interaction.
Autonomously interacting web applications should be intelligent enough to "back off" autonomous operation during periods in which little or no service value results from the network interaction.
Autonomously interacting web applications that provide network event-triggered content delivery should support push methods, e.g. OMA Push, to avoid the need for rapid polling for new events.