RE: Update to BP2 draft

Moving this thread to the public list.

Sean,
Setting the scope and goals is the critical first task I agree. The
draft is consistent with the scope/goals of BP1 as you state them,
except for reliance upon a specific device context (basic, or advanced)
as the frame.

Here is the scope section. It is clearly focused on the mobile device
user experience, and specifically to how web applications (content and
services) are provided (thus not specifically focused on device
capabilities, but the implications of them on the content and services
that are offered).

++++
1.4 Scope
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 [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". 
++++

The ADC was left off the table in the Nov 07 F2F since as I think, the
sense was that:
- it will be difficult to settle on a representative "advanced" device
since so many new/advanced web technologies have been developed and yet
it's still early in terms of their adoption on mobile devices
- better cost/value will result from addressing a focused set of key
issues (based upon BP1 and expanded for new technologies) for web
applications, consistent with the BP1 objectives
(usability/interoperability/efficiency)

The objectives in the current editor's draft are consistent with that
focus/scope, and are specifically intended to be addressed for the
mobile context (the current terse statements will be expanded per the
recommendation outline of BP1).

I will be sending out specific emails to the public list to draw out
discussion on the current "goals" section, e.g. the excerpts below
(posted here for convenience of the public list readers).

++++
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 Personalization
Personalization is an important capability in the mobile environment,
given the extra effort necessary to interact with services, and 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.

2.2 Security  and privacy
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.

2.3 User  awareness and control 
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. 

2.4 Use of cookies and redirection
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 compared to their use for web browser applications, cookies and
redirect may play less of a role in maintaining statefulness and
personalization for for web applications in general.
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.

2.5 Conservative use of network traffic
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.

2.6 "One Web"
- help spread the one web mentality

2.7 Constraints and Capabilities of the Mobile Context 

2.7.1 Presentation Issues
As addressed in BP1, presentation issues of mobile devices can also be
applicable to web applications in general, e.g. 
- variations in page rendering/layout in different devices 
- context/overview constraints due to limited screen size and the
limited amount of visible material 
- dependency upon scrolling through material 
- presentation space expense for images and navigation links 
- overall lack of site/content cohesiveness due to fragmentation of
display and site structure

However, advanced web browser features and evolving web technologies are
adding additional specific issues that need to be addressed in the
mobile context, including: 
- support for popup windows and layers which can overlap partially/fully

- support for popup menus 
- dynamic changes in screen orientation 
- need for content adaptation (e.g. image resizing/cropping) due to
variable presentation space 
- overall usability issues resulting from more complex presentation
options

2.7.2 Interaction Issues
As addressed in BP1, issues of interaction with applications on mobile
devices can also be applicable to web applications in general, e.g.
- limited keypad, e.g. 16-key, leading to difficulty in selecting
\characters, and the need for application help in selecting the input
character type 
- physical keying difficulty due to small key size 
- form field navigation 
- overall difficulty in entering text impacting usability, e.g. for
forms and long URLs 
- no pointing device 
- variations in softkeys for navigation and local application menus

However, evolution of mobile devices is adding additional specific
issues that need to be addressed in the mobile context, including:
- new pointing methods, e.g. touch screens  
- dynamic changes in keyboard layout, e.g. between 16-key, querty, and
soft keyboards 
- solve the top left navigation problem [need a definintion of what this
is, and consideration of whether it is actually testable]   

2.7.3 Delivery Context Variability
As addressed in BP1, the basic aspects of delivery context in the mobile
environment, and how awareness of delivery context relates to the goal
of the "one web", also apply to web applications in general.

BP2 extends/expands the discussion for specific delivery context
aspects, e.g.:
- dynamic delivery context property awareness in general, e.g. methods
of determining current value of properties whether known by the device
or by the network only
- issues for specific dynamic delivery context properties, e.g. network
bandwidth, roaming, location, network services (e.g.  content
transformation

2.8 Applicability to Non-Browser Web Runtime Environment
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

2.9 Toolkit Developer Issues
Audience of BP2 document will include CPs as well as Ajax and other
toolkit developers.
++++

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Sean Owen [mailto:srowen@google.com] 
Sent: Thursday, February 14, 2008 7:40 AM
To: Sullivan, Bryan
Cc: BPWG
Subject: Re: Update to BP2 draft

One problem that plagued the early discussions on BP 1.0 was a lack of
basic agreement on what the goals and non-goals of the BPs were, what
was in and out of scope. What emerged after a lot of work was coherent,
and one can identify the basic principles of the scope and intent of BP
1.0:

- applies to documents/resources, not devices
- does not prescribe new standards or technologies, and promotes / is
consistent with current standards
- speaks to concerns that are mobile-specific (e.g. there are no best
practices on decent error pages since that's true for desktops too)
- BP 1.0 imagines a baseline device, the DDC, as what sites should
target first, and when the device capability is unknown, and makes
recommendations based on that device

Now that we have some BP 2.0 text on the table, I think it's worth
checking whether we're on the same page. My picture of BP 2.0 was that
all of the above principles apply, but that we imagine a more advanced
device, the "ADC", which is something in the ballpark of an iPhone. We
don't *have* to do this, but it was my understanding, and is my
preference, and would likely be less confusing to the public.

With that in mind, reviewing the text written so far, most items seem
general and not yet mobile-specific.

Is my understanding wrong, or are we heading in the direction I'm
thinking? if not, ah, may we talk about that?

Sean

Received on Thursday, 14 February 2008 19:10:48 UTC