Mobile Web Best Practices Working Group
F2F Sophia-Antipolis - Day 2/3

On the agenda

Jo: Today we have scheduled a full day of BP2. Summary of yesterday: we made good progress on CT.

<jo> Agenda

Jo: Having spent an extra half-day on that, we need to reschedule the things we didn't do - mobileOK topics.
... We can try to fit that in tomorrow but it may mean running into the afternoon.
... 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.

Abel: We rescheduled the mobileOK item - but we are leaving in the afternoon tomorrow.

Jo: We can move the agenda around to accomodate that.

MWABP - Scope

Jo: Adam as co-editor for BP2 has prepared some comments.
... Also a Vodafone submission.
... We will start with a document review and scope discussion.

<adam> http://docs.google.com/Doc?docid=dft77cn8_17dkz5wp8h&hl=en

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.
... top of the doc is scope
... 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?
... I've highlighted the ones that I feel need most attention.
... there's a few more BPs we can add. We should go through those.
... scope?

Jo: yes.

<dom> [I think 4.11 (Applicability to Non-Browser Web Runtime Environment) should probably be moved to scope, 1.4.2 ("Web application")]

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.

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!

jo: are you saying it's missing bits on static content that are missing in bp1?

kai: yes - I was thinking there would be some more expansion on the topics in bp1

scott: I agree. Some of my input is in this area.

kai: I don't have any specific inputs in this area.

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.

jo: we need to categorize comments under the headings of missing, wrong, extra, typographic and unclear.

kai: we need to have references to bp1 - a stronger linkage.

jo: what is missing is a stronger tie-in to bp1 - needs to be higher level than bp1 but lower level than "applications."

kai: yes

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?

kai: potentially.

jo: I have in mind a mental model of how these documents fit together [goes to white board].
... BP1 is a foundation document, on which is built mobileOK basic, on which is built mobileOK pro.
... now we are creating a new foundation document - bp2. In this model, all the documents should refer to bp1 as the foudnation.

kai: the tests document show you adhere to the best practices. with bp2 there is a gap.

jo: if so, then the answer is to fill that chasm in and increase the linkage back to bp1.

adam: yes - I'd like to see that expressed in concrete best practices.

jo: to return to the discussion of scope -

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.
... some requests to add more material to the mobile context have come in.
... I'm happy with it in its current state.
... signifigant concerns?

jo: I've made the point that I don't think think that "great web applications" is meaningful.

adam: I like it - I found it grounding - I think it's been dropped out of the scope.

DKA: I like it because it speaks to web developers.

Jo: is it possible to be precise and also populist? Would it be better to make it precise and then make it populist?

adam: It needs to be useful.

Jo: To be useful it has to be correct. To be correct it has to be percise.

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.

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.
... I think it's about ineroperability at its heart.

Ed: I regarding the audience should we be more percise, saying that this is for web developers as opposed to programmers?
... are we talking about markup technologies primarily?

Jo: under 1.3 what would need to change there?

Ed: People who build java applications I consider to be programmers, people who do markup are web developers [in my view].

DKA: It's all a sliding scale.

Jo: in what respect should this text change to reflect that sentiment?

Ed: the last sentence - can we make it positive...
... Please add "Web developers"

adam: I'm happy with that.

<Zakim> dom, you wanted to suggest 4.11 be integrated in scope 1.4.2

Dom: currently applicability to web-runtimes is in 4.11. I think it should be in the scope of 1.4.2.

adam: I agree.

<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.

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.

Jo: We have 2 competing objectives - one is to make it accessible as possible, the other is to make it tight and correct.

Kai: I think "great web applications" have no meaning.

Jo: How about "web applications" rather than "great web applications"

DKA: I think having prose-type text at the beginning of a document does not take away from percise text later in the document.

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.

Kai: I agree.

DKA: I agree.

Jo: rather than trying to define "Web 2.0" perhaps someone would like to take an action to propose text for that section.

Kai: "Interactive web technologies"

<Kai> ACTION: Dan to come up with alternative phrasing for Web 2.0 [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action01]

<trackbot> Created ACTION-783 - Come up with alternative phrasing for Web 2.0 [on Daniel Appelquist - due 2008-06-24].

<Scott> http://docs.google.com/Doc?docid=dd3jk8v_116pb2r6cfw&hl=en

[reviewing Vodafone submission]

scott: two main areas are user interface and performance - mainly around using client side scripting.
... there may be some overlap [with the current doc]

jo: Ok - this looks "great"
... it looks like it's fairly easy to weave into the structure of the document.

