RE: BP2 Comments.

Adam,
Thanks for the input. Here are some responses to your comments. The
changes will appear in the 0409 editor draft.
 
Re "5.1.2 Retain manually entered information.": 24 hours is not quite
arbitrary, but I updated the BP to make the duration recommendation more
general. The 24 hours came from significant experience with the ways
users with mobile web services. User "sessions" with a service need to
be reasonably immune from the repeated necessity to re-enter
personalizing information. Holding this info for a day (*at least*)
ensures that within one typical "session" they won't have to reenter it.
A week may be better (but longer times begin to be problematic due to
resource impacts/constraints on both server and device), but it depends
upon the nature of user interaction with the service (the typical
"session profile"), so recommending a reasonable/typical minimum was the
intent of the BP. 
 
Re "5.1.3 Suggest changing "simplify" -> "minimize"": Simplicty captures
the essence better, unless you mean "minimize user effort" rather than
"minimize the use of". "Minimize" has typically been used to mean the
latter in the BP's e.g. BP1. I don't think we want to recommend
impersonal services, rather provide useful guidelines on keeping
personalization simple for users. I updated the BP to clarify we mean
"minimize the effort required to manually personalize the service."
 
Re "5.3.2 Inform user about device memory impact": In terms of
"installation", we are talking in part about web applications here that
can run outside the browser sandbox (e.g. using a web runtime). These do
have impact upon device memory for installation. Re data memory, web
applications that manage persistent data can consume considerable device
memory, depending upon their nature. It's important that this BP guide
developers toward this disclosure, unless BPWG wants to focus only on
the browser, which would be a considerable retreat in my opinion on the
value of BP2 (we could then call it "BP1.5"), and not serving the
developer community with guidance for the real scope of mobile web
applications. I clarified the BP as related to "Users should be informed
of impacts to device memory for installable web applications."
 
Re "5.3.4 Provide disclosures that are timely.": similar to the previous
one, this is needed based upon the current scope of BP2 "The BP2 focus
includes further recommendations for addressing delivery context issues
and for use of Web technologies more advanced than covered in BP1, which
apply both to browsers and non-browser web runtime environments."
 
Re "5.5.1 Use transfer compression for content.": BP2 is not just about
AJAX, so if AJAX (XMLHTTPRequest) doesn't support compression that is
regrettable (any IMO does not bode well for Mobile AJAX until is is
corrected...), but there are many other web technologies that do since
they only depend upon normal HTTP client/server functions, which
typically do include GZIP/deflate as a HTTP stack service. Further, we
have added a reminder to "Note that transfer compression may not be
supported for all network request techniques", which is intended to
address the AJAX limitations (once they are confirmed, if real).
 
Re "- "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.": There are some aspects that are not so simple, yet are
important for developers to consider. For some of these it will not be
possible to create a simple "do this" statement, but are we then just to
ignore them? Developers need to know when they need to make the call on
whether to act upon a BP or not, based upon the nature of their
application.
 
Re "* Battery use of AJAX crops up a number of times...I feel that these
are dangerous statements without substantiation ": there is only one
case related (somewhat) to AJAX, and this relates to scripting in
general and DOM manipulation in particular. Again, BP2 is about much
more than AJAX. Many of the warnings against battery impacts are related
to basic autonomous behavior or advanced web technology use (e.g. DOM).
At least in terms of autonomous network requests but also in terms of
autonomous screen updates, there is clear evidence that such automatic
functions can impact the battery "idle time" (the typical measure of how
often a user has to charge the battery, not counting talk time). Most
Operators have enough experience to tell you that these are real
concerns, and are driving the recommendations on *careful* use (*not*
avoidance) of automatic behaviors and advanced technologies.
 
Re "5.5.2 ": I changed the first sentence to "Applications that
automatically issue network requests should provide value for those
requests." This may seem obvious, but it is likely that some/many
developers, having the luxury of wired web bearers as their connection
to the client, will not consider carefully enough the cost/benefit of
such traffic in the mobile context. Having a direct statement such as
this will either be obvious to those who understand it, or will cause
the others to wonder why and thus learn about the need to consider
cost/benefit and the methods to optimize it.
 
Re "5.5.3": Push technologies are not out of scope as they are a
currently widely supported and deployed method for optimizing
client/server interaction for notification-significant services. Web
applications can run as midlets, even full web browsers, and MIDP Push
is a key method supported for them. The point is not the execution
environment (why consider only "native OS" applications in scope? If
applications are based upon web technologies in at least some major
aspects as the data they consume and the way they interact with servers,
is it irrelevant what their runtime environment is). OMA Push in
particular is a mobile web technology that underlies or enhances many of
the widely successful service enablers that OMA has specified, including
mobile browsing.
 
Re "5.5.4 Minimize application size.": text improvements are welcome.
 
Re "5.5.5 Minimize DOM manipulation.": text improvements are welcome.
This was provided as input.
 
Re "5.5.6 Minimize external script files.": input on a better wording
for the note is welcome ("Note that caching can also diminish the
overhead for transfer of external script files, however as script files
are collected into single packages, the efficiency of caching may
diminish. So you should seek an optimum balance between script
aggregation and cache efficiency.")
 
Re "5.7.2 Retain focus on updates.": I did not submit this but I
understand the sentiment, and I do think it occurs in dynamically
updating applications. Certainly desktop web applications steal focus
all the time and this drives me crazy. I can imagine how this would
affect mobile web use.
 
Best regards,
Bryan Sullivan | AT&T
________________________________

From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Adam Connors
Sent: Tuesday, April 01, 2008 6:03 AM
To: MWI BPWG Public
Subject: BP2 Comments.


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.