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

Hi Adam,

>What should be the action out of this?
>Remove the SVG section unless we get some more specific SVG recommendations on the list ?

I agree with you. I would remove the whole section. What about incorporating these guidelines
as concrete uses cases of selected BPs?

Regards,
Abel
________________________________________
De: Adam Connors [mailto:adamconnors@google.com] 
Enviado el: jueves, 19 de febrero de 2009 17:34
Para: Abel Rionda
CC: Francois Daoust; Mobile Web Best Practices Working Group WG
Asunto: Re: [minutes] Editorial meeting on Mobile Web Application Best Practices

Hey Abel,

Yes, I agree. Many of the SVG BPs have strong overlap with existing BPs and we don't (currently) have a great deal to say specifically on SVG itself. Apologies from me, that I didn't realize the BPs you first submitted were intended as clarifications to exsiting BPs rather than standard alone practices.

What should be the action out of this?

Remove the SVG section unless we get some more specific SVG recommendations on the list ?

Adam.
On Thu, Feb 19, 2009 at 3:18 PM, Abel Rionda <abel.rionda@fundacionctic.org> wrote:

>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

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.11.0/1959 - Fecha de la versión: 02/18/09 20:55:00

Received on Friday, 20 February 2009 07:05:10 UTC