scott: some bits at the end not sure where they fit - such as network.

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.

jo: back to a line by line review.

adam: this document is 9000 words long
... 1.4.4 and 1.4.5 - now obsolete. Are there bits we need to preserve or can we delete them?

[some discussion on wording of this section]

jo: should there be an expression of what the document is not?
... as far as I'm concerned that's "great"

MWABP - Requirements

adam: section 2- this contains all the text now absorbed into section 4.
... propose to remove section 2.

jo: I wasn't happy but I can see the rationale and the consensus view is to remove it so let's move on

MWABP - Personalization

<Zakim> Kai, you wanted to say something on legal issues of personalization

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.

adam: the intent is to say if you have a relationship with the operator you can...

kai: it needs a careful read-through with this point in mind.

jo: we touched on this - should we be seen to be encouraging illegal behavior.
... but not sure what to do to the document...

kai: there's a difference between permission data and automated data - that's one area where we have to be careful.

adam: is it safer just to talk about sign-on?
... there's manual signon and automated signon... so rather than personalization talk about sign-on?

kai: I can take an action...

<dom> ACTION: Kai to review 4.1 Personalization with privacy regulations in mind [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action02]

<trackbot> Created ACTION-784 - Review 4.1 Personalization with privacy regulations in mind [on Kai Scheppe - due 2008-06-24].

DKA: do we need specific wording about privacy and legal implications (e.g. european data protection, etc...)

Jo: that could be a slippery slope....

<Kai> ACTION: Kai to check the personalization section for specific parts that seem to imply combination of personal information with usage patterns [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action03]

<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].

Ed: to be very generic - legality is important. Something like "privacy regulations and legal constraints."

adam: on the back of this conversation - should we focus on login instead of personalization?
... "use automated means for obtaining personalization information" seems inflamatory.

kai: the current phrasing [could be construed] as encouraging illegal behavior.

jo: add a note that it needs to be clarified.

<dom> ACTION-784: dup of ACTION-785

<trackbot> ACTION-784 Review 4.1 Personalization with privacy regulations in mind notes added

<dom> close ACTION-784

<trackbot> ACTION-784 Review 4.1 Personalization with privacy regulations in mind closed

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.

jo: suggests "personalization often increases user value."
... [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.
... 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.
... so we need to note that there are things you need to know about the ecosystem that you may not know.

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?

jo: yes and then we can have some additional wording on who can act as a service provider [eg aggregators]

<jo> ACTION: Jo to draft wording for an appendix that identifies the aggregators and operator roles that are different in the mobile ecosystem. [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action04]

<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].

adam: suggest cutting out text on "other user information..."

<achuter> +

alan: occurs to me that personal information might include accesability preferences.

adam: i'm proposing removing the enumeration all-together.

alan: ok

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.

<Kai> ScribeNick: Kai

adam: [explaining his reasoning for a comment on cookies]
... that hidden information is not retained across sessions
... need to remove the cookie part
... as for security don't store personal infomation in cookies and adjust security to what is necessary

MWABP - Security and privacy

adam: 4.2.1...is the wording ok?
... what is the intent of this BP?

jo: not sure if this is particular mobile specific

adam: not sure

dom: this may be interesting for web developers in this context

jo: i am not sure that using secure hashes is a BP

adam: should we remove this section?

is there a document we can refer to, since it is not specifically mobile?

jo: what do the present think?
... is this sufficiently mobile?

dom: if you only develop apps for the pc then this may pose different challenges since it is a mobile environment
... recommending not use HTTPS is certainly not a good practice, but you have to take the mobile context into account

jo: should we say do not use HTTPS unnecessarily?
... if we were to say use a secure hash somebody might ask what is that exactly?

francois: you want to just say use https if you have secure information?

SeanP: isn't it the same on the PC?

jo: but it is in scope
... there are certainly harmful effects in a mobile environment

SeanP: but don't overuse it, right?

adam: so we should change this from protecting personal information to balance the measures chosen?

jo: can you come up with seomthing?

dka: can we have explicit examples?
... instead of leaving it open, give specific alternatives
... we should not say these are the MOST secure alogrithms or somethign like that

adam: I agree. We would then have to worry about that too.

edm: rather than just say "use HTTPS
... use "performance implications of using HTTPS"

MWABP - User awareness and control

adam: 4.3

Inform user about personal information? how and what?

adam: [explainin this proposed changes]
... perhaps the BP is good and we need to reword it a bit
... informing the user means there are some browsers that show personal information, such as contacts etc.
... you should allow users to opt out
... I think we need to come up with a coherent view of what this sections means and says

