RE: [minutes] Editorial meeting on Mobile Web Application Best Practices

>Section 3.7 SVG
>- The section is mostly void for the time being, i.e. does not say much 
>apart from "use SVG because it's cool". Any real BP we could think of 
>and put in this section? "Use SVG so that images automatically scale to 
>fit the width of the screen"?


I think it is worth noting what the origin of this section was. In F2F
of past July in Sophia, after I inquired about whether SVG was in scope
regarding MWABP, I was requested to propose some text on this
technology.
 
Afterwards, this contribution was partially incorporated in the document
in its own section. Frankly, I had not thought as having a specific
section for this guidelines but being real examples of possible BPs (i.e
possible use cases for more generic BPs).

For example, taking into account my initial proposed bullet points [1]:

* "Use SVG only when appropriate" could be a real example of 3.6
Handling Device Capability Variation (e.g. similar to 3.6.4 Support a
non-JavaScript Variant if Possible)

* "Use the suitable SVG profile (SVG Tiny 1.1) could be an example of a
more generic BP that would state "Be aware of using suitable formats for
mobile devices" (SVG would be a part of the picture; CSS, mark-up
languages and other browser technologies would be the rest) 

* Be aware of deficient SVG implementations (i.e. Test on target
devices)".
This is a use case for the BP "Test on real Devices" (This BP is not
present in MWAP -it is in MWBP- and I honestly think that it is even
more important in this new context).

* "Minimize the size and complexity of the SVG graphics" could be a real
example of BP 3.4.1 Use Transfer Compression or 3.4.2 Minimize
Application Size.

* "Use some SVG capabilities smartly and Provide graceful degradation to
the SVG graphics" could be an example of 3.6 Handling Device Capability
Variation (e.g. similar to 3.6.4 Support a non-JavaScript Variant if
Possible)

I honestly thought that SVG technology could help to illustrate MWABP
applicability and uses cases (and this was the idea behind this and not
the publicity of a "cool" technology).

Regards,
Abel.

[1]http://lists.w3.org/Archives/Public/public-bpwg/2008Jul/att-0090/SVG_text.html



-----Original Message-----
From: public-bpwg-request@w3.org on behalf of Francois Daoust
Sent: Fri 13/02/2009 16:26
To: Mobile Web Best Practices Working Group WG
Subject: [minutes] Editorial meeting on Mobile Web Application Best Practices
 

Hi all,

Dan, Adam, Jo_on_IRC and I had an editorial meeting on the Mobile Web 
Application Best Practices. We took a few rough notes, which are not 
exactly minutes. They are available at:
  http://www.w3.org/2009/02/10-mwabp-minutes.html

Adam should be working on an updated draft that implements some of the 
changes below.

Below is a more concrete summary of the main points raised during the 
meeting, best viewed with a copy of the latest draft on the screen:
 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090101


Section 3.1 Personalization
-----
- We propose to re-focus the best practices of the section around the 
appropriate use of the local storage API for storing application data, 
when available. The current best practice deald more with regular 
session management and doesn't have any real mobile twist.
- Jo pointed out that we may need to have a specific BP around URI 
decoration and potential size limits of URIs in mobile networks. Any 
thoughts on that?


Section 3.2 Security and privacy
-----
- We reviewed the feedback from the Web Security Context Working Group:
 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009JanMar/0005.html
We recognized that there are valid use cases when storing hashed 
identities over HTTP would improve the user experience, but that the 
message would have to be so nuanced and complex that it sounds best to 
remain silent.
- We also agreed that mobile devices are more exposed to unfriendly 
networks than most desktops (e.g. public WIFI networks). We mentioned 
the idea to replace the BP by one that truly says "Use HTTPS, the 
overhead is not high once the handshake has been made". Any thought on that?
- We evaluated BPs on JSON from a mobile perspective, and realized that:
    1. there isn't any clear mobile-specific touch there
    2. since mobile devices potentially (will) give access to more APIs 
(think geolocation, calendar, contacts list, ...), there's even a higher 
risk to have malicious code executed on mobile devices.
We thus recommend to drop 3.2.2 and to switch 3.2.3 to something along 
the lines of "do not use eval to run untrusted Javascript feeds"


Section 3.3 User awareness and control
-----
We mostly skipped the section. Several comments need to be taken into 
account, but the section looks fine otherwise.


Section 3.4 Conservative user of resources
-----
- We agreed with Jo's former comment that 3.4.1.3 goes too much into 
detail for no clear benefit and should be removed.
- We discussed push methods in 3.4.5. Jo and I raised the fact that the 
BP cannot be actioned by anyone. We agreed to reword the BP in a more 
"network provider" centric way and to get back to the group with the 
updated wording. Jo raises the fact that WiFi only mobile devices de 
facto require a different approach.


Section 3.7 SVG
-----
- The section is mostly void for the time being, i.e. does not say much 
apart from "use SVG because it's cool". Any real BP we could think of 
and put in this section? "Use SVG so that images automatically scale to 
fit the width of the screen"?


Best practices flags
-----
Following one of the last discussions of the mailing-list, we thought 
that it would be useful for readers to identify BPs that matter to them 
easily. Defining precise required capabilities for each BP is likely to 
result in a dead end and would probably not help readers anyway.

The idea we propose is to use a set of simple icons to flag best 
practices. The flags would not need to carry a specific set of device 
capabilities. The list could be:
  ALL: the BP applies to most devices
  CSS: the BP requires the device to have a good support of CSS
  XHR: the BP requires the device to support AJAX-like requests and 
scripting
  SCRIPT: the BP requires the device to support scripting, although not 
necessarily the XHR object (could be merged with former one)
  HTML5: the BP requires some support of advanced HTML5 features 
(typically local-storage)
  SVG: provided we end up with SVG best practices.

I ran through the list of Best practices. I see a couple of them that do 
not quite match any of the categories but could probably be flagged as 
ALL anyway. What about it?


Francois.



Se certificó que el correo entrante no contiene virus.
Comprobada por AVG - www.avg.es 
Versión: 8.0.237 / Base de datos de virus: 270.10.23/1951 - Fecha de la versión: 02/14/09 18:01:00