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

RE: BP2 Comments.

From: Sullivan, Bryan <BS3131@att.com>
Date: Wed, 9 Apr 2008 15:48:23 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD09B3F08D@BD01MSXMB015.US.Cingular.Net>
To: "Yeliz Yesilada" <yesilady@cs.man.ac.uk>, "Adam Connors" <adamconnors@google.com>
Cc: "MWI BPWG Public" <public-bpwg@w3.org>

Yeliz,
Thanks for the comments. Some responses are provided here. The changes
will be in the 0409 editor's draft.

Re "Abstract": This will be clarified as "web applications".

Re "great Web applications", I welcome text explaining what we mean.
This phrase came from Dan.

Re "Section 2.4": I will add a clarifying paragraph "In BP1, HTTP
cookies and redirection were recommended to "not be relied upon" due to
constraints of limited-capability mobile browsers and slower mobile
networks. BP2 however recognizes that cookies are widely supported by
current mobile browsers, and mobile network speeds have considerably
increased since BP1. Thus while the BP1 recommendations are still useful
to consider when the delivery context can't be determined, BP2 focuses
on use of HTTP cookies and redirection for capable browsers and mobile
networks."

Re "Section 2.12": while the focus is on the browser sandbox as the most
typical execution environment for web applications, we need to recognize
that this is quickly becoming a historical assumption. This is why we
are clear to the applicability of the BPs to applications executing out
of the native browser sandbox, if they meet the criteria in the scope.
Limiting this explicitly to the "browser sandbox" would be akin to
sticking our heads in that sand.

Re "Section 5.1.3": I provided a link in the "how to do it" section.

Re "Section 5.3.2": I clarified that the timing of the disclosure is
addressed in 5.3.4.

Re "Section 5.3.4.1": I clarified that "useful" means "result in user
awareness of the implications of using an application".

Re "Section 5.5.4": text suggestions are welcome.

Re "Section 5.7.1": text suggestions are welcome.

Re "Section 5.7.2": this is just one technology (not exclusive of
others) that has received attention so far re this particular BP. Input
is welcome on others.

Re "Section 5.9.4": Changed as suggested.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Yeliz Yesilada
Sent: Wednesday, April 02, 2008 8:17 AM
To: Adam Connors
Cc: MWI BPWG Public
Subject: Re: BP2 Comments.



I also have some comments and some of my comments overlap with Adam's
comments. I hope you will find them useful.

Abstract
In abstract, it says "The recommendations refer to applications as
experienced on mobile devices." I think this is a bit confusing. Even
though "Mobile Web applications" are described in section 1.4, this
sentence gives the impression that BP 2 covers all kinds of applications
on mobile devices.

Section 1.1
What does "great Web applications" mean?

Section 2.4
This section talks about how Cookies and redirection can be useful for
personalisation, etc. but in MWBP 1.0 there are specific BPs that say do
not reply on these. I think it would be good to clarify these and not to
give the impression that these two versions contradict.

Section 2.12
This section highlights that the focus of this version is on producing
BPs that apply to *browser* sandbox. If that's the case, why not add
that to the definition of "Web application" in section 1.4.

Section 5.1.3
I think "how to do it" part can be better linked to BPs in MWBP 1.0.

Section 5.3.2
I think "how to do it" part does not really explain how to do it. Are
the information listed there will be displayed before the application is
loaded or while the application is loaded or in a pop-up box, it is not
clear. It is clear what kind of information is good to show but not how.

Section 5.3.4.1
What does "useful" mean here?

Section 5.5.4
Application size can be minimised in different ways, I think "how to do
it" section can be extended with some other techniques such as
techniques on scripting (from 5.5.6.2), etc. or as Adam suggested scope
needs to be constraint.

Section 5.7.1
In MWBP 1.0, there is a BP that says "do not rely on scripts" but this
BP says use scripting for user interfaces. I think this needs to be
clarified.

Section 5.7.2
I think there is too much focus on a specific technology here.

Section 5.9.4
Would it be better to generalise this as "advanced scripting" and then
give Javascript as an example?

Regards,
Yeliz.

On 1 Apr 2008, at 14:02, Adam Connors wrote:
> Hello,
>
> I have some comments on the BP2 doc. I hope this is useful.  
> Apologies for not looking at this previously, the usual tale of hard 
> deadlines and travelling... :)
>
> Adam.
>
> Comments on BP2 doc:
>
> 5.1.2 Retain manually entered information.
> - I like the sentiment.
> - "24-hr period at least" sounds a bit arbitrary.
>
> 5.1.3 Suggest changing "simplify" -> "minimize" to make recommendation

> a little more concrete. I like the "require only variable information 
> comment."
>
> 5.3.2 Inform user about device memory impact.
> - I agree with earlier comments that this is out of scope. HTML5 is 
> about the closest technology to this but I can't imagine a case where 
> it makes sense for a web-page to inform memory impact.
>
> - The language is very application specific. You don't "install"  
> web-applications. Even if using HTML5 storage there isn't an explicit 
> "install" stage so these statements are anachronistic.
>
> - I disagree that this is good practice for web-applications. The 
> user-experience would be poor. I need to see a concrete example of the

