W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

[minutes] F2F Day 1 - 25 March 2009 - Mobile Web Application Best Practices

From: Francois Daoust <fd@w3.org>
Date: Mon, 30 Mar 2009 14:13:16 +0200
Message-ID: <49D0B75C.6080602@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi,

The minutes of the first day of last week's F2F are available at:
  http://www.w3.org/2009/03/25-bpwg-minutes.html
... and copied as text below.

This first day was spent diving in the latest draft of Mobile Web 
Application Best Practices. We reviewed comments that were made on the 
mailing-list prior to the meeting, and agreed on changes to be brought 
to the draft.

Please refer to the minutes for a complete list of resolutions. The main 
changes that were agreed upon during the day are:
- We will keep best practices on e.g. client-side storage agnostic of 
the underlying technology and mention non-standardized-yet technologies 
as examples: HTML5, BONDI, ...
- A "Minimize time to first view" BP will replace BPs on power-efficient 
methods
- An "Avoid page reloads" BP will be created on the ashes of former "Use 
Scripting" and "Group Closely Coupled Views" BPs
- Wording in "Support a non-JavaScript Variant if Possible" will be 
watered down to explain that a non-Javascript version is only attractive 
when one wants to reach the billions of users that do not have a smart 
phone.
- The BP on using push methods will be generalized to "Exploit 
mobile-specifc methods for initiating Web applications and interaction 
when appropriate" and include SMS, OMA Push, QR codes as specific examples.

Thanks,
Francois.


-----
25 Mar 2009

    [2]Agenda

       [2] 
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html#agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2009/03/25-bpwg-irc

Attendees

    Present
           Adam, Rob, SeanP, Jonathan, AlanC, Jo, Dan, Kai, francois,
           Eduardo, Jeffs_on_the_phone, Bryan_on_the_phone

    Regrets
           none

    Chair
           jo

    Scribe
           Rob

Contents

    The whole day was spent discussing [4]the latest draft of the Mobile
    Web Application Best Practices (MWABP) specification.
      * [5]Topics
          1. [6]MWABP - Overview
          2. [7]MWABP - 1.3.2 - Widgets reference
          3. [8]MWABP - 1.3.4 - Assumed device capabilities
          4. [9]MWABP - 3.1.2 - HTML5 client-side storage
          5. [10]MWABP - 3.4.2 - Minify
          6. [11]MWABP - 3.4.6 - inline style-sheets
          7. [12]MWABP - 3.4.11 and 3.4.12 - Power efficient techniques
          8. [13]MWABP - 3.5.2 and 3.5.4 - Avoid page reloads
          9. [14]MWABP - 3.5.8 and 3.5.9 - Separate rarely used
             functionality
         10. [15]MWABP - 3.5.10 - Consistency across devices
         11. [16]MWABP - 3.6.3 and 3.6.4 - XHR support or not?
         12. [17]MWABP - Personalization
         13. [18]MWABP - 3.2 - Security and privacy
         14. [19]MWABP - 3.3.3 - Automatic Network Access
         15. [20]MWABP - 3.4 - Conservative use of resources
         16. [21]MWABP - 3.5.11 - Push
         17. [22]MWABP - Canvas and SVG
         18. [23]MWABP - Bryan's remaining points
         19. [24]MWABP - Contributions from Jonathan Jeon
         20. [25]MWABP - Login forms
      * [26]Summary of Action Items

       [4] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20091703

Minutes of the F2F

      * [27]Day 1/3 (this page)
      * [28]Day 2/3
      * [29]Day 3/3
      _________________________________________________________

      [27] http://www.w3.org/2009/03/25-bpwg-minutes.html
      [28] http://www.w3.org/2009/03/26-bpwg-minutes.html
      [29] http://www.w3.org/2009/03/27-bpwg-minutes.html

MWABP - Overview

    <adam> [30]http://docs.google.com/Doc?id=dft77cn8_35cvjfktc2&hl=en

      [30] 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> [31]Bryan's latest comments on MWABP

      [31] http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0057.html

    <Bryan> seem to have lost the audio

    <francois> [32]Eduardo's comments on MWABP

      [32] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html

    <francois> [33]Jeff's comments on MWABP

      [33] http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0036.html

    <francois> [34]Jeff's ACTION-910 on use of canvas

      [34] http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0051.html

    <francois> [35]ISSUE-290 raised by Jonathan

      [35] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/290

    <francois> [36]ISSUE-291 raised by Jonathan

      [36] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/291