dom: maybe this should have a caveat if the device does not allow the opt out the app should do so

adam: the app may not know if a dialog has popped up (?)

dka: the implementation are not out there yet
... access to the address book from the scripting layer would surely prompt the user

jo: we should something to catch poor app design
... harmonzing access with underlying systems

dom: if you get this prompt but don't the app will get access to your addressbook you will be surprized

adam: make the request for personal information an active choice?

dom: yes.
... we need to keep the user aware of what might trigger access to personal information

jo: prior to running the app for the first time it should inform the user about all the information it will access

adam: CP may not necessarily want to do that

jo: it can be done in a number of ways

edm: i think it would be good have statement of balancing security with sensitivity
... context does matter a lot, but taking advantage of that context is a trade off
... user experience may improve but there is a price to pay
... don't ask for everything if you make do with less
... should we recommend DCCI or so?

jo: I think we have had problems with this before and would say no

dom: I think we can't say it is a BP
... there will be a geolocation API and if this work is going ahead fast enough, it might become interesting

jo: at the end of this section we will take a break
... 4.3.4 - Brian is keen on redirection

[break for 20 min]

[We're baaack]

MWABP - Use of cookies and redirection

adam: provide control for app behavior
... use of cookies and redirection
... this might be a bit turned around. Should be robust against loss of cookie information

<DKA> +1

jo: the amount in infos should be minimized is the focus here
... use only the user id key

adam: minimize redirects
... use landing pages

Kai: actually landing pages tend to annoy users

jo: we don't want to interrupt user flow
... we need to balance the two

<Zakim> DKA, you wanted to wonder out-loud on whether there should be a bp on use of client-side database?

dka: there are at least two implementation of client side databases
... would it be useful to write something about this in this document?

jo: so to minimize client side storage is not a BP?

dka: in the mobile context you probably don't want to store lots of information

jo: so the amount of information is important
... the amount of offline operation needs to be taken into account
... and multi channel access services
... speed of access is important

adam: where does this fit in?

jo: control of the app is really the point taking this into account

adam: does this fit into this section on cookies and redirects?

jo: no

Kai: what about redirects, latency etc. Is that still timely for this document?

jo: we need to get to this, but let's finish this first

adam: so which BPs do we need?

jo: I think we need a how to do it
... also need to add the thing on size of client side storage

adam: move redirects to use of resources

Kai: we should not focus too much on redirects, latency and realted issues

jo: Bryan has a similar stance
... I am not sure how much more we are saying here that hasn't been said in BP1 already

adam: we should mention it, but it doesn't really add much

jo: we should have a coherent policy on when to mention BP1

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

jo: so where possible we should make reference to BP1
... we could have a preamble "refer also to..."

adam: web applications increase demands for redirects for authentication?

jo: I am not sure "need" is the right

Kai: sometimes redirects really are overdone but they do have an important role to play
... is there are web app specific part that we could mention?

adam: well the authentication part may be one

jo: so let's ref BP1 on redirection as preamble for 4.5

dom: there is no real BP that says minimize server redirection

jo: so yes, then we should call out the fine points
... but we perhaps should not mention specific numbers on redirects

<SeanP> Scribe: Sean

<SeanP> Scribenick:Sean

MWABP - Conservative use of resources

Jo: on to 4.5

Adam: Transfer compression makes sense
...not sure what we want to recommend for app level compression

Kai: Everyone thinks that compression will speed things up; when you go to binary on a fast network it sometimes slows things down.
...not sure if this is always true in mobile environment

DKA: Makes Vodafone joke

Rob: Use text-based compression

Jo: How can we capture point of efficiency gain of compression vs. loss of battery life, etc.

Kai: restrict to text based compression

Dom: Don't compress 1k files and be careful with other bad compression techniques; is there a way we can get data on this?
...If you are going to send 1M of a text file, it should be compressed.
...Where is the line?

Adam: Could publish a table with thresholds of data sizes to compress.

Kai: Can show a table of compression data.

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

Rob: In practice you tell it what mime types to compress

Kai: [Puts up a table about compression on the screen]

Kai: [Describing table] Many times don't see much benefit from compression of binary content on ISDN and broadband
...Compression makes a big difference however on text based content

Adam: Simple message: compression of text is good, compression of binary data is bad

Kai: [another spreadsheet is projected] [Shows a case where compression has a negative effect]
...A lot of variation in benefits of compression for different files

Rob: Given normal developer tools, it is difficult to configure to compress different size files

Scott: After doing all of the BP1 stuff like removing whitespace, etc, the impact of compression may not be that much.

Adam: Javascript compresses well.

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

Kai: Obfuscating JavaScript makes the files smaller

Adam: yes, should we call it tokenizing?

<dom> [An ajaxian article referring to the lack of benchmark on the topic http://ajaxian.com/archives/compression-caching-for-faster-load-times]

Jo: Open question: Do some work to find out what files and sizes are best to compress.

<dom> [another related article: http://clientside.cnet.com/best-practices/optimization/dean-edwards-packer-compression-tool/ ]

Adam: There is a section on app compression which I thought we should remove.
...I think it is covered elsewhere.

Jo: Can we put something in about preprocessing JavaScript?

DKA: There is a mention of EXI; I think this is out of scope for this document.

<DKA> +1

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.

Kai: Shouldn't we refer to asynchronous methods to reduce transport?

Adam: I agree; we should refer to that.

Jo: Should it be in this section or another section?

Kai: Maybe in another section.

Jo: Moving to "Minimize Automatically Issued Network Requests"

<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

<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

Adam: 2 main points: Batch requests together and Back off during periods of inactivity

<dom> a archives (.jar files) by 52% on average for the networks, compression techniques and benchmarks studied"]
...Make these two things the focus of this section.

Dom: How do you do this?

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

Kai: Would sections like this benefit from listing bad examples?
...If we can't come up with concrete problems that we are trying to solve, maybe we don't actually have a good BP.

Jo: A good idea, but verges on the idea of techniques.

DKA: Actually different than techniques; with techniques we would come up with a Wiki and the community would come in and add content...
...Come up with example applications--this would be a new work item however.

Kai: If you show a good way and a bad way to do things, you can see the difference.

Adam: From the view of developer, the good way would be more useful.

Jo: Back to "Minimize Automatically Issued Network Requests"

Jo: Is there anything to say about roaming here?

Adam: No way to tell if you are roaming.
...Good reason to give users more control

Scott: Are we talking about a low bandwidth version and a high bandwidth version?

Adam: Do we want to make a BP for this?

Jo: I think we should do this.

DKA: Refer to BP1.

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.
...I use both of them.

Adam: If it makes sense to your app, provide a low bandwidth version.

Jo: We're going off on a tangent...we're talking about automatic network requests.
...I think we want to say offer a low bandwidth version if you can.
...some apps may not be able to offer a low bandwith version.

Adam: Should be able to switch network off if possible.

Kai: Is this low bandwidth stuff really relevant for this document--we're not really talking about saving money.
...it's about a comfortable application; sometime you have to spend more money.

Jo: We're talking about value--an app
...shouldn't use bandwidth unnecessarily.

Adam: Moving to "Push Methods"

Jo: generated a lot of discussion on list

Adam: Reference to MIDP seems out of scope; but I like the idea of the BP.

Jo: What we lack standardized or commonly accessible push methods. Hard to recommend a specific Push method.

DKA: What about WAP push? Is it the same as OMA push?

Adam: I think they are the same?

Rob: That is the problem. Where does a developer go to find out about this stuff?

<dom> OMA Push specs

<dom> WAP Push in wikipedia

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.
...since mediation is required with Push, it requires extra administrative actions.

Adam: We have some examples; we should remove the part about MIDP.

Jo: Should we remove "vendor-specific mechanisms"? Is that too opaque?

Jo: How is WAP push different from a text message?

DKA: WAP push sends a special SMS. Hasn't been popular because the user experience differs greatly across handsets.

Rob: Yes, the user experience varies.

Jo: Is it worth capturing this point about the user experience varying?

Ed: Are people still using it?

Rob: Old spec, but people still do use it.

Adam: On to Minimize Application Size
...There is a long part with examples that should be removed.

<DKA> http://www.w3.org/TR/mobile-bp/#MINIMIZE

...Should we just focus on tokenizing scripts?

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.
...the CSS suggestion was by Martin.
...disadvantage is that the stylesheets cannot be shared easily between documents.

Adam: Suggestion is to remove the stuff about CSS selectors and make this BP about tokenization of scripts.

Jo: Maybe we put something in that is more bland about using CSS selectors, but not include the detailed example.

<edm> http://my.opera.com/Andrew%20Gregory/blog/

[Time for lunch; back at 1:15]

<adam> http://docs.google.com/Doc?id=dft77cn8_17dkz5wp8h

<edm> scribe: edm

<scribe> scribenick: edm

<DKA> Of interest: http://www.moconews.net/entry/419-bank-of-america-says-it-has-1-million-mobile-users-details-other-mobile/

<edm2z> scribe: edm

<edm2z> scribenick: edm2z

adam: back to 4.5.5 Minimize DOM Manipulation

<achuter> Is there some way people can measure if they are doing this efficiently?

Scott: parsing the javascript to initialize the doc slows things down...

Jo: practice should be about limiting DOM manipulation required before initialization of the page
... limit dynamic/scripting portions where possible

adam: we have not measured the cost of dynamic vs. static - need benchmarks
... may also need new BP to minimize network requests

dka: in general this makes sense

adam: e.g., do not require additional request for JSON packet...

jo: should we discuss progressive rendering - page rendered as streams?
... all points discussed are really about snappier user experiences
... e.g., contacts as JSON rather than fully-rendered HTML

Scott: this is about more general presentation issues - not just DOM manipulation

DKA: need to provide immediate feedback and keep user aware of what is going on - e.g., animation for loading in case of delays

adam: e.g., notification thta your app is coming down ...

Jo: is there anyting in particular to preserve re efficient DOM manipulation?

dka: who would do some testing?
... if presentation related BPs cover this, we could drop this for now.

adam: 4.5.6 Minimize External Script Files
... ...could be absorbed into other sections...
... ...e.g., minimize network requests
... topic of minimizing external script files would benefit from some benchmarking data
... deferred binding of device specific bits seems to be a good idea

Kai: re 4.5.6.2 - question on diminishing efficiency of caching?

adam: need to discuss the benefits of deferred binding vs. pre-loading

jo: points out the difference between static pages vs. dynamic applications - re value of caching

adam: 4.5.7 Use Power-Efficient Methods
... ... need some benchmarking data - to show specific cost

Scott: no specific data to offer on this yet

adam: valid point in general - but there are other power efficiency issues other than usage

Jo: ... leave this as a placeholder for now - need more details and specific examples of power efficient techniques
... perhpas somebody should draft some specific text for the placeholder

<scribe> ACTION: Scott to draft text re power efficiency by June 25 [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action05]

<trackbot> Created ACTION-787 - Draft text re power efficiency by June 25 [on Scott Hughes - due 2008-06-24].

ISSUE: how to keep the screen alive (re null gestures) - what to recommend?

<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 .

<jo> ACTION: Dan to communicate with OpenAjax Alliance about the backlighting issue and null gestures [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action06]

<trackbot> Created ACTION-788 - Communicate with OpenAjax Alliance about the backlighting issue and null gestures [on Daniel Appelquist - due 2008-06-24].

MWABP - One Web

adam: 4.6 One Web

jo: invites Jonathan and Sunghan to comment on this - in the context of using application when switching devices

Sunghan: e.g., using mobile web application and switching over seamleassly to PC at home...

adam: e.g, pushing personalization to the server would enable this

jo: is it worthwhile to design mobile web apps to work across multiple devices - possibly simultaneously

adam: 4.6.1 may require some rewording to cover support for range of devices AND simultanueos or serial use across multiple devices

Sunghan: agrees - but need to define specific APIs

kai: does this include switching devices within session?

dka: need to add a specific app and use case example - e.g., homepage app

Kai: what is meant by sharing consistent app state (in 4.6.1.1)?

MWABP - Interaction and presentation issues

adam: 4.7 Presentation Issues - still a placeholder, but some specific examples were discussed earlier
... may need to cut dowm the preamble and add details

<rob> Scribe: rob

scribenice: rob

<scribe> scribenick: rob

<DKA> Apple guidelines: http://developer.apple.com/webapps/designingcontent.php (specifically "Optimize for Page Readability").

<Zakim> DKA, you wanted to gush about iPhone

dka: since we're discussing presentation issues, i've an action for recs gleaned on this Apple doc
... some may be only appliccable to iPhone browsers but may be more widely appliccable if say Android's webkit browser also follows suit

scott: you've got the browser that browses the whole web

but built-in a bunch of commands that allow iPhone-aware apps to control the viewport and zoom in/out

adam: is it pure Apple-only?

scott: think it's Apple-only but would be interesting to see when it came into Safari
... lots of things are handled automatically, the controls mostly disable inappropriate automatic actions for your iPhone app
... Not sure if Apple are submitting those viewport controls anywhere for others to use.

jo: so what are the generalisable good practices?

dka: there's not much, but I've transferred the action to Scott!
... interesting info about a finger being 44x44px

Scott: you do make different assumptions for focus-based / pointer-based / touch-based devices

adam: continuing on 4.7.1
... just noting about touch-based devices
... what about WTAI links for making phone calls?

Scott: back to 3 different interfaces:
... 1) focus-based is moving over controls
... 2) pointer-based is moving a cursor around a screen, a bit like a mouse but probably with a joystick or D-pad
... 3) touch-based is with a touch-screen and stylus or finger
... so in 2 and 3 it's essential to know what parts of the screen are "clickable"
... Both focus-based and touch-based you can move about a page very rapidly
... wheras pointer-based interfaces can be quite slow if you have to move from side-to-side of the screen a lot

