W3C home > Mailing lists > Public > public-bpwg@w3.org > February 2008

RE: Update to BP2 draft - some feedback

From: Scheppe, Kai-Dietrich <k.scheppe@telekom.de>
Date: Fri, 15 Feb 2008 09:19:59 +0100
Message-ID: <398533C370C23441981074C456AA3BDD031DAF0B@QEO00226.de.t-online.corp>
To: "BPWG-Public" <public-bpwg@w3.org>

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:20:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:55 UTC