MWABP - 1.3.2 - Widgets reference

    <DKA> [37]http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets

      [37] 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
    [38]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].

MWABP - 1.3.4 - Assumed device capabilities

    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

MWABP - 3.1.2 - HTML5 client-side storage

    adam: Use client-side-storage. HTLM5, BONDI for example.

    <JonathanJ> Bondi: [39]http://www.omtp.org/bondi

      [39] 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>
    [40]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.htm
    l

      [40] 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

MWABP - 3.4.2 - Minify

    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

MWABP - 3.4.6 - inline style-sheets

    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

MWABP - 3.4.11 and 3.4.12 - Power efficient techniques

    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
    [41]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

MWABP - 3.5.2 and 3.5.4 - Avoid page reloads

    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

MWABP - 3.5.8 and 3.5.9 - Separate rarely used functionality

    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

MWABP - 3.5.10 - Consistency across devices

    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.

MWABP - 3.6.3 and 3.6.4 - XHR support or not?

    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>
    [42]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.htm
    l

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

MWABP - Personalization

    Jo: Let's move on to Bryan's comments.

    <Jo> [43]Bryan's latest comments on MWABP

      [43] http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0057.html

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

MWABP - 3.2 - Security and privacy

    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:
    [45]http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 ]

      [45] 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

MWABP - 3.3.3 - Automatic Network Access

    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

MWABP - 3.4 - Conservative use of resources

    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.

MWABP - 3.5.11 - Push

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

MWABP - Canvas and SVG

    <jeffs>
    [47]http://www.it.rit.edu/~jxs/test/canvas/action910draft.html

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

MWABP - Bryan's remaining points

    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
    [48]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/292/edit .

      [48] 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>
    [49]http://docs.google.com/Doc?id=dhpvgnmn_95cp98m3c4&hl=ko

      [49] http://docs.google.com/Doc?id=dhpvgnmn_95cp98m3c4&hl=ko

MWABP - Contributions from Jonathan Jeon

    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> [50]http://www.w3.org/WAI/WCAG20/quickref/

      [50] http://www.w3.org/WAI/WCAG20/quickref/

    JR: Can we merge this idea with the categories for flip cards Dom
    proposed

    <francois> [51]http://www.w3.org/2007/02/mwbp_flip_cards.html

      [51] 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> [52]Discussion on login forms

      [52] http://www.w3.org/2009/02/10-bpwg-minutes.html#added01

    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
    [53]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> [54]http://docs.google.com/Doc?id=dhpvgnmn_97hhvrdjhn

      [54] 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> [55]http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets

      [55] 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
    [56]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/293/edit .

      [56] 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> [57]http://docs.google.com/Doc?id=dhpvgnmn_98dqm2nddc

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

MWABP - Login forms

    <francois> [58]Login form's discussion

      [58] http://www.w3.org/2009/02/10-bpwg-minutes.html#added01

    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
    [59]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]

Summary of Action Items

    [NEW] ACTION: adam to ping Jose ref the battery and DOM manipulation
    question [recorded in
    [60]http://www.w3.org/2009/03/25-bpwg-minutes.html#action02]
    [NEW] ACTION: Adam to review discussion on login forms and
    resolutions threreto and reinstate text appropriately [recorded in
    [61]http://www.w3.org/2009/03/25-bpwg-minutes.html#action06]
    [NEW] ACTION: Adam to use latest reference from Bryan when
    referencing OMA Push [recorded in
    [62]http://www.w3.org/2009/03/25-bpwg-minutes.html#action04]
    [NEW] ACTION: Dan to work with bryan to propose some text on user
    identification [recorded in
    [63]http://www.w3.org/2009/03/25-bpwg-minutes.html#action03]
    [NEW] ACTION: Dan to write a relevant section at Webapps Wiki to act
    as reference for On MWABP 1.3.2 DKA [recorded in
    [64]http://www.w3.org/2009/03/25-bpwg-minutes.html#action01]
    [NEW] 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
    [65]http://www.w3.org/2009/03/25-bpwg-minutes.html#action05]

    [End of minutes]
Received on Monday, 30 March 2009 12:13:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 March 2009 12:14:00 GMT