dka: eg controls at the top and bottom of the screen where you have to use both a lot

scott: and you might deliberately do that with a touch-screen to avoid chance of pressing wrong button by accident
... there are some valuable BP1s that are relevant
... but these 3 input-modes have a huge effect building apps.

jo: we need Scott to add more text around this

<jo> ACTION: Scott to propose text for different interaction modes in discussion with Adam [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action07]

<trackbot> Created ACTION-789 - Propose text for different interaction modes in discussion with Adam [on Scott Hughes - due 2008-06-24].

adam: and after that we might change the heading to reflect the content

Scott: already discussed helping users to see what's changed in a page (eg "yellow-fade technique")
... 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
... You need to understand which bits of the page are visible to avoid wasting CPU on invisible changes.
... One of the top-level reasons to do this is to speed up the apparent responsiveness of the user experience -
... providing immediate feedback (eg animation) while waiting for information

jo: it's making more small things happen instead of just click-wait-read

adam: recants these ideas in section 4.7

Scott: About text-entry, many browsers won't allow you to see labels around a textbox while you enter text in it.

dom: the inputmode attribute is defined on <input> to tell the browser what type of input you are expecting

jo: it's particularly interested in predictive text

Scott: Consider impact of CPU on the interface. You don't want jerky motion.
... This will vary a lot between devices.

