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