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

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

Great. I'll raise this at the next call just to make sure there are no
objections.

Regards using guidelines as concrete use cases -- I really like the idea of
including concrete use cases since the more concrete the better... I think
we have previously talked about having an appendix for elaboration /
examples / use-cases and if I ever get to writing that I think the SVG
examples will fit in nicely there.

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

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