adam: I'll leave a placeholder here for Scott's contribution.
... Another potential BP: enabling the browser history by updating the URL with #viewname
... this also allows the user to bookmark a view within the page

jo: how common is this?

adam: Google uses it all the time

jo: solves a problem, so it's a useful BP

<francois> Scribe: francois

<scribe> ScribeNick: francois

[end of break]

MWABP - Handling device capability variation

Adam: On handling device capability variation (4.9)

jo: what do we want to say here?
... 1. determine whether the device supports scripting at all
... 2. determine the level of script support
... The first think may be statistically determined through a DDR, whereas the second may not be.

Scott: from our perspective, we test each possible device to see if our application works

adam: there's device capability and device compliance
... Initial intent was more: if the device exposes Javascript in some way, what can be done?
... There's a very standard pattern listed in the doc to detect whether a feature/object is supported

jo: the static detection, the dynamic detection, and to what extent you may design your application to use the dynamic detection

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

scott: So we can use profiles of Javascript support, and dynamic detection within each profile

<Zakim> Kai, you wanted to ask about script interpretation / compatibility

<inserted> Following is a message from Heiko connecting remotely to the IRC channel

<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.

Kai: are we confident that the interpretation of Javascript is standardized enough to tell that dynamic detection will be enough?

adam: probably not.
... should we be referencing the DDWG work?

