RE: BP2 Comments.

Jo,
Thanks for the input. I'm feeling a bit like a deer in the headlights
now, with the rush over on the other TF's and the full glare pointed at
BP2.

I've added some notes on the changes in the 4/23 version as [bryan]
comments.

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: Wednesday, April 16, 2008 8:41 AM
To: Sullivan, Bryan
Cc: MWI BPWG Public
Subject: RE: BP2 Comments.


I'm sorry if some of my comments below re-hash what ahs already been
said and I am sorry that it's taken me a while to get to this in detail.

The comments are based on the Editor's draft of 27 March and I note that
a lot of your earlier responses are "text welcome". I haven't made many
proposals in this but would be happy to join a focus session were such
statements were crafted.

1. Abstract

I think that it could be made even clearer that the purpose of this
document is to amplify on some general statements in BP1 - in particular
its job is to expand upon "Exploit device capabilities" - which is
indeed detailed in the second sentence of the abstract, but I think this
could be made even clearer.

[bryan] Edited much as suggested.

2. Also to make reference to the fact that time has moved on since BP1
and some things can now be recommended as Best Practice which did not
qualify as Best Practice then.

[bryan] Edited much as suggested.

3. I think we need to think about what is actually accepted as Best
Practice and what we think is desirable. This is in fact spelled out in
1.4.1 but I think we need to give this more thought. I have a feeling
that BP1 strayed too far in the direction of "Desirable" rather than
"Best Practice", but then if it hadn't done, it wouldn't have said much.
So perhaps we need to think about the dividing line a little more
carefully.

