- From: Yeliz Yesilada <yesilady@cs.man.ac.uk>
- Date: Thu, 3 Apr 2008 14:25:59 +0100
- To: MWI BPWG Public <public-bpwg@w3.org>
Would the following WCAG 2.0 success criteria be useful for BP 2? Re-authenticating: 2.2.5 When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. <http://www.w3.org/TR/2007/WD-WCAG20-20071211/#time-limits-server- timeout> <http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/time- limits-server-timeout.html> 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... <http://www.w3.org/TR/2007/WD-WCAG20-20071211/#minimize-error- reversible> <http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/minimize- error-reversible.html> Error Prevention (All): 3.3.6 For Web pages that require the user to submit information, at least one of the following is true... <http://www.w3.org/TR/2007/WD-WCAG20-20071211/#minimize-error- reversible-all> <http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/minimize- error-reversible-all.html> Regards, Yeliz. 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 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, 3 April 2008 13:26:30 UTC