jo: excellent idea, indeed

dka: we should make it clear it's not the only way. There's also WURFL and proprietary means to do such things

<hgerlach> ok,

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

jo: are we through enough on this before we move on?

adam: I'd prefer to craft some text around this, and see the result

SeanP: There's another document we could reference: the Content Transformation guidelines with the X-Device header.

There could be a content transformation proxy between the origin server and the client

scribe: It's thus possible that the Javascript is not executed

jo: Can we put a placeholder in whatever text you'll be crafting on the role of CT proxies

adam: ok
... 4.9.3 Device Classification to simplify content selection/adaptation

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
... that they may use classification

Kai: it's not an easy issue
... not easy to classify devices.

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

Rotan: I think an attempt to create a global way to classify devices is just a complete waste of resources

jo: we need a placeholder in there IMO to reference DD Structures

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.
... The whole intent is to have structures that may be passed across different organizations.
... 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.

adam: OK, I'll change that to "a" DDR.
... About alternative to client-side scripting

jo: I think this fits in the "One Web" section
... it seems to me that people whether the application they develop requires a non-javascript implementation
... We should be aware that the Accessibility and I18n folks may have things to say about Javascript use in Web Applications.

adam: It seems to me that a Javascript application is not always less accessible for instance

jo: that's true, but Flash for instance is often cited as not accessible-friendly

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.
... so far, a DDR only talks about device capabilities, but may include users capability in the future