[bryan] I agree. A process of assessment against the criteria (if
different from what's given) would be useful.

4. I have a fair number of non-substantive comments on the use of
language and terminology that would probably better be taken off line. 

Now would be the time to think about the structure of the BP statements.
Section 4 says there is a "What to test" section, which in general there
isn't and which in general has been found to be rather flawed in BP1. I
think we should drop the idea.

[bryan] OK, but I recommend there be a resolution on that first. I
originally started out wanting only *really-testable* (even really
*machine-testable*) recommendations to be included, but it would have
been a short document.

5. Like Yeliz I don't know that I would recognise a "great Web
application". In BP1 we used terminology from DI Glossary and said we
were trying to help people provide a "functional user experience".
Perhaps now is the time for us to say we are trying to help provide a
"harmonized user experience" (q.v.).

[bryan] I added the statement ""Great web applications" means that users
find true value in use of the applications, and simply enjoy using them
even given the constrained mobile context."

6. Like others I think that the specific mobile problems need to be
spelled out more clearly in 2.2 Security and Privacy. 2.3 could do with
some expansion and I don't think 2.4 is very clear in what it is trying
to say.

[bryan] I updated the sections, hopefully it is clearer now.

7. 2.5 Conservative use of network traffic - I think this might better
be recast as conservative use of resources e.g. battery, cpu, memory
etc. as well as network. I'm not sure why this is separate to 2.11 or
what the text under 2.11 is trying to say on this topic.

[bryan] I have consolidated them under 2.5 and 5.5.

8. 2.12 Non Browser Web Runtime environment

I know we have already spent a lot of time on this, but still think that
this requires clarification

[bryan] Tweaked it further.

9. 2.13 Toolkit requirements

I'm not clear what specific requirement this is identifying. Plus it's
unlucky to have 13 requirements ... think we should drop this

[bryan] plunk

10. 5.1 Personalization

Like others I am not clear what the specifically mobile slant on this
is. The reference to "network operators" gives a slightly opco centric
feel to this, in my view. I don't feel happy with recommending use of
opco programs which may not exist, or which if they do exist are all
different to each other. It's fine to mention the existence of such
programs but note should be made of the differences and non-universal
availability. The recommendations should, in general, apply equally to
access over operator provided networks and wifi for instance.

[bryan] I made the recommendation less specific to network operators and
applicable to "service providers" (a more generic term which can mean
either network service provider or a web portal/community provider... it
really wasn't meant to be operator-specific anyway, since some growing
initiatives are not operator-based). 

11. 5.1.2 and 5.1.3

I don't see the real difference between these and I'm not sure of the
difference to MINIMIZE_KEYSTROKES. [A pet hate is also the use of the
word "manual"]

[bryan] I agree on the keystrokes overlap at least for the simplify
manual entry part. I thought there probably were some additional
techniques we could mention above BP1 but for now removed it. The
retention though is more than what BP1 called for, since it specifically
addresses not making the user have to enter the information too often,
rather than just how simple it is to enter it when needed.

12. 5.2 Security and Privacy

I don't think I am clear as to what the specifically mobile take on this
is, and like others feel uncomfortable about suggesting that insecure
transmission is acceptable. Also we would need a number of supporting
examples to show that this is Best Practice.

[bryan] I added more details and hopefully that will make it clearer. I
would think that personal information privacy would be inherently
understandable as a best practice. The biggest gotcha of the mobile
context is the need to limit use of HTTPS, due to related CPU/processing
and latency issues, or due to simple interoperability issues of root
certificates and supported cipher suites etc. Rather than just punt and
use non-secure HTTP in all cases (which we have seen content providers
do, even when apparently private/sensitive information is being
exchanged), using it judiciously is a better approach. If content
providers understand that personal information is not personal unless it
can be associated with a person (anything that does not fit this should
definitely be encrypted), then they will realize that the important
secure phase is the acquisition of the personalizing information.
Alternate approaches to use of HTTPS, e.g. securely hashed information
included as URL parameters, POST data, or cookies, are very useful to
minimize the overhead yet retain security. But nonetheless, many sites
still simply pass personal information as clear-text parameters in URLs.

13. 5.3.1 User Awareness

I like this very much and it definitely has the right feel to it. How
can we turn this more into something that is actually a statement of
Good Practice rather than being desirable?

[bryan] There are some specific examples provided... More would be
helpful. But I don't know exactly what you would expect the BP to say
beyond this, unless you want to get to the level of specifying what the
prompt should be.

14. 5.3.2 emory Impact

Others have commented on this.  

[bryan] I reduced the scope just to addressing impact on persistent
storage. This is a supported function of web applications today (though
perhaps not browsers) so I think it's reasonable to keep in scope.

15. 5.3.3 and 5.3.4 Inform the User/ Provide Disclosures Per 13. and
also not sure about the specifically mobile aspects.

[bryan] The section addresses the overall expectations of the user being
informed about sensitive application functions, that themselves are
addressed in other sections. The point is that if the user is to be
informed, what are the expectations to ensure that the notices and
controls are effective? I'm not sure this is addressed in any normative
way anywhere else (can you point me to a recommendation?). The MWI
should take the lead on this, especially since these issues are more
pressing in the mobile context.

16. 5.3.5 Provide Useful Control

I think this needs to be tightened up a bit more to make sure that it is
specifically mobile in nature and to clarify for example what "Useful"
means.

[bryan] Rather than define useful, I just renamed the section. Hopefully
it will still be as implicit as I assumed it was before. The specific
recommendations address the controls for issues addressed in other
sections, so are internally consistent with the document. Since they are
of enough importance in the mobile context to be have related best
practice statements (in the other sections), it makes sense if there is
a best practice on controls, they should be included as well there. I
did expand the section based upon other comments, but I'm not sure how
much tighter it can be made. It seems pretty cut and dried to me.

17.5.4.1 Cookie Based information

I'm unclear what this is recommending. On the one hand it is
recommending use of cookies and on the other it's recommending that lost
cookies can automatically be recovered. I don't think this is
specifically mobile, is it?

[bryan] The section is addressing the need to be prepared to
automatically recover cookie information if possible. There are a number
of server-side ways to implement this that should be apparent to
application designers. But saying that there is a way to recover
information, is not the same as saying you want to use that method to
get the information for every request. Ask any highly scalable web
application designer about the role of a session/database management
server and an application server. It will be clear that there is value
in getting information from the session/database server when needed, but
retaining/using it at the application server through more efficient
means when possible. While these techniques are not limited to the
mobile context (how much of any of this really is?), the importance of
cookie use for personalization/automation and general ease-of-use is
more significant in the mobile context (unless you use other methods to
provide the same retention/recovery, but that's then just a design
decision and does not invalidate our addressing use of cookies for this
purpose), so recommendations about automatic recovery are relevant here.

18. 5.4.2 Redirects

I am unhappy about this. Actually, there's no need to redirect at all,
given a sophisticated enough server side/proxying implementation.  On
the other hand what is this saying that is mobile specific? The mobile
specific aspect is that redirects are unduly costly and should be
minimized.

[bryan] The actual fact of most large-scope/scale service environments
is that they probably involve distributed servers of probably multiple
service providers with different roles (e.g. identity management,
session management, personalization/database, application, m-commerce,
etc). These likely are hosted in multiple datacenters or server
complexes with different deployment requirements (e.g.
security/capacity/load-balancing), and the complexity of server-server
direct API's limit the ability to coordinate the interaction of these
without ever relying upon HTTP redirect. To put it simply, "this is how
the web works". To ignore the significance of redirect in service design
is again to put our heads in the sand. We objected to it being a hard
"don't do it" criteria in BP1 and MobileOK (but accepted it, if only in
order not to delay further the completion of that work), since we felt
that was unrealistic. BP2 is the chance we have to set the record
straight. As far as mobile-specific, there are a lot of reasons why,
when redirect is to be used, it should be used conservatively
(cost/latency/reliability), and that content providers should consider
using techniques to break up redirect sequences (especially since a lot
of the overall latency can be in server processing, and not round-trip
delay).

19. 5.5.1 Transfer Compression

I am a bit sceptical about the generic claims of compression ratios - I
think that the figures would be better if toned down to speak of
"improvement". I think also that it needs to be mentioned that there is
non-universal support and that compression and decompression adds to
delay and to batter consumption etc.

[bryan] While the claims are not generic (I have been doing this for
enough years to know that, for a fact), I can make the claims less
definite. As far as support, this goes for most browser / web
application features, but I will also clarify that. In this case though
it is probably less of an issue, since deflate/gzip is supported by
nearly every WAP2 browser that has been deployed in the last few years
(even though it was mentioned that XMLHTTPRequest does not support it,
which as I've said would be a significant weakness in AJAX if true).

20. 5.5.2 Automatically Issued Network Requests

How does one ascertain a user's roaming status?

[bryan] There are both device-side methods (through device API's
provided by specific platforms) and server-side methods (e.g. through
source-IP assessment or use of roaming information forwarded by network
service providers). 

21. 5.5.3 Push Methods

Commented on elsewhere

[bryan] I haven't seen any strong arguments why the mobile-specific push
methods (and they are truly mobile specific, so that is not an issue
here) aren't a significant advantage in building great web applications,
especially those that offer asynchronous server-initiated content
delivery. The only other "push" methods in use are really just
optimized/adaptive polling, and in the end much more costly in terms of
battery life and data usage.

22. 5.5.4 Minimize Application Size

Think that an example of what is meant ref CSS would be very useful.
Also do we have anything other than CSS to reference here? Otherwise
should we rename the section Minimize CSS?

In direct response to Adam's comment on the same section, as I
understand it the technique is to provide path references rather than to
use class-based techiques. I think the comment about maintainability is
just that that as a author you're going to change your styles more
reliably by centralizing them.

[bryan] Specific text changes would be helpful, as I'm not a SME in this
area.

23. Scripting 5.9.4 and 5 

Would we benefit from a fully worked example as a non-normative
appendix, rather than having extended code segments here? Also I think
we'd prefer reference to XHTML Basic rather than to XHTML MP 1.2 (which
we've found to be difficult to reference, as I recall).

[bryan] If I can get a block submission for the new appendix, I will
include it.

24. Understand that the majority of the rest is placeholder but this
needs careful review as for it example it currently suggests to the
untutored eye that we propose to do mobileOK for BP2, which afaik, we
don't. Or at least "have no current plans to do so".

[bryan] This relates to the testability/test aspects, so I guess will
get edited out if they do.

Jo




> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Sullivan, Bryan
> Sent: 09 April 2008 23:48
> To: Yeliz Yesilada; Adam Connors
> Cc: MWI BPWG Public
> Subject: RE: BP2 Comments.
> 
> 
> 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 Thursday, 24 April 2008 07:04:23 UTC