IRC log of bpwg on 2009-03-25

Timestamps are in UTC.

10:27:13 [RRSAgent]
RRSAgent has joined #bpwg
10:27:14 [RRSAgent]
logging to http://www.w3.org/2009/03/25-bpwg-irc
10:27:26 [Zakim]
Zakim has joined #bpwg
10:27:50 [Jo]
Meeting: BPWG F2F London March 2009, Day 1
10:28:05 [Jo]
chair: jo
10:28:06 [francois]
francois has joined #bpwg
10:28:42 [francois]
francois has changed the topic to: BPWG F2F meeting in London
10:28:47 [francois]
RRSAgent, draft minutes
10:28:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois
10:29:11 [francois]
RRSAgent, make logs public
10:30:03 [francois]
Present: Adam, Rob, SeanP, Jonathan, AlanC, Jo, Dan, Kai, francois
10:30:46 [francois]
Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html#agenda
10:32:01 [Jo]
Regrets: I have none
10:32:50 [Jo]
zakim, room for 5?
10:32:51 [Zakim]
ok, Jo; conference Team_(bpwg)10:32Z scheduled with code 26631 (CONF1) for 60 minutes until 1132Z
10:33:24 [Zakim]
Team_(bpwg)10:32Z has now started
10:33:31 [Zakim]
+Bryan_Sullivan
10:33:41 [francois]
zakim, code?
10:33:41 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois
10:33:43 [Jo]
zakim, codse?
10:33:44 [Zakim]
I don't understand your question, Jo.
10:34:23 [Zakim]
+ +0207881aaaa
10:34:42 [Jo]
zakim, aaaa is berners_lee_at_google
10:34:42 [Zakim]
+berners_lee_at_google; got it
10:35:18 [achuter]
achuter has joined #bpwg
10:35:37 [Jo]
zakim, berners_lee_at_google holds Jo, Francois, Alan, Jonathan, Kai, Adam, Rob, Sean, DKA
10:35:37 [Zakim]
+Jo, Francois, Alan, Jonathan, Kai, Adam, Rob, Sean, DKA; got it
10:37:55 [achuter]
achuter has joined #bpwg
10:38:45 [rob]
Scribe: Rob
10:38:50 [DKA]
DKA has joined #bpwg
10:38:51 [rob]
ScribeNick: rob
10:40:49 [adam]
adam has joined #bpwg
10:41:25 [rob]
Topic: MWABP
10:41:46 [adam]
http://docs.google.com/Doc?id=dft77cn8_35cvjfktc2&hl=en
10:43:14 [rob]
adam: This doc contains a few comments from Bryan, Eduardo and Jeff and others and all the ToDos highlighted
10:43:58 [rob]
Jo: shall we start going through in order?
10:44:37 [rob]
adam: ok, starting at the top, can Francois reference the emails?
10:45:35 [francois]
-> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0057.html Bryan's latest comments on MWABP
10:45:49 [Bryan]
seem to have lost the audio
10:46:42 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html Eduardo's comments on MWABP
10:47:28 [Zakim]
-berners_lee_at_google
10:47:39 [francois]
-> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0036.html Jeff's comments on MWABP
10:48:28 [Zakim]
+berners_lee_at_google
10:48:47 [francois]
-> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0051.html Jeff's ACTION-910 on use of canvas
10:50:01 [francois]
-> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/290 ISSUE-290 raised by Jonathan
10:50:16 [francois]
-> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/291 ISSUE-291 raised by Jonathan
10:50:28 [DKA]
http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets
10:50:31 [DKA]
?
10:50:36 [rob]
DKA: reference this link into Web Apps WG?
10:51:59 [rob]
... this is the widgets section of the WG's wiki. As good as it gets
10:52:20 [rob]
Jo: Is there nothing that says "this is what a widget is"?
10:52:31 [rob]
DKA: no, too political!!
10:53:45 [rob]
adam: Onto Eduardo's point about assumed device capabilities and baseline compliance...
10:53:55 [Jo]
Jo has joined #bpwg
10:54:08 [Jo]
ACTION: Dan to write a relevant section at Webapps Wiki to act as reference for On MWABP 1.3.2 DKA
10:54:08 [trackbot]
Created ACTION-918 - Write a relevant section at Webapps Wiki to act as reference for On MWABP 1.3.2 DKA [on Daniel Appelquist - due 2009-04-01].
10:54:15 [rob]
... Any suggestions for this?
10:54:31 [rob]
DKA: isn't this an Advanced Delivery Context?
10:55:45 [rob]
Jo: I'd prefer to leave as it is: being compliant with "JavaScript" or "HTMLx" is problematic
10:55:48 [DKA]
PROPOSED RESOLUTION: We will remain ambiguous in the document as regards compliance to specific language profiles...
10:56:10 [rob]
+1
10:56:17 [Jo]
PROPOSED RESOLUTION: Replace 1.3.4 "Compliance" with "Capability"
10:56:42 [rob]
+1
10:56:43 [SeanP]
+1
10:57:09 [DKA]
+1
10:57:11 [Jo]
+1
10:57:43 [rob]
RESOLUTION: Replace 1.3.4 "Compliance" with "Capability"
10:59:00 [Jo]
PROPOSED RESOLUTION: We don't think it worthwhile to propose specific versions of HTMLO, CSS, Javascript
10:59:18 [Jo]
s/HTML0/HTML/
10:59:29 [Jo]
s/HTMLO/HTML/
10:59:34 [rob]
DKA: do we want specific resolution on not referencing specific language versions?
10:59:45 [Jo]
+1 to me
11:01:00 [rob]
Bryan: given a lot of the doc is about "use the capabilities the device has" then don't we assume HTML5?
11:01:32 [rob]
Jo: no, we're going to talk about capabilities like client-side-storage instead
11:01:51 [rob]
DKA: this is coming up in the next point
11:02:35 [dom]
dom has left #bpwg
11:02:37 [rob]
+1
11:02:56 [SeanP]
+1
11:02:58 [Bryan]
+1
11:03:02 [rob]
RESOLUTION: We don't think it worthwhile to propose specific versions of HTML, CSS, Javascript
11:03:05 [DKA]
+1
11:04:35 [rob]
adam: Use client-size-storage. HTLM5, BONDI for example.
11:05:02 [JonathanJ]
Bondi: http://www.omtp.org/bondi
11:06:27 [rob]
DKA: This is OK as an informal reference for BONDI, because they're pre-release specs
11:06:58 [rob]
SeanP: any implementations yet?
11:07:16 [rob]
francois: no, but Symbian is close
11:07:39 [rob]
Jo: this is a forward-looking BP
11:08:41 [rob]
DKA: HTML5 client-side-storage is real on a number of handsets
11:09:08 [rob]
s/client-size/client-side/
11:10:09 [francois]
s/Symbian is close/I heard David Wood from Symbian yesterday mention their intention to implement Bondi in 2009/
11:10:09 [rob]
adam: should we use the Offline Web Applications reference?
11:10:31 [Jo]
PROPOSED RESOLUTION: Generalise HTML 5 to "Client Size Storage" and add informative reference to BONDI
11:11:03 [Jo]
+1
11:11:07 [Bryan]
+1
11:11:10 [JonathanJ]
+1
11:11:13 [SeanP]
+1
11:11:17 [francois]
+1
11:11:21 [DKA]
+1
11:11:22 [rob]
+1
11:12:15 [francois]
+1 from Kai
11:12:25 [rob]
RESOLUTION: Generalise HTML 5 to "Client Side Storage" and add informative reference to BONDI
11:14:24 [francois]
http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html
11:14:29 [JonathanJ]
http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?
11:14:34 [rob]
adam: question from Bryan and Eduardo is about is replicating client-side-storage on the server really a best practice or just another technique?
11:17:42 [rob]
Bryan: it's not always necessary but server-based synchronisation of data between multiple devices is useful. Just don't want to discourage use of client-side-storage.
11:17:56 [JonathanJ]
s/http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?//
11:18:12 [rob]
adam: yes, rewording is wise to highlight this
11:18:32 [Jo]
s|s/http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?//||
11:18:48 [Jo]
s|http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?||
11:19:11 [Jo]
rrsagent, draft minutes
11:19:11 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html Jo
11:33:25 [achuter]
achuter has joined #bpwg
11:34:46 [francois]
s/David Wood from Symbian/David Wood from Symbian [Post discussion note from francois: I most probably confused David from Symbian with Morgan Gillis from the Limo Foundation]
11:35:29 [DKA]
q?
11:36:55 [rob]
adam: continuing onto minify: since this is the name of a specific tool we should avoid the word minify and explain what it does
11:37:51 [rob]
Jo: or find another word (like compression or optimisation)?
11:40:19 [rob]
DKA: but a search on "minify" yields lots of other references (inc Wikipedia definition)
11:41:18 [JonathanJ]
JonathanJ has joined #bpwg
11:42:33 [rob]
adam: can someone take an action to research a recommendation?
11:44:30 [rob]
Jo: I think it's ok to say "minify" as a verb for this
11:46:34 [rob]
... and a note to explain we do not refer specifically to the minify utility
11:46:46 [Jo]
PROPOSED RESOLUTION: Leave in the word "minify" as we mean it in a generic sense (like hoover vs. Hoover in EN-GB) and write a Note: explaining the types of things we mean here
11:46:56 [rob]
+1
11:46:58 [Jo]
+1
11:47:05 [DKA]
+1
11:47:08 [SeanP]
+1
11:47:14 [rob]
RESOLUTION: Leave in the word "minify" as we mean it in a generic sense (like hoover vs. Hoover in EN-GB) and write a Note: explaining the types of things we mean here
11:49:06 [rob]
adam: Eduardo raised point that inline style-sheets isn't necessarily a good practice. Lack of cache can degrade performance
11:49:25 [rob]
DKA: isn't this encapsulated in the word "consider"?
11:50:46 [rob]
adam: if it's often not a good idea then perhaps we should not recommend even considering it to avoid confusion?
11:51:07 [rob]
... there is already a BP about minimising the number of requests
11:52:10 [rob]
Jo: this is in MWBP1
11:52:45 [rob]
adam: so let's remove 3.4.6 from MWABP
11:53:40 [Jo]
zakim, ping me in 7 minutes
11:53:40 [Zakim]
ok, Jo
11:54:29 [rob]
Jo: 3.4.6 does say a little bit more than MWBP
11:56:26 [rob]
adam: but it is potentially going to mislead
11:56:51 [Jo]
PROPOSED RESOLUTION: Remove 3.4.6 ref inline style sheets and script
11:56:53 [Jo]
+1
11:56:56 [rob]
+1
11:56:58 [achuter]
+1
11:57:03 [francois]
+1
11:57:07 [kscheppe]
kscheppe has joined #bpwg
11:57:09 [SeanP]
+1
11:57:17 [rob]
RESOLUTION: Remove 3.4.6 ref inline style sheets and script
11:59:24 [rob]
adam: onto 3.4.11/12: they say much the same thing. But we're suggesting doing something without concrete evidence that's it a big improvement.
12:00:40 [Zakim]
Jo, you asked to be pinged at this time
12:00:43 [rob]
... Bryan suggested returning to the original wording but on a modern browser it's simply not a power concern
12:01:11 [rob]
Jo: but it is a concern for discovery of content by search spiders etc
12:01:41 [rob]
... and "minimise time to first view"
12:03:31 [Jo]
PROPOSED RESOLUTION: Remove 3.4.11 and 3.4.12 as they are hard to quantify and are not actionable
12:04:31 [rob]
Bryan: The original advice was submitted by Jose at Telefonica and was to start with a static HTML structure and manipulate that
12:05:22 [rob]
adam: yes, it got less clear as the advice I disagreed with got removed. We're down to the point where this point does not add much value.
12:05:52 [Jo]
+1
12:06:07 [rob]
+1
12:06:17 [Kai]
+1
12:06:21 [Jo]
ACTION: adam to ping Jose ref the battery and DOM manipulation question
12:06:21 [trackbot]
Created ACTION-919 - Ping Jose ref the battery and DOM manipulation question [on Adam Connors - due 2009-04-01].
12:06:27 [rob]
RESOLUTION: Remove 3.4.11 and 3.4.12 as they are hard to quantify and are not actionable
12:07:16 [Jo]
PROPOSED RESOLUTION: instead of 3.4.11 and 3.4.12 have a section on Minimize time to first view
12:07:23 [rob]
+1
12:07:24 [Jo]
+1
12:07:33 [rob]
RESOLUTION: instead of 3.4.11 and 3.4.12 have a section on Minimize time to first view
12:08:30 [rob]
adam: 3.5.2 Use Scripting could be combined into "avoid page reloads"
12:09:18 [rob]
Jo: does this inhibit data discovery again?
12:09:39 [rob]
adam: make it all available as an RSS field?
12:10:06 [rob]
Jo: load all the data with display:none until script reveals it?
12:10:48 [Jo]
PROPOSED RESOLUTION: Remove 3.5.2 and 3.5.4 and replace with "Avoid Page Reloads"
12:10:55 [francois]
+1
12:10:58 [adam]
+1
12:11:00 [Jo]
scribenick SeanP
12:11:11 [francois]
Scribenick: SeanP
12:11:23 [Jo]
s/scribenick SeanP//
12:13:00 [SeanP]
RESOLUTION: Remove 3.5.2 and 3.5.4 and replace with "Avoid Page Reloads"
12:13:58 [SeanP]
Jo: We want say something about techniques for what?
12:14:21 [SeanP]
...The best practice is about flipping views.
12:14:43 [SeanP]
Adam: We have 3.5.2, avoid page reloads.
12:15:06 [SeanP]
..3.5.2 and 3.5.4 are combined into one BP: avoid page reloads.
12:15:40 [SeanP]
...downside of XHR is that content is not discoverable by Lycos or other crawlers.
12:16:10 [SeanP]
...I'd like someone to devise the right thing to do in this case.
12:16:30 [SeanP]
Jo: It's obvious that if you want discoverable content, then you should like to it.
12:16:58 [SeanP]
DKA: We're talking about Web Apps here. We're talking about cool apps that may not be indexable.
12:17:05 [SeanP]
Jo: It's worth noting however.
12:17:51 [SeanP]
s/like/link/
12:18:16 [Jo]
PROPOSED RESOLUTION: Under new BP Avoid Page Reloads, include a note to the effect that content that is _only_ retrieved dynamically and is not available via links is not discoverable
12:19:01 [adam]
+1
12:19:04 [rob]
+1
12:19:08 [SeanP]
Jo: Adam, you'd like to add some techniques, right.
12:19:12 [Bryan]
+1
12:19:17 [achuter]
+1
12:19:18 [francois]
+1
12:19:20 [SeanP]
Adam: No, I'm fine with just the note.
12:19:34 [SeanP]
RESOLUTION: Under new BP Avoid Page Reloads, include a note to the effect that content that is _only_ retrieved dynamically and is not available via links is not discoverable
12:19:59 [SeanP]
Jo: 3.5.8, Separate Rarely Used Functionality
12:20:25 [SeanP]
Adam: My proposal is replace 3.5.8 with Partition Application Functionality
12:21:23 [SeanP]
...Make this section less technical. If you have a large complex app, chop it up into small parts instead of having a giant JS file.
12:21:31 [SeanP]
Jo: Is this a mobile best practice?
12:22:56 [SeanP]
Francois: It's not necessarily mobile; if you just need to download a small part of the functionality for your app, then you should do it.
12:23:15 [SeanP]
Adam: We see that a lot of the time taken for an app is JS parsing time.
12:23:37 [SeanP]
Francois: Could be part of minimize time to first view.
12:24:06 [SeanP]
Adam: I'll move it to "minimize time to first view"
12:25:06 [SeanP]
Francois: I think we'll have the same discussion on 3.5.9, Enable Progressive Rendering
12:25:26 [Jo]
PROPOSED RESOLUTION: Remove 3.5.8 and take relevant portions of it into new BP minimize time to first view - parsing Javascript being time consuming and resource intensive
12:26:53 [rob]
+1
12:26:56 [Jo]
+1
12:26:56 [francois]
+1
12:26:56 [Kai]
+1
12:26:57 [JonathanJ]
+1
12:26:59 [Bryan]
+1
12:27:00 [achuter]
+1
12:27:02 [adam]
+1
12:27:03 [SeanP]
RESOLUTION: Remove 3.5.8 and take relevant portions of it into new BP minimize time to first view - parsing Javascript being time consuming and resource intensive
12:27:32 [SeanP]
Jo: Moving to 3.5.9 Enable Progressive Rendering
12:28:30 [SeanP]
Adam: This may be kind of redundant since it is in other standards docs.
12:28:50 [SeanP]
Jo: This can become "Minimize time to first view"
12:29:16 [SeanP]
Adam: We can rename it.
12:30:05 [SeanP]
Adam: Enable Progressive Rendering is just a bullet point in "minimize start up time"
12:30:15 [Jo]
PROPOSED RESOLUTION: Absorb 3.5.9 into new BP Minimise time to first view as a technique
12:30:33 [rob]
+1
12:30:35 [SeanP]
+1
12:30:38 [SeanP]
RESOLUTION: Absorb 3.5.9 into new BP Minimise time to first view as a technique
12:31:27 [SeanP]
Francois: We were going to change the title of 3.5.10 to a more general title.
12:32:05 [Jo]
PROPOSED RESOLUTION: Genenralise 3.5.10 to refer to consistency of state across devices for a given user
12:32:17 [Kai]
+1
12:32:37 [francois]
+1
12:32:44 [rob]
+1
12:32:47 [SeanP]
+1
12:32:49 [DKA]
+1 (and support for calling out Desktop and Mobile as a specific example)
12:33:05 [SeanP]
RESOLUTION: Generalise 3.5.10 to refer to consistency of state across devices for a given user
12:33:13 [Jo]
s/Genenralise/Generalise/
12:34:45 [SeanP]
Kai: On 3.5.4, Group closely couple views, it recommends that you hide content. We've played around with that and it makes really large pages.
12:35:02 [SeanP]
Adam: I think that section is going to go away.
12:35:52 [SeanP]
Kai: On 3.5.1. Design for Multiple Interaction Methods, should we refer to Multi-Modal Interaction Group?
12:36:04 [SeanP]
Adam: I think that is different.
12:36:38 [SeanP]
DKA: Yes, we're just trying to highlight the focus vs. touch vs. pointer.
12:37:27 [SeanP]
Kai: Is the Canvas tag a best practice; I'm not sure.
12:37:56 [SeanP]
Adam: A good time to discuss that is when we talk about Jeff's Canvas contribution.
12:38:34 [SeanP]
Adam: The next section to discuss is 3.6.3 and 3.6.4
12:39:37 [SeanP]
Adam: Eduardo raised the point: A lot of BPs say that we should use XHR, and then we have a BP that says make it works on devices that don't support XHR.
12:40:00 [SeanP]
Kai: I don't think it is contradictory; it's just necessary.
12:41:11 [SeanP]
Jo: You should try to make a mobile app work on as wide a range of devices as possible. Just because we are recommending web apps doesn't mean that they shouldn't necessarily work on lower class devices.
12:43:31 [SeanP]
Bryan: I think we should recommend where important, use discovery techniques to discover the functionality of the device, but we shouldn't say that you have to design a version for the lowest common demoninator.
12:43:48 [SeanP]
s/demoninator/denominator/
12:44:33 [SeanP]
Bryan: I could build a web app that has nothing to do with network interaction; which just uses local interaction on the device.
12:44:50 [SeanP]
Adam: I think that is my feeling as well.
12:45:15 [SeanP]
Kai: Isn't that the same as saying we are relying on class 2 and 3?
12:45:32 [SeanP]
Bryan: You should be intelligent to use alternate means.
12:45:53 [SeanP]
Kai: You need to classify your devices so you know what to aim for.
12:46:13 [SeanP]
Bryan: You need to know what you are aiming for.
12:46:47 [adam]
http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html
12:47:26 [SeanP]
Adam: What has been said today, we seem to feel that these BPs (3.6.3 and 3.6.4) are OK.
12:48:34 [SeanP]
Bryan: If you are going to reach the broadest list of devices, you need to use alternate techniques.
12:49:17 [SeanP]
DKA: For advanced devices, this doc is applicable; for legacy devices we say use other techniques.
12:49:31 [SeanP]
Jo: We are not saying that.
12:50:06 [SeanP]
Jo: If you are only developing for the iPhone; is that good practice?
12:50:20 [SeanP]
Adam: Depends on the market. We don't develop for some devices.
12:51:24 [SeanP]
...This doc focuses on devices that have platforms that e.g. support JavaScript.
12:51:49 [SeanP]
Jo: We also need to deal with JS being turned off, but I suppose that doesn't happen much anymore.
12:52:12 [JonathanJ]
how about to add categorize about class within each statement ?
12:52:18 [SeanP]
Francois: Eduardo brought up the point that "typical device" may not be the best way to word it.
12:53:24 [SeanP]
Jonathan: I would like to see categories under each class of device.
12:53:54 [Jo]
PROPOSED RESOLUTION: Change "typical configuration" to "example configuration" under 3.6.3
12:54:23 [SeanP]
Adam: We're talking about using icons in the document to specify what kinds of devices BPs are target for.
12:54:43 [SeanP]
DKA: I think the icons are a great idea; after all they are my idea.
12:54:58 [SeanP]
Adam: I agree that the icons are a good idea.
12:55:00 [rob]
+1
12:55:03 [adam]
+1
12:55:07 [DKA]
+1
12:55:07 [SeanP]
RESOLUTION: Change "typical configuration" to "example configuration" under 3.6.3
12:55:07 [JonathanJ]
+1
12:55:43 [SeanP]
Jo: We are using icons to specify the features that the device supports.
12:56:07 [SeanP]
Jo: I think it is better to do it feature by feature instead of class by class.
12:56:53 [SeanP]
Adam: On 3.6.4 we change the wording from "Possible" to "Appropriate"
12:57:31 [SeanP]
Alan: Are people going to understand what "406 Not Acceptible" means?
12:57:45 [SeanP]
Adam: Well, it's standard HTTP.
12:58:38 [Jo]
PROPOSED RESOLUTION: Water down the language in in 3.6.4 to recomend providing non Javascript versions rather than "if at all possible" for the reasons already stated in that section
12:58:52 [SeanP]
DKA: Can we just provide a link to BP1?
13:00:54 [SeanP]
Francois: It's more about the spirit of: don't lock yourselves into a technology that you don't necessarily need.
13:01:26 [SeanP]
...there may be parts of your app that don't need the advanced stuff. I don't think that this translates into a BP, however.
13:02:10 [SeanP]
Jo: I think 3.6.4 needs more than just changing "Possible" to "Appropriate"
13:02:35 [SeanP]
Bryan: How about changing to "Where necessary and possible"?
13:02:42 [DKA]
q+
13:03:12 [DKA]
ack me
13:03:14 [SeanP]
Adam: I think there is a difference between supporting desktop and mobile and mobile and legacy.
13:04:04 [SeanP]
Adam: If we wait a couple of years, all devices will support full internet browsers.
13:04:24 [SeanP]
DKA: You could follow all the recommendations in this document and not be mobileOK.
13:05:19 [DKA]
q+ to suggest "Support a non-JavaScript Variant if You Want to Reach the Billions of Potential Users Who Don't have a Whizzy Smart Phone"
13:05:29 [SeanP]
Adam: If you have to build an XHTML version of every app, I'm not sure I want to do that because the XHTML version won't get the usage.
13:05:35 [DKA]
q?
13:05:38 [DKA]
ack me
13:05:38 [Zakim]
DKA, you wanted to suggest "Support a non-JavaScript Variant if You Want to Reach the Billions of Potential Users Who Don't have a Whizzy Smart Phone"
13:05:40 [Jo]
ack d
13:06:16 [SeanP]
Jo: We need to say something like "Don't forget about the devices that don't support advanced apps."
13:06:27 [SeanP]
DKA: That's basically what I wanted to say.
13:08:05 [Jo]
PROPOSED RESOLUTION: Water down the language in in 3.6.4 to recommend providing non Javascript versions where it is attractive to reach the billions of users that don't have a smart phone rather than "if at all possible" for the reasons already stated in that section
13:08:18 [Jo]
+`1
13:08:34 [adam]
+1
13:08:35 [Kai]
+1
13:08:35 [rob]
+1
13:08:36 [JonathanJ]
+1
13:08:38 [Jo]
zakim, '1 is where your heart is
13:08:38 [Zakim]
I don't understand ''1 is where your heart is', Jo
13:08:42 [achuter]
+1
13:08:52 [francois]
+1
13:08:53 [Bryan]
+1
13:08:54 [SeanP]
RESOLUTION: Water down the language in in 3.6.4 to recommend providing non Javascript versions where it is attractive to reach the billions of users that don't have a smart phone rather than "if at all possible" for the reasons already stated in that section
13:08:56 [DKA]
+1
13:09:26 [SeanP]
Francois: Is "local index" clear to everyone?
13:10:32 [SeanP]
DKA: I think it needs expansion to something like "local device repository" or something like that.
13:11:42 [SeanP]
Jo: Let's move on to Bryan's comments.
13:11:53 [Jo]
-> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0057.html Bryan's latest comments on MWABP
13:14:23 [SeanP]
Adam: We've dealt with the first two on 3.1.2 and 3.1.3.
13:15:15 [SeanP]
Adam: Bryan refers to BONDI directly, we need to mention it directly in the document.
13:15:30 [SeanP]
Bryan: The reference we have to BONDI is not good enough.
13:16:51 [SeanP]
Adam: It was hard to visualize an app that didn't use personalization, so it seemed kind of obvious that that's what you need to do to write a mobile app. That's why most of the personalization stuff was removed.
13:17:11 [SeanP]
...We should look at the older version and newer version of the doc side by side.
13:18:12 [SeanP]
Bryan: The techniques for personalization for desktop don't work for mobile apps. The developer needs to go learn the techniques somewhere if they aren't in this document.
13:19:15 [SeanP]
Adam: There is the aspect of using user id from service providers, which not everyone as access to.
13:19:26 [SeanP]
Bryan: That data is widely available.
13:20:17 [SeanP]
Jo: The feeling of the group is that using the different user data available through different service providers is not practical for app developers.
13:20:36 [DKA]
q+ to suggest aggregators can provide this function...
13:21:12 [Jo]
ack d
13:21:12 [Zakim]
DKA, you wanted to suggest aggregators can provide this function...
13:21:15 [SeanP]
Jo: There has been a lot of water under the bridge since this was previously discussed.
13:22:15 [SeanP]
DKA: In defense of Bryan's position, my perception is that there are now more options for developers to take advantage of personalization. For example, Bango has something that aggregates this kind of information.
13:22:37 [SeanP]
Jo: This has been discussed quite a lot in the past.
13:22:58 [SeanP]
DKA: I think things have changed in the last 10 months.
13:23:15 [SeanP]
Bryan: I understand Jo's position, but there isn
13:23:15 [Jo]
ACTION: Dan to work with bryan to propose some text on user identification
13:23:15 [trackbot]
Created ACTION-920 - Work with bryan to propose some text on user identification [on Daniel Appelquist - due 2009-04-01].
13:23:47 [SeanP]
s/isn/isn't anything in the document right now.
13:24:22 [SeanP]
DKA: I think using an aggregator is a mobile thing.
13:24:48 [SeanP]
Jo: Next: Bryan's comment on 3.2
13:24:57 [francois]
[ I note there was a long discussion on login forms with 4 resolutions during a BPWG call following the editorial meeting on MWABP, the result of which is not in the latest draft. See: http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 ]
13:25:40 [SeanP]
Bryan: This section talks about JSON data. What are the methods for preserving confidentiality of data?
13:26:59 [SeanP]
Adam: Originally we said that you don't always need to use HTTPS, you can use hashed identities. The security team said that HTTPS is not the expensive and using hashed identities was dubious.
13:27:51 [SeanP]
Bryan: Security people always say to use a secure connection. This isn't always necessary.
13:28:12 [jeffs]
jeffs has joined #bpwg
13:28:13 [SeanP]
...Security people are not always the application developers.
13:28:49 [SeanP]
Jo: I don't think we can disregard what the W3C security team said.
13:29:15 [SeanP]
Adam: I think I agree with Bryan here.
13:30:39 [Zakim]
-Bryan_Sullivan
13:30:39 [SeanP]
...however, I think the safest thing to do, is unless we can find some good reasons to recommend these dubious techniques, what have now is good.
13:30:40 [Zakim]
-berners_lee_at_google
13:30:41 [Zakim]
Team_(bpwg)10:32Z has ended
13:30:42 [Zakim]
Attendees were Bryan_Sullivan, +0207881aaaa, Jo, Francois, Alan, Jonathan, Kai, Adam, Rob, Sean, DKA, berners_lee_at_google
13:31:19 [francois]
RRSAgent, draft minutes
13:31:19 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois
13:35:47 [jeffs]
zakim, conference code please?
13:35:47 [Zakim]
the conference code is hidden, jeffs
14:19:34 [Jo]
zakim, room for 4?
14:19:35 [Zakim]
ok, Jo; conference Team_(bpwg)14:19Z scheduled with code 26631 (CONF1) for 60 minutes until 1519Z
14:19:51 [Jo]
zakim, code?
14:19:51 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo
14:20:07 [Zakim]
Team_(bpwg)14:19Z has now started
14:20:14 [Zakim]
+Bryan_Sullivan
14:20:26 [Zakim]
+berners_lee_at_google
14:20:57 [francois]
ScribeNick: francois
14:28:56 [francois]
[Debussy interlude]
14:29:35 [francois]
[not-Debussy-anymore interlude]
14:34:03 [francois]
BanJo: OK, so...
14:34:04 [Jo]
present+ Eduardo
14:34:52 [francois]
Jo: Let's resume
14:35:36 [francois]
adam: 3.3.3.1 and 3.3.3.2 sections
14:35:55 [francois]
... I'm fine with Bryan's proposal
14:36:35 [francois]
Jo: I think that we changed it to "in an inappropriate manner" because we didn't want to be prescriptive.
14:36:44 [google]
google has joined #bpwg
14:37:30 [francois]
s/inappropriate/appropriate
14:37:59 [francois]
bryan: OK, that answers the problem.
14:38:21 [francois]
... but I'm talking about 3.3.3.1
14:38:53 [Zakim]
+??P3
14:39:11 [jeffs]
zakim ??P3 is jeffs
14:39:37 [francois]
... we're not clear as to what constitutes the type of information that should be explained.
14:39:37 [jeffs]
hello, on voice now & lurking
14:40:37 [francois]
... and mentioning the information doesn't say how users information will be protected.
14:40:51 [francois]
... We believe developers need more precise instructions.
14:42:24 [francois]
... All the section is about disclosure.
14:44:07 [francois]
adam: the point is about saying that asking users for accessing their contacts doesn't necessarily allow the application to upload the information to some server.
14:44:50 [francois]
bryan: 3.3.3.1 is ok.
14:45:17 [EdC]
EdC has joined #bpwg
14:45:28 [francois]
... but the server exchange case is not backup-ed by any actionable practice.
14:48:00 [francois]
jo: in short, both of Bryan's comments imply changes in 3.3.3.2. Are you happy with that, Adam?
14:48:57 [francois]
... Bryan's point is to stay that text in 3.3.3.1 needs to be reflected in 3.3.3.2.
14:49:54 [francois]
adam: I guess I'm questioning how the new wording to 3.3.3.2 adds clarity.
14:50:36 [francois]
bryan: in many cases, the use of APIs need some kind of confirmation dialog. That's the base.
14:51:07 [francois]
... In many cases, the Web application doesn't control the underlying framework.
14:51:41 [francois]
... and the underlying framework is handling the trust level access dialog.
14:52:53 [Jo]
PROPOSED RESOLUTION: Add a note along the lines sugegsted by Bryan ref making sure that information about the use of data is made available to the user and noting that the guidance needs to be tailored to how the application interacts with the device on a case by case basis
14:53:19 [jeffs]
+1
14:53:27 [rob]
+1
14:53:34 [Jo]
+1
14:53:35 [Bryan]
+1
14:53:39 [adam]
+1
14:53:42 [DKA]
+1
14:53:43 [google]
+1
14:53:43 [SeanP]
+1
14:53:47 [JonathanJ]
+1
14:53:48 [francois]
RESOLUTION: Add a note along the lines suggested by Bryan ref making sure that information about the use of data is made available to the user and noting that the guidance needs to be tailored to how the application interacts with the device on a case by case basis
14:54:09 [Kai]
+1
14:54:12 [jeffs]
+1
14:54:14 [EdC]
+1
14:54:59 [francois]
jo: Moving on to the PIM data icon
14:55:27 [francois]
bryan: Here, we're talking to a broader set of data than just personal information, e.g. gallery.
14:55:45 [francois]
adam: sounds reasonable to me, we haven't had a conversation about what the icons should be yet.
14:56:02 [Jo]
PROPOSED RESOLUTION: Change reference to PIM DATA APIs to DEVICE DATA APIs
14:56:16 [SeanP]
+1
14:56:19 [Bryan]
+1
14:56:20 [JonathanJ]
+1
14:56:20 [rob]
+1
14:56:24 [francois]
RESOLUTION: Change reference to PIM DATA APIs to DEVICE DATA APIs
14:56:27 [Kai]
+1
14:56:28 [jeffs]
+1
14:57:18 [francois]
bryan: about 3.4, the current text implies that only resource-oriented issues are important.
14:58:03 [francois]
adam: on the battery use, without precise figures, I'm not sure. About service cost, it makes sense.
14:58:24 [Jo]
PROPOSED RESOLUTION: Add a reference to battery and cost in the introductory sentence of 3.4
14:58:31 [jeffs]
+1
14:58:31 [adam]
+1
14:58:37 [SeanP]
+1
14:58:42 [francois]
RESOLUTION: Add a reference to battery and cost in the introductory sentence of 3.4
14:58:42 [rob]
+1
14:58:44 [EdC]
+1
14:58:53 [JonathanJ]
+1
14:58:58 [jeffs]
+1
14:59:25 [francois]
bryan: about 3.4.1.2, the current text only talks about simple compression algorithms. There are more ambitious solutions that can be pointed out.
15:00:06 [francois]
dan: we already talk about minify in some other part.
15:00:43 [francois]
jo: how about we extend the note on minification to also include encoding techniques
15:01:08 [francois]
... there will be a reference to tokenization in the section anyway
15:02:08 [francois]
adam: there's another BP about optimizing network requests
15:02:18 [achuter1]
achuter1 has joined #bpwg
15:02:25 [francois]
bryan: if it's covered by another BP, that's fine, but that doesn't seem to be the case
15:03:00 [Kai]
as an side ---- this is also bandwidth dependent. the more bandwidth the less net effect of compression.
15:03:05 [achuter1]
achuter1 has joined #bpwg
15:03:10 [francois]
jo: we're more talking about the number of requests than the size of the requests.
15:03:52 [francois]
EdC: on the one side, you have semantic-free compression techniques, and on the other side, you have compression techniques specific to the content you're trying to compress.
15:04:08 [Jo]
PROPOSED RESOLUTION: Extend the proposed reference to the meaning of "minify" under 3.4.2 to take account of Bryans coments on EXI and WBXML
15:05:06 [francois]
adam: I think that BP is specifically about semantic-free compression
15:05:34 [francois]
jo: I'm proposing the above proposed resolution.
15:06:09 [francois]
sean: why don't we change the title to "minimize application and data size"
15:07:10 [francois]
adam: I think that's the idea, yes.
15:07:22 [francois]
jo: OK, let's take sean's suggestion into account, then.
15:07:30 [Jo]
PROPOSED RESOLUTION: Extend the proposed reference to the meaning of "minify" under 3.4.2 to take account of Bryans coments on EXI and WBXML and change the title to "Minimize Application and Data Size"
15:07:43 [jeffs]
+1
15:08:06 [Bryan]
+1
15:08:16 [francois]
+1
15:08:37 [achuter1]
+1
15:08:53 [adam]
+1
15:09:04 [francois]
[talking about whitespace stripping and the difficulty to maintain the delivered code]
15:09:34 [Kai]
+1
15:10:08 [francois]
adam: we could say something like use gzip, and don't bother to strip whitespaces
15:10:29 [francois]
RESOLUTION: Extend the proposed reference to the meaning of "minify" under 3.4.2 to take account of Bryan's comments on EXI and WBXML and change the title to "Minimize Application and Data Size"
15:10:56 [jeffs]
why not say "bother to strip whitespaces"
15:12:37 [francois]
jo: moving on to 3.4.11
15:12:54 [francois]
adam: we're going to combine the bps as agreed this morning
15:13:33 [francois]
bryan: my text is the previous text. I find it's clearer
15:13:57 [francois]
adam: if the WG wants to recommend this, I agree with the text, but I don't think we should recommend that as a BP.
15:14:29 [francois]
jo: per this morning discussion on minimizing the time to first view, what does it give?
15:16:50 [francois]
... How about this: I feel that what Bryan is proposing here is too prescriptive. If you want to reflect different user states, saying that the page should contain all the markup that declares and populates user UI elements is not generic enough.
15:16:52 [Zakim]
-??P3
15:18:19 [francois]
adam: I'm a bit confused. We agreed this morning about revamping these BPs into "minimize time to first view" and I have an action to check with José that it's ok.
15:18:45 [francois]
jo: bryan, where do you stand? 3.4.11 is to disappear.
15:19:14 [francois]
bryan: I think previous versions answered the question. Now it doesn't anymore.
15:19:30 [francois]
jo: we're to remove the question altogether.
15:20:01 [Jo]
[noted that Bryan's comment against 3.4.11.2 now moot as a result of the earlier decision and the action to check with Jose ref his original contribution]
15:20:05 [francois]
bryan: alright. If there's disagreement with the group on that technique, I'm fine with removing it.
15:22:24 [francois]
section 3.4.4.2
15:23:15 [francois]
bryan: again, there was more details in the past
15:23:34 [francois]
jo: I think that's too detailed a level, actually
15:24:19 [francois]
... Let's see if what's written now captures the sense of the former more precise text.
15:24:42 [francois]
EdC: are there any reference about works, reports about these techniques
15:24:49 [francois]
adam: not to my knowledge.
15:25:11 [francois]
EdC: has anybody measured that?
15:25:16 [francois]
adam: no. It would be great.
15:25:57 [francois]
dan: in our call for request feedback, we can specifically call out for researches that would validate/invalidate these techniques
15:26:40 [francois]
adam: there hasn't been community feedback on the past drafts, so we should not expect too much on that front
15:27:11 [francois]
jo: I think there are examples of examples in this text. It's a level of details that is inconsistent with the rest of the document.
15:28:25 [Jo]
PROPOSED RESOLUTION: On 3.4.4 leave text as is
15:28:28 [francois]
bryan: OK, there will be room for interpretation of the resulting guidelines. Let's move forward.
15:28:34 [rob]
+1
15:28:41 [DKA]
+1
15:28:42 [francois]
+1
15:29:30 [Kai]
+1
15:29:34 [EdC]
+1
15:29:38 [JonathanJ]
+1
15:29:39 [SeanP]
+1
15:29:42 [francois]
RESOLUTION: On 3.4.4, leave text as is.
15:30:33 [francois]
jo: about push, 3.5.11
15:31:08 [francois]
bryan: I suggest that the way the section is introduced was better worded in the previous version.
15:31:26 [francois]
... The purpose for using push is clearer in the previous version
15:32:21 [francois]
jo: If I recall correctly, the discussion around this was that the point of access is not restricted to operators, but may include Wi-Fi.
15:33:31 [francois]
bryan: there's work around providing solutions for this type of use case. Push in general is a way to minimize the need to do do so frequent background requests.
15:34:28 [francois]
rob: what about waking up the application as opposed to pushing a URI to the browser?
15:35:02 [francois]
bryan: no, it's a much more broader way of having notifications that is not restricted to the browser.
15:35:16 [francois]
... It's very widely deployed
15:35:31 [francois]
... It's related to optimizing network interactions.
15:36:16 [francois]
dan: If we're going to talk about this, we're going to have to talk about how to incorporate text messaging into your web applications.
15:36:31 [francois]
... and that's actually a very good way to develop cool applications.
15:36:57 [francois]
... but obviously, it only works in the context of mobile network operators access points.
15:37:47 [francois]
jo: I think it's so caveatted with roaming and yada yada that we'd have a hard time coming up with something useful.
15:38:41 [francois]
bryan: the "alternative vendor-specific initiatives" sentence, I don't know what that means
15:39:14 [francois]
jo: I think it was to refer to vendor-specific push methods, e.g. the iPhone.
15:39:58 [francois]
dan: regardless of whether there is a direct link between receiving a SMS and triggering an action, it could still be part of your application.
15:40:21 [francois]
adam: then we should talk about sending postcards
15:40:47 [francois]
dan: I'm referring to many apps I've used that make innovative uses of SMS.
15:41:28 [francois]
... [describing a cool existing app based on Zip codes and text messages]
15:41:48 [francois]
adam: we're talking about other complement technologies
15:42:15 [francois]
dan: it's something exclusively mobile that enhances the user experience of your mobile application
15:43:03 [francois]
jo: If we were to say something like "exploit mobile specific methods for initiating web applications and interactions"
15:43:05 [DKA]
Exploit mobile-specifc methods for initiating Web applications and interaction
15:43:26 [francois]
... then that could be a BP, but having "use Push methods" isn't.
15:43:44 [DKA]
(e.g. SMS, QR codes, OMA Push, quantum entanglement, etc...)
15:44:19 [francois]
bryan: push is a technique that has a purpose.
15:45:30 [francois]
jo: I find it a little difficult that a content provider with a simple application would prefer to send tons of SMS just to reduce the amount of data exchanged on the network.
15:45:43 [francois]
dan: Can I suggest that we move forward with your suggestion?
15:45:57 [francois]
s/suggestion?/suggest, Jo?
15:46:53 [francois]
jo: I think it should replace 3.5.11
15:48:00 [DKA]
PROPOSED RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes as examples of mobile-specific methods.
15:48:35 [EdC]
Is it worth adding cell broadcasting to the list?
15:48:54 [DKA]
PROPOSED RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes and cell broadcast as examples of mobile-specific methods.
15:49:14 [JonathanJ]
s/specifc/specific/
15:50:08 [Jo]
OK we'll drop call and restart bridge
15:50:23 [Jo]
zakim, drop bryan
15:50:23 [Zakim]
Bryan_Sullivan is being disconnected
15:50:25 [Zakim]
-Bryan_Sullivan
15:50:38 [Jo]
zakim, drop Berners
15:50:38 [Zakim]
berners_lee_at_google is being disconnected
15:50:40 [Zakim]
Team_(bpwg)14:19Z has ended
15:50:41 [Zakim]
Attendees were Bryan_Sullivan, berners_lee_at_google
15:50:52 [Jo]
zakim, room for 4 for 120 minutes
15:50:52 [Zakim]
I don't understand 'room for 4 for 120 minutes', Jo
15:51:08 [Jo]
zakim, room for 4 for 120 minutes?
15:51:11 [Zakim]
ok, Jo; conference Team_(bpwg)15:51Z scheduled with code 26631 (CONF1) for 120 minutes until 1751Z; however, please note that capacity is now overbooked
15:51:23 [Zakim]
Team_(bpwg)15:51Z has now started
15:51:25 [Jo]
zakim, code?
15:51:25 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo
15:51:30 [Zakim]
+Bryan_Sullivan
15:51:52 [Zakim]
+berners_lee_at_google
15:52:14 [jeffs]
hello, conf bridge failing
15:52:35 [DKA]
PROPOSED RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes as examples of mobile-specific methods.
15:52:48 [Bryan]
+1
15:52:52 [adam]
+1
15:52:53 [DKA]
+1
15:52:59 [francois]
+1
15:53:05 [SeanP]
+1
15:53:06 [Zakim]
+??P7
15:53:20 [jeffs]
zakim, ??P7 is jeffs
15:53:20 [Zakim]
+jeffs; got it
15:53:21 [JonathanJ]
s/specifc/specific/
15:53:22 [Jo]
ACTION: Adam to use latest reference from Bryan when referencing OMA Push
15:53:22 [trackbot]
Created ACTION-921 - Use latest reference from Bryan when referencing OMA Push [on Adam Connors - due 2009-04-01].
15:53:24 [JonathanJ]
+1
15:53:30 [francois]
bryan: I'm ok with that new resolution. I did provide a better link on OMA push.
15:53:35 [rob]
+1
15:53:35 [jeffs]
back, got 4 more mninutes
15:53:45 [francois]
RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes as examples of mobile-specific methods.
15:54:06 [Kai]
http://www.it.rit.edu/~jxs/test/canvas/action910draft.html
15:54:13 [jeffs]
http://www.it.rit.edu/~jxs/test/canvas/action910draft.html
15:54:48 [francois]
jeffs: what I did was try to integrate Jo's feedback in my initial solution.
15:54:52 [jeffs]
3.5.12 Use Canvas Tag For Dynamic Graphics
15:55:05 [francois]
jo: first question is: is canvas sufficiently deployed to be considered a BP?
15:55:10 [francois]
jeffs: I think so.
15:56:07 [francois]
... I tried to get feedback from developers about when you should use what. When you should use canvas, SVG.
15:56:18 [francois]
... When you use SVG, content is available to the DOM.
15:56:23 [francois]
... When you use canvas, it's not.
15:57:31 [francois]
jo: sorry I mis-managed the time. We won't be here in two hours.
15:57:43 [francois]
... We could come back to the point tomorrow.
15:57:58 [Jo]
s/jo: sorry I mis-managed the time. We won't be here in two hours.//
15:58:26 [Jo]
s/.../jo:
15:58:49 [francois]
dan: just to be clear. It looks like you're recommending the use of canvas rather than SVG, is that right?
15:59:32 [francois]
jeffs: it's unlikely that developers are going to need elements that have been drawn for other purpose, yes.
16:00:06 [Zakim]
-jeffs
16:00:06 [francois]
jo: I think we're in danger of a declarative vs. procedural discussion here.
16:00:15 [francois]
... Let's come back to that tomorrow.
16:02:02 [francois]
francois: we may have a problem to have something such as "use canvas" in the spec, in the sense that it really creates a dependency with the HTML5 spec.
16:02:24 [francois]
kai: I think the main point is about implementations, and there are implementations of canvas already deployed.
16:03:02 [francois]
dan: I think it's not something that is coming, it's something that people are already using.
16:03:48 [francois]
kai: the question is, is it being using enough?
16:04:58 [francois]
dan: the tipping point for me was when I realized that an app deployed by a big company used client-side storage.
16:05:48 [francois]
... I think this is the whole point of having the icons.
16:06:40 [francois]
... When it comes to canvas, getting away from SVG vs. canvas, if it can be shown that there is good support for canvas, then let's do it.
16:07:49 [francois]
kai: I just wanted to make sure that we agreed on what we're doing in terms of putting HTML5 in the document.
16:08:26 [francois]
dan: on that particular discussion, let's sleep on it, we need to get back to that item tomorrow with jeff anyway.
16:08:36 [francois]
jo: OK, let's address Bryan's remaining points.
16:08:46 [francois]
jo: on 3.5.5.
16:09:13 [francois]
bryan: The next 3 should be pretty straight. I think examples would be useful.
16:09:51 [francois]
adam: I agree. Dan mentioned previously the possibility to have some kind of appendix with code examples, I think that would be useful.
16:10:23 [francois]
jo: I think this particular point would indeed be good in an appendix.
16:11:11 [Jo]
PROPOSED RESOLUTION: Ref Fragment ID and history - either include an example showing how this works, or find a suitable explanatory text that can be referenced in a non-normative way
16:11:17 [DKA]
+1
16:11:22 [Bryan]
+1
16:11:25 [rob]
+1
16:11:25 [JonathanJ]
+1
16:11:25 [Kai]
+1
16:11:26 [francois]
+1
16:11:27 [SeanP]
+1
16:11:36 [francois]
RESOLUTION: Ref Fragment ID and history - either include an example showing how this works, or find a suitable explanatory text that can be referenced in a non-normative way
16:13:04 [Jo]
ISSUE: Need example of use of Fragment ID and Brwoser History
16:13:04 [trackbot]
Created ISSUE-292 - Need example of use of Fragment ID and Brwoser History ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/292/edit .
16:13:30 [francois]
jo: Section 3.5.10
16:14:00 [francois]
[agreement on Bryan's comment]
16:14:15 [Jo]
RESOLUTION: Reword to clarify 3.5.10.2
16:14:58 [francois]
jo: Section 3.6.3
16:15:17 [francois]
... We already discussed that point this morning.
16:15:43 [Jo]
PROPOSED RESOLUTION: Under 3.6.3 Call out disabled Javascript as a specific use case for Class 1
16:15:45 [Jo]
+1
16:15:47 [adam]
+1
16:15:48 [francois]
+1
16:15:51 [DKA]
+1
16:15:52 [achuter]
+1
16:15:56 [francois]
RESOLUTION: Under 3.6.3 Call out disabled Javascript as a specific use case for Class 1
16:16:32 [Zakim]
-Bryan_Sullivan
16:16:33 [Zakim]
Team_(bpwg)15:51Z has ended
16:16:35 [Zakim]
Attendees were Bryan_Sullivan, berners_lee_at_google, jeffs
16:21:23 [francois]
RRSAgent, draft minutes
16:21:23 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois
16:34:22 [francois]
ScribeNick: achuter
16:34:23 [JonathanJ]
http://docs.google.com/Doc?id=dhpvgnmn_95cp98m3c4&hl=ko
16:34:46 [achuter]
Topic: Contributions from Jonathan Jeon
16:35:18 [achuter]
JJ: Desirble goals for MWABP
16:35:50 [achuter]
JJ: Propose add new subsection to section 2
16:38:03 [achuter]
JJ: Better security; Compatibility improvement; Improving User Experience; Maximizing Development productivity; Performance improvement; Resource saving
16:39:05 [achuter]
JJ: Add as appropriate these goals under each BP statment in section "Desirable goals of this statment".
16:40:04 [achuter]
JJ: For example, 3.1.1 Use Cookies for Simple Client-Side State: 3.1.1.3 Desirable Goal of this statement: [Improving User Experience], [Better security]
16:41:44 [achuter]
AC: Aren't some of these already captured in higher-level headings?
16:42:22 [achuter]
AC: Maybe better to review our headings.
16:42:42 [achuter]
DA: Tags are the modern way.
16:42:51 [achuter]
JJ: Headings not efficient.
16:43:14 [achuter]
DA: Could make a filtered list.
16:43:55 [achuter]
KS: Wouldn't detract
16:44:18 [achuter]
AC: Don't think it adds anything. Adds complexity.
16:45:46 [achuter]
DA: Positive about proposal as there are BPs that address multiple goals.
16:46:00 [achuter]
SP: Like tags for blogs.
16:46:51 [francois]
http://www.w3.org/WAI/WCAG20/quickref/
16:47:52 [achuter]
JR: Can we merge this idea with the categories for flip cards Dom proposed
16:48:16 [francois]
http://www.w3.org/2007/02/mwbp_flip_cards.html
16:50:18 [achuter]
DA: [compares categories for flip cards with those proposed by JJ]
16:50:50 [achuter]
JR: Needs to be orthogonal to existing structure.
16:51:45 [achuter]
JR: So far only one BP under "Security and privacy"
16:52:02 [achuter]
FD: BP about login forms was dropped at editorial meeting.
16:52:59 [francois]
-> http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 Discussion on login forms
16:53:30 [achuter]
JR: Needs to avoid repeating existing structure.
16:53:47 [achuter]
AC: Concerned that it would add more compexity.
16:54:04 [achuter]
KS: maybe JJ disagrees with existing headings.
16:54:16 [achuter]
JJ: No. But categories needed.
16:54:27 [achuter]
SP: Maybe remove all the headings and use tags.
16:55:07 [achuter]
KS: Yes, maybe remove headings and have all BPs one after another.
16:57:33 [achuter]
KS: As JJ says, many BPs fall into multiple categories. As AC says, having both could be confusing.
16:59:16 [achuter]
DA: Maybe call for review.
17:00:29 [achuter]
JR: Each person could have their own categorisation.
17:00:49 [achuter]
AC: Would also have capability tags.
17:01:24 [achuter]
KS: would only work with dynamic document.
17:02:27 [achuter]
JR: At minimum JJ's proposal shows that we have not sufficiently considered the classification.
17:02:56 [achuter]
JR: Also that it is a linear document and needs a hierarchical structure.
17:05:16 [achuter]
JR: Need to change the section headings.
17:06:56 [Jo]
ACTION: Jonathan to look at how the existing headings could be improved and to propose classiification groupings that are orthogonal (don't talk about the same things)
17:06:56 [trackbot]
Created ACTION-922 - Look at how the existing headings could be improved and to propose classiification groupings that are orthogonal (don't talk about the same things) [on Jonathan Jeon - due 2009-04-01].
17:07:36 [JonathanJ]
http://docs.google.com/Doc?id=dhpvgnmn_97hhvrdjhn
17:08:21 [achuter]
JJ: Proposal for Widget best Practices
17:09:48 [achuter]
JR: Make references to widgets already in document but no definitive document to refer to.
17:10:12 [Kai]
http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets
17:10:24 [achuter]
JR: There are types of widget that are in scope but others that are not.
17:10:36 [achuter]
DA: Only Web app widgets.
17:11:10 [achuter]
JR: Only HTML+CSS +JS otherwise not in scope. Don't want to broaden scope.
17:12:21 [achuter]
AC: We said that widgets of the type that are in scope are not sufficiently different to warrant special treament.
17:12:41 [achuter]
AC: Presently no widget-specific BPs.
17:14:54 [achuter]
JR: Not keen on seperate widget section. But JJ says new things not in the document at present.
17:16:06 [achuter]
JJ: Propose new references.
17:16:31 [achuter]
JJ: Propose newBP, "Keep the widget simple" purpose immediately apparent to user.
17:16:48 [achuter]
JJ: Propose new BP, "have a license agreement"
17:17:14 [achuter]
JR: True, but not mobile-specific.
17:17:56 [achuter]
JR: Principle is to keep to mobile-specific.
17:18:30 [achuter]
[Read JJ's proposed new BPs on screen]
17:19:57 [achuter]
AC: "Provide visual feedback" already covered.
17:20:29 [achuter]
JJ: "Use larger fonts, buttons and controls"
17:21:23 [achuter]
AC: Already have BP about this.
17:22:32 [achuter]
Rob: User can change font size
17:23:00 [achuter]
EC: Allow user to change font size.
17:23:15 [achuter]
JR: so covered in BP1 under FONT SIZE.
17:23:44 [achuter]
JR: Is issue about pixel density on mobile devices. Needs to be addressed somewhere.
17:27:16 [Jo]
ISSUE: Should there be a Best Practice noting that pixel density on mobile devices is typically greater than desktop? or is BP1 [MEASURES] sufficient?
17:27:16 [trackbot]
Created ISSUE-293 - Should there be a Best Practice noting that pixel density on mobile devices is typically greater than desktop? or is BP1 [MEASURES] sufficient? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/293/edit .
17:27:49 [achuter]
s/FONT SIZE/[MEASURES]
17:29:27 [achuter]
JR: Consider again "Widget's purpose should be immediately apparent to user"
17:31:07 [achuter]
JR: Can't really make a BP about it. Can't make it simple enough.
17:31:35 [achuter]
SP: Sometimes want multipurpose widget-
17:34:55 [achuter]
JR: All agree with the intention but is not possible to make a BP from it.
17:35:26 [JonathanJ]
http://docs.google.com/Doc?id=dhpvgnmn_98dqm2nddc
17:36:51 [achuter]
JJ: Propose BP "Periodically update heartbeat mesages"
17:37:08 [achuter]
AC: Valid design pattern, but not mobile-specific.
17:39:50 [achuter]
JR: Hpw does it work with "Back off during periods of inactivity"?
17:40:55 [achuter]
AC: Prefer separate BP.
17:41:05 [achuter]
s/Hpw/How
17:41:58 [Jo]
PROPOSED RESOLUTION: Add a note 3.4.4 ref heartbeats and that some applications require presence notification
17:42:06 [francois]
+1
17:42:07 [rob]
+1
17:42:08 [SeanP]
+1
17:42:09 [Jo]
+1
17:42:09 [adam]
+1
17:42:13 [JonathanJ]
+1
17:42:18 [Kai]
+1
17:42:32 [achuter]
RESOLUTION: Add a note 3.4.4 ref heartbeats and that some applications require presence notification
17:44:25 [achuter]
JJ: Not only fragment IDs, can use any URI.
17:44:44 [achuter]
AC: IDs work with Ajax within application.
17:45:06 [achuter]
AC: Make URIs RESTful.
17:46:15 [achuter]
FD: How do you update history with script?
17:46:58 [achuter]
AC: using document.location. Changes hsigtory without causing browser to reload page.
17:47:14 [francois]
s/hsigtory/history
17:47:47 [achuter]
JJ: Not same point. Is about providing unique URIs. Each application state should have unique URI.
17:49:53 [achuter]
JR: Already covered by exisitng BPs.
17:50:07 [francois]
-> http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 Login form's discussion
17:50:12 [achuter]
Topic: Login forms BP
17:50:50 [achuter]
FD: Do we agree that the login forms BP should be restored?
17:52:39 [Jo]
ACTION: Adam to review discussion on login forms and resolutions threreto and reinstate text appropriately
17:52:39 [trackbot]
Created ACTION-923 - Review discussion on login forms and resolutions threreto and reinstate text appropriately [on Adam Connors - due 2009-04-01].
17:53:00 [achuter]
[close of meeting]
17:53:08 [Jo]
[meeting adjourned at 1750]
17:53:19 [francois]
RRSAgent, draft minutes
17:53:19 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois
17:59:24 [rob]
rob has left #bpwg
18:00:03 [JonathanJ]
JonathanJ has joined #bpwg
18:20:21 [Zakim]
Zakim has left #bpwg
19:44:29 [seungyun]
seungyun has joined #bpwg
19:44:35 [seungyun]
seungyun has left #bpwg