achuter: the accessibility of javascript. Generally it's accessible, but it usually depends on the assistive technology available on the device.
... I'm not sure there is an accessibility API for mobile devices

[thunders]

jo: it seems to me that we could probably do with some draft around that point if you could take care of that

<scribe> ACTION: alan chuter to produce some text around accessibility of Javascript for Web Application Best Practices [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action08]

<trackbot> Sorry, amibiguous username (more than one match) - alan

<trackbot> Try using a different identifier, such as family name or username (eg. achuter, atai)

<scribe> ACTION: chuter to produce some text around accessibility of Javascript for Web Application Best Practices [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action09]

<trackbot> Created ACTION-790 - Produce some text around accessibility of Javascript for Web Application Best Practices [on Alan Chuter - due 2008-06-24].

kai: should we emphasize the point even more?

jo: let's see what comes out of the draft when it's updated
... Anything else on 4.9.4?

adam: there's a section on progressive enhancement, which looks very cool
... but I'm not so sure it's a good idea. I wonder whether it's not too low-level to be a BP.

DKA: Someone presented on this at Over The Air. I wondered if it can be reduced to something more BP-friendly

jo: yes, a big blob of html and javascript is probably not clear enough
... I suggest we raise an issue on this

ISSUE: How to rephrase progressive enhancement to make it fit as a BP?

<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 .

adam: 4.11, I think we agreed to move to the Scope section

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

scott: GPRS, UMTS, Wifi... It's a nice idea, but in practice we don't do it
... there are other things you need to consider before we move to this point

jo: some of it may be moved to minimize use of network typically

<Zakim> abel, you wanted to add a comment related to section 4.9.5 (that i think we have skipped)

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.

jo: very good point.

dka: If we do that, then we should also reference WICD, because it was built with mobile web applications in mind
... The problem of course is that it's not implemented in any browser today.
... I agree to take an action to draft some text

<jo> ACTION: dan to draft some text on WICD [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action10]

<trackbot> Created ACTION-791 - Draft some text on WICD [on Daniel Appelquist - due 2008-06-24].

[abel projects some statistics chart demonstrating the use of SVG on desktop and mobile browsers]

abel: first of all, this chart uses SVG FULL, with animations and the like.
... second version, the same chart for an E61: you still have animations. The links are made by means of XLink.
... and then the same example, where animations were removed.
... and eventually, if SVG is not supported, you may want to display a table for instance
... The idea would be to complete the practice we have to degrade Javascript apply to SVG.

DKA: you mean figure out what level of SVG the device has? How do you do that on the client-side?

abel: sometimes via a DDR, but some can be determined by scripting.

DKA: hmmm. Seems like a BP that reads: use SVG when available.

<dom> [charts being demoed: http://idi.fundacionctic.org/bk/E61/barras.svg]

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.

<jo> -> tjamm.mobi svg dublin mobile traffic info

scott: about the Javascript doing the checks: you do that on the first page, and that's about it.

<jo> s/tjamm.mobi/http://tjamm.mobi/

<abel> desktop version-> http://idi.fundacionctic.org/bk/Desktop/barras.svg

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.

<abel> Nokia e61 version-->http://idi.fundacionctic.org/bk/E61/barras.svg

<abel> raster version-->http://idi.fundacionctic.org/bk/Raster/barras.html

jo: thanks abel for the demo.

<scribe> ACTION: abel to propose some text on SVG [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action11]

<trackbot> Created ACTION-792 - Propose some text on SVG [on Abel Rionda - due 2008-06-24].

jo: Anything else from anybody else?

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.

kai: good point. There's something we can do: modification-based caching which is not commonly done instead of access-based caching.
... With that, you can increase the expiration a lot because all that matters is the last modification date.
... There's a caveat based on the memory of the device, if you cache too much.

jo: There is stuff on caching on BP1.
... Again, I'd like to ask for more specific text. I think it's a good point.
... 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.

<jo> ACTION: Kai to work with Scott to produce proposed text on caching that goes beyond BP 1 [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action12]

<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].

kai: agree to take an action

jo: anything else?

scott: things often can be done using multiple techniques in javascript, and you probably want to identify those that are more widely supported. We've found in general the most simple things are more likely to work, sometimes to the cost of elegance

adam: my concern is that it could be too presprictive in terms on how people develop their apps

dka: I know there is a document at OpenAjax which we could probably reference.

kai: one think that I think is missing is GUI design.
... We have this top-left navigation problem. Should we comment on what a GUI should look like?

jo: are GUI in mobile world stable enough to comment on that? I think not.
... I suggest not. But we may put a placeholder to reconsider that later on.

