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
>
>