RE: Update to BP2 draft - some feedback

Kai,
Thanks for the comments.

I must admit I still don't know what the phrase "top left navigation
problem" even refers to. So I seriously need the help of those (like
you) that do.

On efficiency and user awareness, I would not focus so much on
efficiency except in terms of general, useful guidelines. Data volume as
you state is of concern to the user only in per-KB/bucket service plans
or low-speed networks, although those are real concerns and do affect a
large population. But not all service providers believe that flat-rate
service is in the best interest of consumers in the end. As flat rate
service does impact the service provider, someone still has to pay. So
network use efficiency is an important consideration, regardless of the
service context.

But apart from the general guidelines on efficiency, I would focus on
the simple expectations that the user can be at least be made aware of
the potential implications of application use (data traffic being just
one), and be given some simple means to control it.

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Scheppe, Kai-Dietrich
Sent: Friday, February 15, 2008 12:20 AM
To: BPWG-Public
Subject: RE: Update to BP2 draft - some feedback


Hi Bryan,

I would like to take up a couple of points in the draft..

First
- solve the top left navigation problem [need a definintion of what this
is, and consideration of whether it is actually testable] 

I very much agree.  But I don't know how to evoke change.
This is probably one of the most entrenched patterns on the web.

Deutsche Telekom P&I (Products and Innovation, formerly known as
T-Online) has just undergone a major redesign of its portals.
Among other changes we switched from top left vertical navigation to top
horizontal navigation.
This was a /*major*/ undertaking, not on the side of implementation but
on the side of reaching agreement.
It was incredible to see how difficult it was for people to let go of
paradigms.

I see no feasible way to tell the general public:  "Please do not use
top left navigation".

Granted, using content adaptation you can do a lot, but I would guess
that the number of authors and providers with access to good content
adaptation is rather limited.

The influence of those provides is of course not exactly small, but in
order to make this work I feel a grass-roots movement is needed and
pages need to be designed from the get-go with different navigation.
While the Navbar makes sense in purely mobile environments, I don't see
this taking off on regular portals that "could be" mobile friendly, yet
I also don't see an alternative.

I would be curious to see what others think on this subject.




Second
- 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.

I agree, in principle.  As a matter of fact in the paragraph preceeding
this one you nicely outline the potential hazards involving data volume
and web applications.

However, my feeling is, that we ought to be careful not to worry too
much about data volume with BP2.
BP2 is about web applications / rich internet applications whose main
focus is usability, comfort, style and effectiveness.
I see a completely different focus with respect to the user's intentions
and the author's ability to provide.

I would caution against sacrificing usability, in an age of increasing
bandwidth, flat rate tarifs and highly increased user expectations, for
saving of data volume.
If someone choose to create bad applications that will take ages to
load, I suggest the market will take of that very quickly.
We do not have to "legislate" that in a standard.



-- Kai


 

> -----Original Message-----
> From: public-bpwg-request@w3.org
> [mailto:public-bpwg-request@w3.org] On Behalf Of Sullivan, Bryan
> Sent: Thursday, February 14, 2008 8:10 PM
> To: BPWG-Public
> Subject: 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

Received on Friday, 15 February 2008 08:48:23 UTC