> intention here for this to be convincing.
>
> - Suggest dropping this BP.
>
>
> 5.3.4 Provide disclosures that are timely.
>
> - Language is too application specific. If in most cases we are 
> talking about "web-applications" references to "application selection,

> install, first runtime" sound strange and anachronistic.  If we are 
> referring to specific non-browser technologies I think we need to call

> this out explicitly since anybody reading this document on the 
> assumption we are referring mostly to browser-based applications won't

> know what to make of a recommendation worded in these terms.
>
> - Suggest dropping.
>
>
> 5.5.1 Use tranfer compression for content.
>
> - The summary beneath 5.5 "web applications that autonomously 
> interact..." implies we are talking about transfer compression for 
> AJAX requests. Sure, compression in general is a good thing, but I'd 
> hesitate to make a BP around compressing AJAX unless we have a good 
> view on how this is done... Can someone provide confirmation that this

> either "just works" or how it is done? I'm not convinced this works 
> out the box and if we have to do something like implement gzip in 
> javascript by hand to do it then I don't think it makes sense as a 
> recommendation.
>
> - "Balance use of compression with potential cost"
> Statements like this don't add any value in my opinion. The purpose of

> a BP document surely is to weigh up / investigate such issues and 
> attempt to come to a conclusion.
>
> * Battery use of AJAX crops up a number of times I feel that these are

> dangerous statements without substantiation.
> Sure, "be aware of battery use of ajax and don't use it unnecessarily"

> is perfectly reasonable, but the way these statements are worded is 
> much stronger. Do we have a reference or experiment or example to help

> us understand the true significance of this consideration.
>
>
> 5.5.2 "Applications should not create network traffic..." -- cut this 
> sentence it adds nothing. Start with "For application that 
> automatically issue network request... etc"
>
>
> 5.5.3 Refers to MIDP Push Registry which is specifically out of  
> scope. Isn't OMA push also out of scope for "web applications". I  
> don't know of any push techniques that do work for web- 
> applications. A hanging-get is the nearest thing, but has problems  
> of its own.
>
>
> 5.5.4 Minimize application size.
>
> - "overuse of nested css classes" --> I think I contributed this  
> one. The language I used is confusing now I re-read it... I will  
> offer a better wording.
>
> - "the cost of css optimization needs to be balanced against  
> impacts of maintainability" -- I don't agree that well-written /  
> optimized css needs to be any less maintainable so I don't see much  
> value in this point. Maybe I need more explaination of what is  
> meant by "optimize css at the point of delivery", I'm not sure what  
> this means.
>
> - There are a great many other ways to minimize application size  
> beyond this. The heading is far broader than the content for this  
> section.
>
>
> 5.5.5 Minimize DOM manipulation.
>
> - The points in the "how to do it" section contradict the premise  
> of the recommendation (!) We need to rework this one.
>
> - What's the reference for this statement? There are a number of  
> advantages to building the page on the client based on a JSON data- 
> model -- it's a technique we use a lot -- so I am concerned that a  
> strong recommendation like this should have a solid evidence-based  
> motivation.
>
> - To my mind identifying a BP for how to build and manipulate  
> dynamic pages based on a javascript data-model is the place where  
> we can offer most value here. But this recommendation as it  
> currently stands is quite misleading and contradictory to BPs we  
> use in day-to-day development...
>
> - We need to understand this much more deeply.
>
> - I am happy to take an action to try to put something together on  
> this, but please send me the reference that prompted the "battery- 
> life" concern because I don't have a good understanding of the  
> significance of this factor at the moment.
>
>
> 5.5.6 Minimize external script files.
>
> - I like the sentiment. I don't understand "however if script files  
> are collected into single packages the efficiency of caching may  
> diminish." I understand this to mean that we believe there is  
> advantage to partitioning scripts so that new releases of the  
> application don't require reloads of all the script... In practice  
> I think this would be highly unlikely to have a dominant effect. I  
> suggest that we drop this last statement unless I am  
> misunderstanding it.
>
>
> 5.7.1 Use scripting for user interface
>
> - This is a place-holder? What else would you use? Maybe we should  
> flesh this out to explain that user-experience can be greatly  
> improved by using script to update dynamic parts of the page and so  
> avoid full-page reloads.
>
>
> 5.7.2 Retain focus on updates.
>
> - Feels to me that we are specifically recommending against a  
> particularly pathological behaviour... This isn't the sort of thing  
> that anyone in their right mind would do so I don't think we need  
> to specifically ward against it.
>
> - Suggest dropping this recommendation, but don't feel strongly.
>
>
Received on Wednesday, 9 April 2008 22:49:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:58 UTC