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

Re: BP2 Comments.

From: Yeliz Yesilada <yesilady@cs.man.ac.uk>
Date: Thu, 3 Apr 2008 14:25:59 +0100
Message-Id: <DFB3B2FC-E212-4D0B-860C-73FAEABA0A86@cs.man.ac.uk>
To: MWI BPWG Public <public-bpwg@w3.org>

Would the following WCAG 2.0 success criteria be useful for BP 2?

2.2.5 When an authenticated session expires, the user can continue  
the activity without loss of data after re-authenticating.

Error Prevention (Legal, Financial, Data):
3.3.4 For Web pages that cause legal commitments or financial  
transactions for the user to occur, that modify or delete user- 
controllable data in data storage systems, or that submit user test  
responses, at least one of the following is true...

Error Prevention (All):
3.3.6 For Web pages that require the user to submit information, at  
least one of the following is true...

On 2 Apr 2008, at 16:16, Yeliz Yesilada wrote:
> 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
> 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, 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, 3 April 2008 13:26:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:51 UTC