06:34:18 RRSAgent has joined #bpwg 06:34:18 logging to http://www.w3.org/2008/06/17-bpwg-irc 06:34:20 RRSAgent, make logs public 06:34:22 Zakim, this will be BPWG 06:34:22 I do not see a conference matching that name scheduled within the next hour, trackbot 06:34:23 Meeting: Mobile Web Best Practices Working Group Teleconference 06:34:23 Date: 17 June 2008 06:34:44 Chair: Dan, Jo 06:34:53 DKA has joined #bpwg 06:42:37 achuter has joined #bpwg 06:46:12 Kai has joined #bpwg 06:50:58 jo has joined #bpwg 06:52:42 manrique has joined #bpwg 06:55:07 abel has joined #bpwg 06:59:31 francois has joined #bpwg 06:59:46 zakcohen has joined #bpwg 06:59:47 RRSAgent, draft minutes 06:59:47 I have made the request to generate http://www.w3.org/2008/06/17-bpwg-minutes.html francois 07:00:05 ScribeNick: DKA 07:00:09 Scribe: Dan 07:00:11 Present: Ed, Jo, Adam, Zack, DKA, Kai, Seungyun, Jonathan, SeanP, Dom, Francois, Scott, Rob, Abel, Miguel, Manrique 07:00:21 Sunghan has joined #bpwg 07:00:24 edm has joined #bpwg 07:01:07 Agenda: http://docs.google.com/Doc?id=dd3jk8v_114tkbg6kgj 07:01:21 JonathanJ has joined #bpwg 07:01:29 s/Seu/Su/ 07:01:30 Jo: Today we have scheduled a full day of BP2. Summary of yesterday: we made good progress on CT. 07:01:31 -> http://docs.google.com/Doc?docid=dd3jk8v_114tkbg6kgj&hl=en_GB Agenda 07:01:39 s/gyu/gha/ 07:01:48 Jo: Having spent an extra half-day on that, we need to reschedule the things we didn't do - MobileOK topics. 07:02:03 Jo: We can try to fit that in tomorrow but it may mean running into the afternoon. 07:02:40 Jo: Also tomorrow, we have a review of the accessibility document; we need to figure out how the checker is going; we need a report from the Korean task force; a report would be great. 07:03:02 SeanP has joined #bpwg 07:03:10 Abel: We rescheduled the MobileOK item - but we are leaving in the afternoon tomorrow. 07:03:25 Jo: We can move the agenda around to accomodate that. 07:03:31 rob has joined #bpwg 07:04:01 Jo: Adam as co-editor for BP2 has prepared some comments. 07:04:14 Jo: Also a Vodafone submission. 07:04:27 Jo: We will start with a document review and scope discussion. 07:05:39 adam has joined #bpwg 07:05:47 http://docs.google.com/Doc?docid=dft77cn8_17dkz5wp8h&hl=en 07:05:54 Adam: I've made notes on many of the BPs. Many of them are good but we need to reword parts of them. Rather than wordsmithing here we should get a feeling for intent. 07:06:31 adam: top of the doc is scope 07:06:55 adam: then section 2, which used to be the requirements section. Bryan took the content from that and absorbed into BPs. Do we want to now remove that section? 07:07:11 adam: I've highlighted the ones that I feel need most attention. 07:07:25 adam: there's a few more BPs we can add. We should go through those. 07:07:28 adam: scope? 07:07:34 Jo: yes. 07:08:36 [I think 4.11 (Applicability to Non-Browser Web Runtime Environment) should probably be moved to scope, 1.4.2 ("Web application")] 07:08:45 adam: I've took the original scope, pasted in Jo's comments and removed wording on widgets. We need to flesh out the mobile context bit and describe what's unique about the mobile context. 07:09:02 q? 07:09:26 kai: in reading the document, it's focused on web applications - how does it tie together? I felt a disconnect with the static properties of mobile content. Discuss! 07:09:43 jo: are you saying it's missing bits on static content that are missing in bp1? 07:10:07 kai: yes - I was thinking there would be some more expansion on the topics in bp1 07:10:18 scott: I agree. Some of my input is in this area. 07:10:27 kai: I don't have any specific inputs in this area. 07:11:11 adam: It feels like a very big doc to me so I agree we should add some more but also we need to cut out items. 07:11:29 jo: we need to categorize comments under the headings of missing, wrong, extra, typographic and unclear. 07:11:43 kai: we need to have references to bp1 - a stronger linkage. 07:12:05 jo: what is missing is a stronger tie-in to bp1 - needs to be higher level than bp1 but lower level than "applications." 07:12:10 kai: yes 07:12:47 jo: i think there are things missing from bp1 like the one I suggested yesterday. For example, we don't say that it's a bp for hosts to offer a choice of presentation where they have one. Would you say that's a candidate for bp2? 07:12:51 kai: potentially. 07:14:02 jo: I have in mind a mental model of how these documents fit together [goes to white board]. 07:14:33 jo: BP1 is a foundation document, on which is built MobileOK basic, on which is built MobileOK pro. 07:15:38 jo: now we are creating a new foundation document - bp2. In this model, all the documents should refer to bp1 as the foudnation. 07:16:09 kai: the tests document show you adhere to the best practices. with bp2 there is a gap. 07:16:31 jo: if so, then the answer is to fill that chasm in and increase the linkage back to bp1. 07:17:34 adam: yes - I'd like to see that expressed in concrete best practices. 07:17:48 Scott has joined #bpwg 07:17:56 jo: to return to the discussion of scope - 07:18:21 adam: there are 3 sides to the scope - what's bp, what's a web app and what's the mobile context? Preface that with some intro wording. 07:18:58 adam: some requests to add more material to the mobile context have come in. 07:19:07 adam: I'm happy with it in its current state. 07:19:21 adam: signifigant concerns? 07:19:38 jo: I've made the point that I don't think think that "great web applications" is meaningful. 07:20:19 adam: I like it - I found it grounding - I think it's been dropped out of the scope. 07:20:43 DKA: I like it because it speaks to web developers. 07:21:13 Jo: is it possible to be percise and also populist? Would it be better to make it percise and then make it populist? 07:21:18 adam: It needs to be useful. 07:21:24 s/per/pre 07:21:24 s/per/pre 07:21:34 Jo: To be useful it has to be correct. To be correct it has to be percise. 07:22:11 Dom: I think the question is a good one. I'm not sure there's a direct correlation between this issue and whether the phrase "great web applications" should be in the document. 07:23:00 Jo: If you advertise in the scope that it's about great web applications then you . I think we should remove it and then make a pass at the end. 07:23:42 Jo: I think it's about ineroperability at its heart. 07:23:47 q+ to suggest 4.11 be integrated in scope 1.4.2 07:24:09 Ed: I regarding the audience should we be more percise, saying that this is for web developers as opposed to programmers? 07:24:11 q? 07:24:32 Ed: are we talking about markup technologies primarily? 07:24:41 Jo: under 1.3 what would need to change there? 07:25:36 q+ to say that since BP 2 is supposed to be a specification it should be precise. We should avoid marketing speech. 07:26:04 Ed: People who build java applications I consider to be programmers, people who do markup are web developers [in my view]. 07:26:16 DKA: It's all a sliding scale. 07:26:26 Jo: in what respect should this text change to reflect that sentiment? 07:26:53 Ed: the last sentence - can we make it positive... 07:27:24 Ed: Please add "Web developers" 07:27:30 adam: I'm happy with that. 07:28:00 ack d 07:28:00 dom, you wanted to suggest 4.11 be integrated in scope 1.4.2 07:28:37 Dom: currently applicability to web-runtimes is in 4.11. I think it should be in the scope of 1.4.2. 07:28:44 q+ 07:28:46 adam: I agree. 07:28:53 q? 07:29:00 ack Kai 07:29:00 Kai, you wanted to say that since BP 2 is supposed to be a specification it should be precise. We should avoid marketing speech. 07:29:01 ack ki 07:29:37 kai: I wanted to get back to wording - since it's intended to be a specification it should be percise. Specifications don't have any room for marketing-type-speech. 07:30:12 Jo: We have 2 competing objectives - one is to make it accessibile as possible, the other is to make it tight and correct. 07:30:32 Kai: I think "great web applications" have no meaning. 07:30:50 s/accessibile/accessible/ 07:30:52 Jo: How about "web applications" rather than "great web applications" 07:31:14 Kai has joined #bpwg 07:31:27 ack me 07:31:55 q? 07:31:57 ack ach 07:32:00 DKA: I think having prose-type text at the beginning of a document does not take away from percise text later in the document. 07:32:35 Alan: I agree with Kai that "great" isn't an appropriate term to use in this document - but might be better in an outreach document. Also "Web 2.0" is ill-defined. 07:32:56 Kai: I agree. 07:32:59 DKA: I agree. 07:33:28 Jo: rather than trying to define "Web 2.0" perhaps someone would like to take an action to propose text for that section. 07:33:34 Kai: "Interactive web technologies" 07:36:02 ACTION: Dan to come up with alternative phrasing for Web 2.0 07:36:03 Created ACTION-783 - Come up with alternative phrasing for Web 2.0 [on Daniel Appelquist - due 2008-06-24]. 07:38:49 DKA has joined #bpwg 07:39:31 http://docs.google.com/Doc?docid=dd3jk8v_116pb2r6cfw&hl=en 07:39:37 [reviewing Vodafone submission] 07:40:22 scott: two main areas are user interface and performance - mainly around using client side scripting. 07:40:48 scott: there may be some overlap [with the current doc] 07:40:58 jo: Ok - this looks "great" 07:41:15 jo: it looks like it's fairly easy to weave into the structure of the document. 07:41:41 scott: some bits at the end not sure where they fit - such as network. 07:42:14 adam: as we fix in the existing BPs these should slot in nicely. Some references to minimizing network access. We need to tighten up how that's presented and worded. 07:42:19 jo: back to a line by line review. 07:42:41 adam: this document is 9000 words long 07:43:02 adam: 1.4.4 and 1.4.5 - now obsolete. Are there bits we need to preserve or can we delete them? 07:43:22 q? 07:44:10 [some discussion on wording of this section] 07:44:28 jo: should there be an expression of what the document is not? 07:44:58 jo: as far as I'm concerned that's "great" 07:45:22 adam: section 2- this contains all the text now absorbed into section 4. 07:45:39 adam: propose to remove section 2. 07:45:59 jo: I wasn't happy but I can see the rationale and the consensus view is to remove it so let's move on 07:46:17 q+ to say something on legal issues of personalization 07:46:33 Topic: 4.1 - personalization 07:46:35 ack k 07:46:35 Kai, you wanted to say something on legal issues of personalization 07:47:19 kai: some of the text encourages using automated means to collect usage patterns but in Germany this can be illegal. So some of the stuff we're saying needs to be looked at because it might be illegal. 07:47:41 adam: the intent is to say if you have a relationship with the operator you can... 07:48:03 kai: it needs a careful read-through with this point in mind. 07:48:39 jo: we touched on this - should we be seen to be encouraging illegal behavior. 07:48:47 jo: but not sure what to do to the document... 07:49:06 kai: there's a difference between permission data and automated data - that's one area where we have to be careful. 07:49:18 adam: is it safer just to talk about sign-on? 07:49:18 q+ 07:50:00 adam: there's manual signon and automated signon... so rather than personalization talk about sign-on? 07:50:01 kai: I can take an action... 07:50:24 ACTION: Kai to review 4.1 Personalization with privacy regulations in mind 07:50:24 Created ACTION-784 - Review 4.1 Personalization with privacy regulations in mind [on Kai Scheppe - due 2008-06-24]. 07:50:34 ack DKA 07:51:10 DKA: do we need specific wording about privacy and legal implications (e.g. european data protection, etc...) 07:51:20 Jo: that could be a slippery slope.... 07:52:51 ACTION: Kai to check the personalization section for specific parts that seem to imply combination of personal information with usage patterns 07:52:51 Created ACTION-785 - Check the personalization section for specific parts that seem to imply combination of personal information with usage patterns [on Kai Scheppe - due 2008-06-24]. 07:53:22 Ed: to be very generic - legality is important. Something like "privacy regulations and legal constraints." 07:53:22 adam: on the back of this conversation - should we focus on login instead of personalization? 07:53:49 adam: "use automated means for obtaining personalization information" seems inflamatory. 07:54:13 kai: the current phrasing [could be construed] as encouraging illegal behavior. 07:54:19 jo: add a note that it needs to be clarified. 07:55:45 ACTION-784: dup of ACTION-785 07:55:45 ACTION-784 Review 4.1 Personalization with privacy regulations in mind notes added 07:55:50 close ACTION-784 07:55:50 ACTION-784 Review 4.1 Personalization with privacy regulations in mind closed 07:56:33 adam: I suggest removing yexy "in the pc environment...is acquired" in para 1 of 4.1. Doesn't add value - document will be more accessibile if it's more percise. 07:56:50 jo: suggests "personalization often increases user value." 07:58:26 jo: [digressing] we have in a number of occations tripped across the differences between "mobile ISPs" and traditional ISPs. Some of the things we would like to advocate as best practices are not obvious to the uninitiated. 07:59:15 jo: for the exampe of push - it's a good idea, but in order to do that you must have a relationship with a "push provider" of some kind or you can't do it - so other elements need to exist besices a clear internet connection between the device and the origin server. 08:00:12 jo: so we need to note that there are things you need to know about the ecosystem that you may not know. 08:01:09 adam: we cover the case where you have a relationship with a service provider of some kind first and then where you don't - should we reverse this order? 08:01:31 jo: yes and then we can have some additional wording on who can act as a service provider [eg aggregators] 08:02:16 ACTION: Jo to draft wording for an appendix that identifies the aggregators and operator roles that are different in the mobile ecosystem. 08:02:16 Created ACTION-786 - Draft wording for an appendix that identifies the aggregators and operator roles that are different in the mobile ecosystem. [on Jo Rabin - due 2008-06-24]. 08:03:00 adam: suggest cutting out text on "other user information..." 08:03:14 + 08:03:16 q+ 08:03:27 q? 08:03:58 ack a 08:04:23 alan: occurs to me that personal information might include accesability preferences. 08:04:47 adam: i'm proposing removing the enumeration all-together. 08:04:49 alan: ok 08:05:32 dom: comment on editorial process question - this is a good process today but in the normal process we don't have to go through all your proposed changes. 08:06:13 ScribeNick: Kai 08:07:54 adam: [explaining his reasoning for a comment on cookies] 08:08:16 ...that hidden information is not retained across sessions 08:08:27 ...need to remove the cookie part 08:09:00 ...as for security don't store personal infomation in cookies and adjust security to what is necessary 08:09:22 ....4.2.1...is the wording ok? 08:09:36 ...what is the intent of this BP? 08:10:01 jo: not sure if this is particular mobile specific 08:10:12 adam: not sure 08:10:33 dom: this may be interesting for web developers in this context 08:10:44 jo: i am not sure that using secure hashes is a BP 08:11:09 adam: should we remove this section? 08:11:31 is there a document we can refer to, since it is not specifically mobile? 08:11:40 jo: what do the present think? 08:11:54 ...is this sufficiently mobile? 08:12:45 dom: if you only develop apps for the pc then this may pose different challenges since it is a mobile environment 08:13:10 ...recommending not use HTTPS is certainly not a good practice, but you have to take the mobile context into account 08:13:24 jo: should we say do not use HTTPS unnecessarily? 08:13:48 ...if we were to say use a secure hash somebody might ask what is that exactly? 08:14:20 francois: you want to just say use https if you have secure information? 08:14:36 SeanP: isn't it the same on the PC? 08:14:41 jo: but it is in scope 08:15:04 ...there are certainly harmful effects in a mobile environment 08:15:14 SeanP: but don't overuse it, right? 08:15:41 adam: so we should change this from protecting personal information to balance the measures chosen? 08:16:04 manrique has joined #bpwg 08:16:31 jo: can you come up with seomthing? 08:16:42 dka: can we have explicit examples? 08:17:04 ....instead of leaving it open, give specific alternatives 08:17:26 ...we should not say these are the MOST secure alogrithms or somethign like that 08:17:42 adam: I agree. We would then have to worry about that too. 08:18:12 edm: rather than just say "use HTTPS 08:18:30 ....use "performance implications of using HTTPS" 08:18:49 adam: 4.3 08:19:57 Inform user about personal information? how and what? 08:20:25 adam: [explainin this proposed changes] 08:20:39 ...perhaps the BP is good and we need to reword it a bit 08:21:57 ....informing the user means there are some browsers that show personal information, such as contacts etc. 08:22:09 ...you should allow users to opt out 08:22:51 ....I think we need to come up with a coherent view of what this sections means and says 08:23:25 dom: maybe this should have a caveat if the device does not allow the opt out the app should do so 08:23:42 adam: the app may not know if a dialog has popped up (?) 08:23:58 dka: the implementation are not out there yet 08:24:18 ...access to the address book from the scripting layer would surely prompt the user 08:24:45 jo: we should something to catch poor app design 08:25:00 ..harmonzing access with underlying systems 08:25:29 dom: if you get this prompt but don't the app will get access to your addressbook you will be surprized 08:26:20 adam: make the request for personal information an active choice? 08:26:24 dom: yes. 08:26:25 q+ 08:26:45 ....we need to keep the user aware of what might trigger access to personal information 08:27:35 jo: prior to running the app for the first time it should inform the user about all the information it will access 08:28:02 adam: CP may not necessarily want to do that 08:28:15 jo: it can be done in a number of ways 08:28:24 ack ed 08:28:38 edm: i think it would be good have statement of balancing security with sensitivity 08:28:59 ....context does matter a lot, but taking advantage of that context is a trade off 08:29:37 ....user experience may improve but there is a price to pay 08:29:48 ...don't ask for everything if you make do with less 08:30:47 ...should we recommend DCCI or so? 08:31:00 jo: I think we have had problems with this before and would say no 08:31:14 dom: I think we can't say it is a BP 08:31:40 ...there will be a geolocation API and if this work is going ahead fast enough, it might become interesting 08:32:03 jo: at the end of this section we will take a break 08:33:34 jo: 4.3.4 - Bran is keen on redirection 08:33:48 break for 20 min 08:36:24 RRSAgent, draft minutes 08:36:24 I have made the request to generate http://www.w3.org/2008/06/17-bpwg-minutes.html dom 08:49:33 manrique has joined #bpwg 08:51:26 s/Bran/Brian/ 08:51:26 We're baaack 08:51:41 adam: provide control for app behavior 08:52:23 manrique has joined #bpwg 08:52:49 ...use of cookies and redirection 08:53:29 ...this might be a bit turned around. Should be robust against loss of cookie information 08:53:32 +1 08:54:07 jo: the amount in infos should be minimized is the focus here 08:54:17 ....use only the user id key 08:54:28 adam: minimize redirects 08:54:30 q+ to wonder out-loud on whether there should be a bp on use of client-side database? 08:55:28 ...use landing pages 08:55:44 Kai: actually landing pages tend to annoy users 08:55:58 jo: we don't want to interrupt user flow 08:56:14 ...we need to balance the two 08:56:46 ack d 08:56:46 DKA, you wanted to wonder out-loud on whether there should be a bp on use of client-side database? 08:57:05 dka: there are at least two implementation of client side databases 08:57:37 ...would it be useful to write something about this in this document? 08:57:58 jo: so to minimize client side storage is not a BP? 08:58:20 dka: in the mobile context you probably don't want to store lots of information 08:58:32 jo: so the amount of information is important 08:58:46 ...the amount of offline operation needs to take into account 08:58:56 s/to take/to be taken 08:59:25 ...and multi channel access services 08:59:56 ...speed of access is important 09:00:12 adam: where does this fit in? 09:00:28 jo: control of the app is really the point taking this into account 09:01:03 adam: does this fit into this section on cookies and redirects? 09:01:05 jo: no 09:02:41 Kai: what about redirects, latency etc. Is that still timely for this document? 09:02:55 jo: we need to get to this, but let's finish this first 09:03:53 adam: so which BPs do we need? 09:04:09 jo: I think we need a how to do it 09:04:31 ...also need to add the thing on size of client side storage 09:04:52 adam: move redirects to use of resources 09:07:53 Kai: we should not focus too much on redirects, latency and realted issues 09:08:06 jo: Bryan has a similar stance 09:08:34 ...I am not sure how much more we are saying here that hasn't been said in BP1 already 09:08:52 adam: we should mention it, but it doesn't really add much 09:09:29 q? 09:09:51 jo: we should have a coherent policy on when to mention BP1 09:10:40 dka: we had said earlier we need a stronger linkage between BP1 and BP2. Here we can do that. would help to clear up that BP1 is not encouraging lowest common denominator 09:10:56 jo: so where possible we should make reference to BP1 09:11:16 ...we could have a preamble "refer also to..." 09:11:45 adam: web applications increase demands for redirects for authentication? 09:11:55 jo: I am not sure "need" is the right 09:12:53 Kai: sometimes redirects really are overdone but they do have an important role to play 09:13:45 ...is there are web app specific part that we could mention? 09:13:54 adam: well the authentication part may be one 09:14:30 jo: so let's ref BP1 on redirection as preamble for 4.5 09:15:19 dom: there is no real BP that says minimize server redirection 09:15:33 jo: so yes, then we should call out the fine points 09:17:04 ...but we perhaps should not mention specific numbers on redirects 09:17:21 Scribe: Sean 09:17:28 Scribenick:Sean 09:17:38 Jo: on to 4.5 09:18:02 Adam: Transfer compression makes sense 09:18:20 ...not sure what we want to recommend for app level compression 09:18:52 Kai: Everyone thinks that compression will speed things up; when you go to binary on a fast network it sometimes slows things down. 09:19:10 ...not sure if this is always true in mobile environment 09:19:29 DAK: Makes Vodafone joke 09:19:37 s/DAK/DKA/ 09:20:08 Rob: Use text-based compression 09:20:46 Jo: How can we capture point of efficiency gain of compression vs. loss of battery life, etc. 09:21:21 Kai: restrict to text based compression 09:22:33 Dom: Don't compress 1k files and be careful with other bad compression techniques; is there a way we can get data on this? 09:23:34 ...If you are going to send 1M of a text file, it should be compressed. 09:23:46 ...Where is the line? 09:24:15 Adam: Could publish a table with thresholds of data sizes to compress. 09:24:28 Kai: Can show a table of compression data. 09:26:03 Jo: 4 dimensions of compression: 1. type of network, 2. type of processor, 3. size of data to be transferred, 4. likely benefits of carrying out compression/decompression 09:26:42 Rob: In practice you tell it what mime types to compress 09:27:18 Kai: [Puts up a table about compression on the screen] 09:28:50 Kai: [Describing table] Many times don't see much benefit from compression of binary content on ISDN and broadband 09:29:40 ...Compression makes a big difference however on text based content 09:30:27 Adam: Simple message: compression of text is good, compression of binary data is bad 09:31:21 Kai: [another spreadsheet is projected] [Shows a case where compression has a negative effect] 09:32:07 ..A lot of variation in benefits of compression for different files 09:32:58 Rob: Given normal developer tools, it is difficult to configure to compress different size files 09:33:31 Scott: After doing all of the BP1 stuff like removing whitespace, etc, the impact of compression may not be that much. 09:33:50 Adam: Javascript compresses well. 09:35:53 Adam: Can change the compression BP by: a vague mention of being careful with compression, mention binary files or text files, or do some work to find out which files should be compressed or not 09:36:24 Kai: Obfuscating JavaScript makes the files smaller 09:36:45 Adam: yes, should we call it tokenizing? 09:37:51 [An ajaxian article referring to the lack of benchmark on the topic http://ajaxian.com/archives/compression-caching-for-faster-load-times] 09:38:24 Jo: Open question: Do some work to find out what files and sizes are best to compress. 09:38:37 [another related article: http://clientside.cnet.com/best-practices/optimization/dean-edwards-packer-compression-tool/ ] 09:38:52 Adam: There is a section on app compression which I thought we should remove. 09:39:28 ...I think it is covered elsewhere. 09:39:49 Jo: Can we put something in about preprocessing JavaScript? 09:40:26 DKA: There is a mention of EXI; I think this is out of scope for this document. 09:40:55 +1 09:40:58 Jo: EXI is not a done deal; we usually don't refer to things that aren't done deals. Also WAP is out of scope. 09:41:22 q? 09:41:31 Kai: Shouldn't we refer to asynchronous methods to reduce transport? 09:41:46 Adam: I agree; we should refer to that. 09:42:01 Jo: Should it be in this section or another section? 09:42:10 Kai: Maybe in another section. 09:42:54 Jo: Moving to "Minimize Automatically Issued Network Requests" 09:43:22 [an apparently very relevant IEEE paper on compression: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/7513/20446/00945195.pdf?arnumber=945195 "In this paper, we define the total delay as the time for both the transfer and the decompression of a compressed file. To minimize the total delay, a mobile program should be compressed in the best format for minimizing the delay. Since both the transfer time and the decompression time are dependent upon the current un 09:43:22 derlying resource performance, selection of the "best" format varies and no one compression format minimizes the total delay for all resource performance characteristics. We present a system called Dynamic Compression Format Selection (DCFS) for the automatic and dynamic selection of competitive compression formats based on the predicted values of future resource performance. Our results show that DCFS reduces the total delay imposed by the compressed transfer of Jav 09:43:25 Adam: 2 main points: Batch requests together and Back off during periods of inactivity 09:43:27 a archives (.jar files) by 52% on average for the networks, compression techniques and benchmarks studied"] 09:44:03 ...Make these two things the focus of this section. 09:44:11 Dom: How do you do this? 09:45:53 Adam: Combine your XHR requests; configure your server to be in chunked mode so that you are not making continuous XHR requests--not sure if this is actually better however 09:46:12 Kai: Would sections like this benefit from listing bad examples? 09:47:37 ...If we can't come up with concrete problems that we are trying to solve, maybe we don't actually have a good BP. 09:47:57 Jo: A good idea, but verges on the idea of techniques. 09:48:37 DKA: Actually different than techniques; with techniques we would come up with a Wiki and the community would come in and add content... 09:49:28 ...Come up with example applications--this would be a new work item however. 09:49:54 Kai: If you show a good way and a bad way to do things, you can see the difference. 09:50:15 Adam: From the view of developer, the good way would be more useful. 09:50:46 Jo: Back to "Minimize Automatically Issued Network Requests" 09:50:56 Jo: Is there anything to say about roaming here? 09:51:05 Adam: No way to tell if you are roaming. 09:51:45 ...Good reason to give users more control 09:52:25 Scott: Are we talking about a low bandwidth version and a high bandwidth version? 09:52:38 Adam: Do we want to make a BP for this? 09:52:47 Jo: I think we should do this. 09:52:58 DKA: Refer to BP1. 09:54:09 DKA: Example of Twitter: m.twitter.com is a really stripped down version of Twitter; the iPhone version of Twitter is a much richer user experience. 09:54:14 ...I use both of them. 09:54:41 Adam: If it makes sense to your app, provide a low bandwidth version. 09:55:33 Jo: We're going off on a tangent...we're talking about automatic network requests. 09:55:56 ...I think we want to say offer a low bandwidth version if you can. 09:56:24 ...some apps may not be able to offer a low bandwith version. 09:56:38 Adam: Should be able to switch network off if possible. 09:57:14 Kai: Is this low bandwidth stuff really relevant for this document--we're not really talking about saving money. 09:57:36 ...it's about a comfortable application; sometime you have to spend more money. 09:57:51 Jo: We're talking about value--an app shouldn 09:58:09 shouldn't use bandwidth unnecessarily. 09:58:52 s/app shouldn/app/ 09:59:22 Adam: Moving to "Push Methods" 09:59:33 Jo: generated a lot of discussion on list 09:59:56 Adam: Reference to MIDP seems out of scope; but I like the idea of the BP. 10:00:03 q? 10:00:39 Jo: What we lack standardized or commonly accessible PUSH methods. Hard to recommend a specific Push method. 10:00:56 s/PUSH/push/ 10:01:14 DKA: What about WAP push? Is it the same as OMA push? 10:01:23 Adam: I think they are the same? 10:01:46 Rob: That is the problem. Where does a developer go to find out about this stuff? 10:01:52 -> http://www.openmobilealliance.org/technical/release_program/push_v2_2.aspx OMA Push specs 10:02:17 -> http://en.wikipedia.org/wiki/Wireless_Application_Protocol#WAP_Push WAP Push in wikipedia 10:02:47 Jo: This is where mobile is different from classic Web..some things are no longer bilateral. Push is an example where you have to through a mediator. 10:03:21 ...since mediation is required with Push, it requires extra administrative actions. 10:04:00 Adam: We have some examples; we should remove the part about MIDP. 10:04:20 Jo: Should we remove "vendor-specific mechanisms"? Is that too opaque? 10:04:54 Jo: How is WAP push different from a text message? 10:06:06 DKA: WAP push sends a special SMS. Hasn't been popular because the user experience differs greatly across handsets. 10:06:25 Rob: Yes, the user experience varies. 10:06:48 Jo: Is it worth capturing this point about the user experience varying? 10:07:08 Ed: Are people still using it? 10:07:23 Rob: Old spec, but people still do use it. 10:07:48 Adam: On to Minimize Application Size 10:08:15 ...There is a long part with examples that should be removed. 10:08:21 http://www.w3.org/TR/mobile-bp/#MINIMIZE 10:08:36 ...Should we just focus on tokenizing scripts? 10:11:43 Jo: There are ways to increase CSS speed by using selectors in a different way; use selectors that match the semantic shape of the document instead of class names. 10:12:07 ...the CSS suggestion was by Martin. 10:12:31 ...disadvantage is that the stylesheets cannot be shared easily between documents. 10:12:56 Adam: Suggestion is to remove the stuff about CSS selectors and make this BP about tokenization of scripts. 10:13:30 Jo: Maybe we put something in that is more bland about using CSS selectors, but not include the detailed example. 10:14:17 http://my.opera.com/Andrew%20Gregory/blog/ 10:14:20 Time for lunch; back at 1:15. 11:35:41 zakcohen has joined #bpwg 11:40:21 edm has joined #bpwg 11:40:36 adam has joined #bpwg 11:40:42 http://docs.google.com/Doc?id=dft77cn8_17dkz5wp8h 11:41:26 scribe: edm 11:41:48 scribenick: edm 11:42:46 Present+ Adam 11:43:45 Of interest: http://www.moconews.net/entry/419-bank-of-america-says-it-has-1-million-mobile-users-details-other-mobile/ 11:43:56 edm2z has joined #bpwg 11:44:12 scribe: edm 11:44:23 scribenick: edm2z 11:46:31 adam: back to 4.5.5 Minimize DOM Manipulation 11:47:05 Is there some way people can measure if they are doing this efficiently? 11:47:42 Scott: parsing the javascript to initializa the doc slows things down... 11:48:36 Jo: parctice should be about limiting DOM manipulation required before initialization of the page 11:48:45 s/parctice/practice/ 11:49:22 jo: limit dynamic/scripting portions where possible 11:49:38 s/jo:/Jo:/ 11:50:34 adam: we have not measured the cost of dynamic vs. static - need benchmarks 11:52:08 adam: may also need new BP to minimize network requests 11:52:37 dka: in general this makes sense 11:53:41 adam: e.g., do not require additional request for JSON packet... 11:54:16 jo: should we discuss progressive rendering - page rendered as streams? 11:55:43 jo: all points discussed are really about snappier user experiences 11:56:24 Jo: e.g., contacts as JSON rather than fully-rendered HTML 11:57:23 Scott: this is about more general presentation issues - not just DOM manipulation 11:58:45 Kai_ has joined #bpwg 11:58:50 Kai has joined #bpwg 12:00:07 DKA: need to provide immediate feedback and keep user aware of what is going on - e.g., animation for loading in case of delays 12:01:03 adam: e.g., notification thta your app is coming down ... 12:01:43 Jo: is there anyting in particular to preserve re efficient DOM manipulation? 12:02:12 dka: who would do some testing? 12:02:45 q? 12:03:07 dka: if presentation related BPs cover this, we could drop this for now. 12:03:53 adam: 4.5.6 Minimize External Script Files 12:04:19 adam: ...could be absorbed into other sections... 12:04:51 adam: ...e.g., minimize network requests 12:06:41 adam: topic of minimizing external script files would benefit from some benchmarking data 12:07:48 adam: deferred binding of device specific bits seems to be a good idea 12:08:49 Kai: re 4.5.6.2 - question on diminishing efficiency of caching? 12:10:39 adam: need to discuss the benefits of deferred binding vs. pre-loading 12:12:11 jo: points out the difference between static pages vs. dynamic applications - re value of caching 12:13:04 adam: 4.5.7 Use Power-Efficient Methods 12:13:43 adam: ... need some benchmarking data - to show specific cost 12:14:39 Scott: no specific data to offer on this yet 12:15:58 adam: valid point in general - but there are other power efficiency issues other than usage 12:16:01 Jo: 12:17:50 Jo: leave this as a placeholder for now - need more details and specific examples of power efficient techniques 12:18:39 Jo: perhpas somebody should draft some specific text for the placeholder 12:19:20 ACTION: Scott to draft text re power efficiency by June 25 12:19:21 Created ACTION-787 - Draft text re power efficiency by June 25 [on Scott Hughes - due 2008-06-24]. 12:20:07 manrique has joined #bpwg 12:21:23 ISSUE: how to keep the screen alive (re null gestures) - what to recommend? 12:21:23 Created ISSUE-263 - How to keep the screen alive (re null gestures) - what to recommend? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/263/edit . 12:23:43 ACTION: Dan to communicate with OpenAjax Alliance about the backlighting issue and null gestures 12:23:43 Created ACTION-788 - Communicate with OpenAjax Alliance about the backlighting issue and null gestures [on Daniel Appelquist - due 2008-06-24]. 12:24:49 adam: 4.6 One Web 12:25:18 Kai has joined #bpwg 12:25:52 jo: invites Jonathan and Sunghan to comment on this - in the context of using application when switching devices 12:27:35 Sunghan: e.g., using mobile web application and switching over seamleassly to PC at home... 12:27:59 adam: e.g, pushing personalization to the server would enable this 12:29:04 jo: is it worthwhile to design mobile web apps to work across multiple devices - possibly simultaneously 12:31:30 adam: 4.6.1 may require some rewording to cover support for ramge of devices AND simultanueos or serial use across multiple devices 12:31:45 s/ramge/range/ 12:34:17 Sunghan: agrees - but need to define specific APIs 12:34:59 kai: does this include switching devives within session? 12:35:07 q? 12:36:18 s/devives/devices/ 12:36:31 dka: need to add a specific app and use case example - e.g., homepage app 12:37:36 Kai: what is meant by sharing consistent app state (in 4.6.1.1)? 12:39:00 adam: 4.7 Presentation Issues - still a placeholder, but some specific examples were discussed earlier 12:39:23 adam: may need to cut dowm the preamble and add details 12:42:02 Scribe: rob 12:42:09 scribenice: rob 12:42:25 scribenick: rob 12:46:43 q+ to gush about iPhone 12:48:15 Apple guidelines: http://developer.apple.com/webapps/designingcontent.php (specifically "Optimize for Page Readability"). 12:49:15 zakim, ping us in 5 mins 12:49:15 ok, jo 12:49:34 ack d 12:49:34 DKA, you wanted to gush about iPhone 12:50:09 dka: since we're discussing presentation issues, i've an action for recs gleaned on this Apple doc 12:51:15 ... some may be only appliccable to iPhone browsers but may be more widely appliccable if say Android's webkit browser also follows suit 12:51:55 scott: you've got the browser that browses the whole web 12:52:33 but built-in a bunch of commands that allow iPhone-aware apps to control the viewport and zoom in/out 12:52:44 adam: is it pure Apple-only? 12:53:18 scott: think it's Apple-only but would be interesting to see when it came into Safari 12:54:16 jo, you asked to be pinged at this time 12:54:37 ... lots of things are handled automatically, the controls mostly disable inappropriate automatic actions for your iPhone app 12:55:15 ... Not sure if Apple are submitting those viewport controls anywhere for others to use. 12:55:57 jo: so what are the generalisable good practices? 12:56:33 dka: there's not much, but I've transferred the action to Scott! 12:57:16 ... interesting info about a finger being 44x44px 13:00:07 Scott: you do make different assumptions for focus-based / pointer-based / touch-based devices 13:01:48 adam: continuing on 4.7.1 13:02:11 .. just noting about touch-based devices 13:03:31 ... what about WTAI links for making phone calls? 13:04:22 Scott: back to 3 different interfaces: 13:04:52 ... 1) focus-based is moving over controls 13:05:31 ... 2) pointer-based is moving a cursor around a screen, a bit like a mouse but probably with a joystick or D-pad 13:06:00 ... 3) touch-based is with a touch-screen and stylus or finger 13:06:43 ... so in 2 and 3 it's essential to know what parts of the screen are "clickable" 13:07:55 ... Both focus-based and touch-based you can move about a page very rapidly 13:08:40 ... wheras pointer-based interfaces can be quite slow if you have to move from side-to-side of the screen a lot 13:09:27 dka: eg controls at the top and bottom of the screen where you have to use both a lot 13:10:10 jo: and you might deliberately do that with a touch-screen to avoid chance of pressing wrong button by accident 13:11:07 Scott: there are some valuable BP1s that are relevant 13:11:42 ... but these 3 input-modes have a huge effect building apps. 13:11:57 s/jo:/scott:/ 13:12:50 jo: we need Scott to add more text around this 13:13:28 ACTION: Scott to propose text for different interaction modes in discussion with Adam 13:13:28 Created ACTION-789 - Propose text for different interaction modes in discussion with Adam [on Scott Hughes - due 2008-06-24]. 13:13:54 adam: and after that we might change the heading to reflect the content 13:14:50 Scott: already discussed helping users to see what's changed ina page (eg "yellow-fade technique") 13:15:02 s/ina/in a/ 13:16:37 ... that works well for text and if you need to change the view in response to an update, sliding the content in helps orientating the user 13:17:42 ... You need to understand which bits of the page are visible to avoid wasting CPU on invisible changes. 13:19:12 ... One of the top-level reasons to do this is to speed up the apparent responsiveness of the user experience - 13:19:54 ... providing immediate feedback (eg animation) while waiting for information 13:20:32 Present+ PH 13:21:44 jo: it's making more small things happen instead of just click-wait-read 13:23:25 adam: recants these ideas in section 4.7 13:24:58 Scott: About text-entry, many browsers won't allow you to see labels around a textbox while you enter text in it. 13:26:05 dom: the inputmode attribute is defined on to tell the browser what type of input you are expecting 13:28:34 jo: it's particularly interested in predictive text 13:29:30 q? 13:29:33 Scott: Consider impact of CPU on the interface. You don't want jerky motion. 13:30:08 q? 13:30:55 ... This will vary a lot between devices. 13:31:59 adam: I'll leave a placeholder here for Scott's contribution. 13:33:06 ... Another potential BP: enabling the browser history by updating the URL with #viewname 13:33:43 ... this also allows the user to bookmark a view within the page 13:33:54 jo: how common is this? 13:34:05 adam: Google uses it all the time 13:34:32 jo: solves a problem, so it's a useful BP 13:58:37 Scribe: francois 13:58:40 ScribeNick: francois 13:59:23 [end of break] 13:59:44 Adam: On handling device capability variation (4.9) 14:01:02 jo: what do we want to say here? 14:01:12 ... 1. determine whether the device supports scripting at all 14:01:54 ... 2. determine the level of script support 14:02:24 ... The first think may be statistically determined through a DDR, whereas the second may not be. 14:02:33 hgerlach has joined #bpwg 14:02:59 hgerlach has joined #bpwg 14:03:15 Scott: from our perspective, we test each possible device to see if our application works 14:03:29 adam: there's device capability and device compliance 14:03:33 q+ to ask about script interpretation / compatibility 14:04:07 ... Initial intent was more: if the device exposes Javascript in some way, what can be done? 14:04:49 ... There's a very standard pattern listed in the doc to detect whether a feature/object is supported 14:05:40 jo: the static detection, the dynamic detection, and to what extent you may design your application to use the dynamic detection 14:06:00 q+ and to say that we are mixing device and client/browser 14:06:16 do we have a different dialin today (currently noone in the conf) ??? 14:06:19 scott: dynamic may be useful for cases where you only want to update the behavior of an application, but where it's not entirely required 14:06:57 I know and there is no way to dialin???? 14:07:24 ... So we can use profiles of Javascript support, and dynamic detection within each profile 14:08:25 ack kai 14:08:25 Kai, you wanted to ask about script interpretation / compatibility 14:09:07 I think since I just have 1 item (action 761) and regarding the allowlist to allow CT engine to setup a Desktop useragent we can discuss this either next Tuesday or you could gimme a call when you like to discuss it. So I won't need to join all time long. 14:09:09 Kai: are we confident that the interpretation of Javascript is standardized enough to tell that dynamic detection will be enough? 14:09:15 adam: probably not. 14:10:18 adam: should we be referencing the DDWG work? 14:10:24 jo: excellent idea, indeed 14:10:49 dka: we should make it clear it's not the only way. There's also WURFL and proprietary means to do such things 14:11:08 ok, 14:11:35 adam: there's also the question of Gears for example, where you actually install something on a browser that doesn't have the capability at first 14:12:51 jo: are we through enough on this before we move on? 14:14:10 adam: I'd prefer to craft some text around this, and see the result 14:14:33 SeanP: There's another document we could reference: the Content Transformation guidelines with the X-Device header. 14:15:01 There could be a content transformation proxy between the origin server and the client 14:15:28 ... It's thus possible that the Javascript is not executed 14:16:06 jo: Can we put a placeholder in whatever text you'll be crafting on the role of CT proxies 14:16:12 adam: ok 14:16:36 ... 4.9.3 Device Classification to simplify content selection/adaptation 14:17:02 jo: I think it qualifies as a best practice. It's about telling people that they don't have to do an instance by instance implementation 14:17:07 edm has joined #bpwg 14:17:17 ... that they may use classification 14:17:27 Kai: it's not an easy issue 14:17:36 ... not easy to classify devices. 14:18:35 jo: I agree, but depending on the features required by your application, you need to classify accordingly: if your application uses location, then you want to know the devices that support such feature 14:18:39 Present+ Rotan 14:18:51 Present+ Rotan 14:19:09 s/ Present+ Rotan// 14:19:33 Rotan: I think an attempt to create a global way to classify devices is just a complete waste of resources 14:20:17 jo: we need a placeholder in there IMO to reference DD Structures 14:21:27 rotan: imagine an ad company that provides banners. They need to provide the structures that are used to categorize the capabilities of the devices that may display each device. 14:21:47 ... The whole intent is to have structures that may be passed across different organizations. 14:22:43 Rotan: hey, wait a minute, I just spot "the" DDR on screen in the doc. I think it's dangerous, because it gives the impression that there is only one global DDR, which is just plain wrong. 14:23:12 adam: OK, I'll change that to "a" DDR. 14:24:09 ... About alternative to client-side scripting 14:24:19 jo: I think this fits in the "One Web" section 14:25:03 ... it seems to me that people whether the application they develop requires a non-javascript implementation 14:25:46 ... We should be aware that the Accessibility and I18n folks may have things to say about Javascript use in Web Applications. 14:26:35 adam: It seems to me that a Javascript application is not always less accessible for instance 14:26:55 jo: that's true, but Flash for instance is often cited as not accessible-friendly 14:27:46 rotan: the ability to deliver an application that doesn't rely on Javascript may be connected to the device capability AND the user's capability. 14:28:05 q+ 14:28:08 ... so far, a DDR only talks about device capabilities, but may include users capability in the future 14:28:21 ack achuter 14:28:38 q? 14:28:55 achuter: the accessibility of javascript. Generally it's accessible, but it usually depends on the assistive technology available on the device. 14:29:31 ... I'm not sure there is an accessibility API for mobile devices 14:29:41 [thunders] 14:30:16 jo: it seems to me that we could probably do with some draft around that point if you could take care of that 14:30:47 ACTION: alan chuter to produce some text around accessibility of Javascript for Web Application Best Practices 14:30:47 Sorry, amibiguous username (more than one match) - alan 14:30:47 Try using a different identifier, such as family name or username (eg. achuter, atai) 14:30:52 ACTION: chuter to produce some text around accessibility of Javascript for Web Application Best Practices 14:30:52 Created ACTION-790 - Produce some text around accessibility of Javascript for Web Application Best Practices [on Alan Chuter - due 2008-06-24]. 14:31:19 kai: should we emphasize the point even more? 14:31:32 jo: let's see what comes out of the draft when it's updated 14:31:42 ... Anything else on 4.9.4? 14:32:22 adam: there's a section on progressive enhancement, which looks very cool 14:32:49 ... but I'm not so sure it's a good idea. I wonder whether it's not too low-level to be a BP. 14:33:59 DKA: Someone presented on this at Over The Air. I wondered if it can be reduced to something more BP-friendly 14:34:18 jo: yes, a big blob of html and javascript is probably not clear enough 14:34:41 ... I suggest we raise an issue on this 14:35:26 ISSUE: How to rephrase progressive enhancement to make it fit as a BP? 14:35:27 Created ISSUE-264 - How to rephrase progressive enhancement to make it fit as a BP? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/264/edit . 14:35:36 zakim, mute god 14:35:36 sorry, JonathanJ, I don't know what conference this is 14:36:05 adam: 4.11, I think we agreed to move to the Scope section 14:37:26 jo: problem with 4.10, not clear what purpose it serves as we don't have any specific BP related to it. I suggest we move it to somewhere else 14:38:03 scott: GPRS, UMTS, Wifi... It's a nice idea, but in practice we don't do it 14:38:18 ... there are other things you need to consider before we move to this point 14:38:36 q+ to add a comment related to section 4.9.5 (that i think we have skipped) 14:38:45 jo: some of it may be moved to minimize use of network typically 14:39:04 q? 14:39:09 ack abel 14:39:09 abel, you wanted to add a comment related to section 4.9.5 (that i think we have skipped) 14:39:17 q+ kai 14:40:30 q? 14:40:47 abel: about 4.9.5, I wonder if we could mention SVG. It's widely deployed in the mobile industry today. I have an example of a statistics chart that degrades gracefully based on the capabilities of the device. 14:40:56 jo: very good point. 14:41:42 dka: If we do that, then we should also reference WICD, because it was built with mobile web applications in mind 14:42:18 ... The problem of course is that it's not implemented in any browser today. 14:43:07 ... I agree to take an action to draft some text 14:43:08 ACTION: dan to draft some text on WICD 14:43:08 Created ACTION-791 - Draft some text on WICD [on Daniel Appelquist - due 2008-06-24]. 14:43:34 ack k 14:46:17 [abel projects some statistics chart] 14:46:37 abel: first of all, this chart uses SVG FULL, with animations and the like. 14:46:50 s/chart/chart demonstrating the use of SVG on desktop and mobile browsers/ 14:47:30 ... second version, the same chart for an E61: you still have animations. The links are made by means of XLink. 14:48:17 s/chart demonstrating the use of SVG on desktop and mobile browsers/chart/ 14:48:24 s/chart]/chart demonstrating the use of SVG on desktop and mobile browsers]/ 14:48:28 ... and then the same example, where animations were removed. 14:48:56 ... and eventually, if SVG is not supported, you may want to display a table for instance 14:49:31 ... The idea would be to complete the practice we have to degrade Javascript apply to SVG. 14:50:03 DKA: you mean figure out what level of SVG the device has? How do you do that on the client-side? 14:50:29 abel: sometimes via a DDR, but some can be determined by scripting. 14:50:49 DKA: hmmm. Seems like a BP that reads: use SVG when available. 14:51:56 [charts being demoed: http://idi.fundacionctic.org/bk/E61/barras.svg] 14:53:01 kai: tangential point. To detect device capabilities... If an application does that again and again, then it suddenly comes with a cost in terms of processing. 14:53:27 -> tjamm.mobi svg dublin mobile traffic info 14:54:06 scott: about the Javascript doing the checks: you do that on the first page, and that's about it. 14:54:30 s/tjamm.mobi/http://tjamm.mobi/ 14:54:33 desktop version-> http://idi.fundacionctic.org/bk/Desktop/barras.svg 14:54:55 kai: ok. I was thinking for instance on detecting bandwidth because you may typically do that using Javascript and sending/receiving chunks over the network, but that's not something you want people to do often. 14:55:00 Nokia e61 version-->http://idi.fundacionctic.org/bk/E61/barras.svg 14:55:18 raster version-->http://idi.fundacionctic.org/bk/Raster/barras.html 14:55:35 jo: thanks abel for the demo. 14:56:24 ACTION: abel to propose some text on SVG 14:56:24 Created ACTION-792 - Propose some text on SVG [on Abel Rionda - due 2008-06-24]. 14:56:58 jo: Anything else from anybody else? 14:57:45 scott: I felt there was not much on caching. Maybe it was in BP1. Even if you have content that changes often, you still have images that may be cached. 14:58:23 kai: good point. There's something we can do: modification-based caching which is not commonly done instead of access-based caching. 14:58:52 ... With that, you can increase the expiration a lot because all that matters is the last modification date. 14:59:09 ... There's a caveat based on the memory of the device, if you cache too much. 14:59:23 jo: There is stuff on caching on BP1. 14:59:45 ... Again, I'd like to ask for more specific text. I think it's a good point. 15:00:35 ... I would add that we have observed, within Content Transformation, that HEAD requests often get turned into GET requests which is not exactly good in terms of caching. 15:00:44 ACTION: Kai to work with Scott to produce proposed text on caching that goes beyond BP 1 15:00:44 Created ACTION-793 - Work with Scott to produce proposed text on caching that goes beyond BP 1 [on Kai Scheppe - due 2008-06-24]. 15:00:49 kai: agree to take an action 15:00:55 jo: anything else? 15:02:02 scott: things often can be done using multiple techniques, and you probably want to identify those that are more widely supported. 15:02:58 s/techniques/techniques in javascript/ 15:02:59 adam: my concern is that it could be too presprictive in terms on how people develop their apps 15:03:22 s/supported./supported. We've found in general the most simple things are more likely to work, sometimes to the cost of elegance/ 15:04:29 dka: I know there is a document at OpenAjax which we could probably reference. 15:05:18 kai: one think that I think is missing is GUI design. 15:05:40 ... We have this top-left navigation problem. Should we comment on what a GUI should look like? 15:06:00 jo: are GUI in mobile world stable enough to comment on that? I think not. 15:06:57 ... I suggest not. But we may put a placeholder to reconsider that later on. 15:07:14 adam has joined #bpwg 15:07:25 http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0053.html 15:07:39 http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn 15:08:52 ACTION-695? 15:08:52 ACTION-695 -- Jonathan Jeon to extract BP statements from K MWBP 1.5 document for consideration in BP 2.0 -- due 2008-04-17 -- OPEN 15:08:52 http://www.w3.org/2005/MWI/BPWG/Group/track/actions/695 15:09:09 jonathan: my proposal is about ACTION-695 separating structure, style and behavior 15:09:40 [mobile/view/controller pattern] 15:09:52 s/mobile/model/ 15:09:57 adam: so this is like an MCV (model controller view) for the mobile? 15:10:22 s/MCV (model controller view)/MVC (model view controller)/ 15:11:02 jo: why don't we raise an issue on this? 15:12:14 ISSUE: Discussion of Jonathan's Submission ref separation of structure presentation and behavior at http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn 15:12:14 Created ISSUE-265 - Discussion of Jonathan's Submission ref separation of structure presentation and behavior at http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/265/edit . 15:12:48 ACTION: Adam to lead off discussion on ISSUE-265 following completion of next draft BP2 15:12:48 Created ACTION-794 - Lead off discussion on ISSUE-265 following completion of next draft BP2 [on Adam Connors - due 2008-06-24]. 15:13:31 jo: [closing the discussion on BP2] 15:13:56 dom: schedule for publication as FPWD? 15:14:30 adam: once I've updated the doc, by the end of the week hopefully, I think we should review the doc again, and then see how it goes 15:14:51 jo: I think we should not postpone for too long. What about saying not to last more than 4 weeks on this? 15:15:46 dom: it would be fairly nice if we could talk about this in the press release that will come with publication of Best Practices 1.0 as Rec when it's done 15:16:10 adam: I can commit to have a new draft of this for next week, provided Scott does his actions as well. 15:16:49 jo: I think the reason for postponing the publication was mostly in regards of the scope, and I think we're clear enough now on that. 15:16:53 DKA: +1 15:16:56 dom: +1 15:17:16 jo: so I don't see why we should postpone that any further once the document is updated. 15:19:35 Jo: I suggest we do checker now 15:22:59 [some talks on the schedule for the rest of the day and tomorrow's schedule] 15:31:23 Scott has joined #bpwg 15:33:11 Scribe: rob 15:33:19 scribenick: rob 15:33:28 Topic: Checker 15:34:28 Miguel: summary of what we've done since beta release 15:35:16 ... fixing bugs, completed tests, performance enhancements and test suite 15:36:04 jo: how complete is test-coverage? 15:36:53 miguel: an example, taking into account media in linked CSS was missing and added 15:37:18 ... so test suite coverage is complete 15:38:24 miguel: Updates to LC happening now: grammar validation and object conformance 15:39:26 ... and of course fixing bugs (from test-suite, Bugzilla and other testing in the wild) 15:40:36 ... Also doing some refactoring and documenting of code and internationalisation 15:41:54 ... Roadmap is Proposed Rec in 3 weeks' time 15:42:06 and Rec a month later 15:42:45 jo: synchronising with the mobileOK Basic Rec would be good? 15:43:34 dom: mid-July is proposed date 15:44:01 edm has joined #bpwg 15:44:08 PROPOSED RSOLUTION: Checker 1.0 to be announced July 15 or 16 to coincide with announcement of BP to rec (and mobileOK Basic to PR?) 15:44:18 +1 (if possible) 15:44:47 +1 15:44:56 RESOLUTION: Checker 1.0 to be announced July 15 or 16 to coincide with announcement of BP to rec (and mobileOK Basic to PR?) 15:45:42 jo: process is we need a plan showing a go/no-go decision week before this 15:46:14 ... and go/no-go criteria (eg no critical bugs) 15:47:15 ... eg all test-suite passed; no issues of checker returning a false result 15:47:33 s/result/positives/ 15:48:00 s/a false/false/ 15:48:35 ... and it's stable (doesn't crash) 15:50:09 PROPOSED RESOLUTION: BPWG acceptance criterion for Checker is that the TF asserts that the test suite is complete and that no false positives or false negatives are known 15:50:12 ... We don't want a WG plenary to approve this, the go/no-go decicion should be technical 15:50:55 PROPOSED RESOLUTION: TF Delegates responsibility for Go/No Go decision to TF based on acceptance criterion being met and no show-stopper bugs 15:51:28 Rotan has joined #bpwg 15:51:38 PROPOSED RESOLUTION: BPWG Delegates responsibility for Go/No Go decision to TF based on acceptance criterion being met and no show-stopper bugs 15:51:56 +1 15:51:59 +1 15:52:00 +1 15:52:06 +1 15:52:12 RESOLUTION: BPWG acceptance criterion for Checker is that the TF asserts that the test suite is complete and that no false positives or false negatives are known 15:52:18 yipee! 15:52:21 RESOLUTION: BPWG Delegates responsibility for Go/No Go decision to TF based on acceptance criterion being met and no show-stopper bugs 15:52:40 [this I think resolves ISSUE-228] 15:52:43 ISSUE-228? 15:52:43 ISSUE-228 -- What Criteria for Checker Approval? -- OPEN 15:52:43 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/228 15:53:16 jo: how will TF get there by that date? Do you have enough resources? 15:53:39 ...would it help to muster more resources? 15:53:43 dom: yes 15:53:52 jo: Google? 15:54:28 Scott has joined #bpwg 15:54:31 Miguel: would help to have more people testing certainly 15:54:57 s/Miguel/Abel/ 15:55:17 adam: We personally don't have the time 15:55:30 q+ 15:56:00 dom: we'll keep working on this, we don't need specific promises now 15:56:21 ... long-term maintenance plan is also needed 15:56:45 jo: yes, will be non-maintenance stuff to be done post-1.0 too 15:57:11 dom: core charter of TF is to get to 1.0 15:58:07 jo: we should at least plan documentation ready with 1.0 so that others might be able to help post-1.0 15:58:31 Abel: there is documentation and it is being updated 15:58:34 ack d 15:59:47 dka: writing to Voda R&D colleagues in Spain for potential help 16:00:27 ACTION: Dan to see if R&D colleagues from Spain can help for developing/maintening mobileOK checker 16:00:27 Created ACTION-795 - See if R&D colleagues from Spain can help for developing/maintening mobileOK checker [on Daniel Appelquist - due 2008-06-24]. 16:01:42 Miguel: we should also think about advertising and publicity 16:02:06 jo: yes, that's the point of synchronisation with mobileOK Basic 16:02:58 Miguel: looking at Bugzilla now, there are two important stylesheet issues 16:05:24 ... Meta refresh bug is a question about following meta refresh "redirects" 16:05:52 dom: mobileOK doesn't suggest to do this, so should be out-of-scope for Checker 16:06:06 Rotan has joined #bpwg 16:06:41 jo: suggest leave it open as low-priority, may crop up in FAQs 16:08:34 dom: update priority of image/object source bug to critical 16:09:42 jo: documentation and internationalisation aren't required for 1.0 - they can follow post-1.0 16:10:17 ... and there are no accessibility requirements because there is no user interface! 16:12:31 Sunghan has left #bpwg 16:13:04 Kai has left #bpwg 16:15:53 RRSAgent, draft minutes 16:15:53 I have made the request to generate http://www.w3.org/2008/06/17-bpwg-minutes.html francois 16:16:06 rob has left #bpwg 18:19:11 Zakim has left #bpwg