MWABP - Separating structure, style, and behavior

<JonathanJ> http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0053.html

<dom> http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn

ACTION-695?

<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

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/695

jonathan: my proposal is about ACTION-695 separating structure, style and behavior

<dom> [model/view/controller pattern]

adam: so this is like an MVC (model view controller) for the mobile?

jo: why don't we raise an issue on this?

<jo> ISSUE: Discussion of Jonathan's Submission ref separation of structure presentation and behavior at http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn

<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 .

<jo> ACTION: Adam to lead off discussion on ISSUE-265 following completion of next draft BP2 [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action13]

<trackbot> Created ACTION-794 - Lead off discussion on ISSUE-265 following completion of next draft BP2 [on Adam Connors - due 2008-06-24].

jo: [closing the discussion on BP2]

MWABP - Publication as First Public Working Draft

dom: schedule for publication as FPWD?

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

jo: I think we should not postpone for too long. What about saying not to last more than 4 weeks on this?

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

adam: I can commit to have a new draft of this for next week, provided Scott does his actions as well.

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.

DKA: +1

dom: +1

jo: so I don't see why we should postpone that any further once the document is updated.
... I suggest we do checker now

[some talks on the schedule for the rest of the day and tomorrow's schedule]

<rob> Scribe: rob

<scribe> scribenick: rob

mobileOK Checker

Miguel: summary of what we've done since beta release
... fixing bugs, completed tests, performance enhancements and test suite

jo: how complete is test-coverage?

miguel: an example, taking into account media in linked CSS was missing and added
... so test suite coverage is complete
... Updates to LC happening now: grammar validation and object conformance
... and of course fixing bugs (from test-suite, Bugzilla and other testing in the wild)
... Also doing some refactoring and documenting of code and internationalisation
... Roadmap is Proposed Rec in 3 weeks' time

and Rec a month later

jo: synchronising with the mobileOK Basic Rec would be good?

dom: mid-July is proposed date

<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?)

<dom> +1 (if possible)

<DKA> +1

RESOLUTION: Checker 1.0 to be announced July 15 or 16 to coincide with announcement of BP to rec (and mobileOK Basic to PR?)

jo: process is we need a plan showing a go/no-go decision week before this
... and go/no-go criteria (eg no critical bugs)
... eg all test-suite passed; no issues of checker returning false positives
... and it's stable (doesn't crash)

<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

jo: We don't want a WG plenary to approve this, the go/no-go decicion should be technical

<jo> PROPOSED RESOLUTION: TF Delegates responsibility for Go/No Go decision to TF based on acceptance criterion being met and no show-stopper bugs

<jo> PROPOSED RESOLUTION: BPWG Delegates responsibility for Go/No Go decision to TF based on acceptance criterion being met and no show-stopper bugs

<dom> +1

<DKA> +1

<adam> +1

<Kai> +1

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

<DKA> yipee!

RESOLUTION: BPWG Delegates responsibility for Go/No Go decision to TF based on acceptance criterion being met and no show-stopper bugs

<dom> [this I think resolves ISSUE-228]

<dom> ISSUE-228?

<trackbot> ISSUE-228 -- What Criteria for Checker Approval? -- OPEN

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/228

jo: how will TF get there by that date? Do you have enough resources?
... would it help to muster more resources?

dom: yes

jo: Google?

Abel: would help to have more people testing certainly

adam: We personally don't have the time

dom: we'll keep working on this, we don't need specific promises now
... long-term maintenance plan is also needed

jo: yes, will be non-maintenance stuff to be done post-1.0 too

dom: core charter of TF is to get to 1.0

jo: we should at least plan documentation ready with 1.0 so that others might be able to help post-1.0

Abel: there is documentation and it is being updated

dka: writing to Voda R&D colleagues in Spain for potential help

<dom> ACTION: Dan to see if R&D colleagues from Spain can help for developing/maintening mobileOK checker [recorded in http://www.w3.org/2008/06/17-bpwg-minutes.html#action14]

<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].

Miguel: we should also think about advertising and publicity

jo: yes, that's the point of synchronisation with mobileOK Basic

Miguel: looking at Bugzilla now, there are two important stylesheet issues
... Meta refresh bug is a question about following meta refresh "redirects"

dom: mobileOK doesn't suggest to do this, so should be out-of-scope for Checker

jo: suggest leave it open as low-priority, may crop up in FAQs

dom: update priority of image/object source bug to critical

jo: documentation and internationalisation aren't required for 1.0 - they can follow post-1.0
... and there are no accessibility requirements because there is no user interface!