- From: Francois Daoust <fd@w3.org>
- Date: Mon, 30 Mar 2009 14:13:16 +0200
- 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 UTC