IRC log of bpwg on 2008-06-17

Timestamps are in UTC.

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