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.