RE: MWABP stable draft for F2F (no update I'm afraid).

Dear Adam, Bryan,

Unfortunately I won't be able to attend the Face to Face meeting.

However I have one generic comment about the techniques proposed in this document. It seems to me that they promote an imperative / hacks-based development style for doing content / application adaptation. Although the techniques you propose (such as the CSS degradation or the Javascript degradation) in the document might work, they are not by far the best maintainable way to achieve what you are pursuing. Other techniques such as making use of the onload event are well-recognised by the AJAX community as bad practices, so I think the techniques / examples you are proposing should be reconsidered ...

In fact, content / application adaptation solutions both open source and commercial do that kind of staff at the server side hiding the author from writing / hacking Javascript. Moreover, an author / programmer could do the same without entering in that kind of client-side hacks, doing the same task at the server side.

Also it worries me, that it is not mentioned things like the DDR Simple API in examples that even talk about getting device view ports and things like that.

Best Regards

________________________________________
De: public-bpwg-request@w3.org [public-bpwg-request@w3.org] En nombre de Adam Connors [adamconnors@google.com]
Enviado el: martes, 14 de octubre de 2008 10:00
Para: MWI BPWG Public
Asunto: MWABP stable draft for F2F (no update I'm afraid).

Hello,

Apologies. I'm afraid there will be no new draft of MWABP in time for the f2f next wk as promised... Events have overtaken me in unlikely and amusing ways which I'll share with you over a beer some time.

The stable draft for discussion next wk is the same as last wks:

http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081008

Please review thoroughly so we can be up to speed and don't need to keep Bryan out of his Osaka sleep-pod any longer than necessary. Below is the beginnings of a rough agenda, please add to it on this thread.

Topics for discussion in my mind:

1. Bryan is going to add some comments (or a draft) regarding compatibility. Would be good to take the opportunity to discuss f2f in the broader group.

2. I have added a number of recommendations drafted from various sources around Latency -- 3 on image handling, and a few that are just headings at the moment on javascript parsing. It would be good to go through these, add similar if we can think of more, discuss  what level of detail is appropriate... Regarding the javascript ones especially these are taken from desktop browser research and may not be applicable to mobile browsers. Maybe people in the group with specific experience of javascript parsing on mobiles could come up with some specific recommendations.

3. After the last f2f Scott added a section on User Interface, it would be good to review this section, expand, edit as appropriate.

4. In the light of (2) & (4) I'm beginning to worry that our top-level headings need a bit of a refactor. The following sections all feel a little ad-hoc to me and I think with some thought we can come up with a grouping that will express the intent more clearly.


 *   Conservative Use of Resources -- do we need a heading that expresses why this is important. Or something more focussed -- currently a bit of a catch all.
 *   One Web -- contains only one recommendations, can this we expressed as part of a different heading.
 *   Handling Device Capability Variation -- candidate for refactoring.
 *   User Interface
 *   Latency -- both UI and Latency are tack-ons that haven't had much thought. Would be good to extract a section heading that is more expressive.

5. In this latest draft "Personalization" has become unwieldy. We probably need to extract the comments on cookies and find another home for these... Finding a home for these might inform our discussion (4) above.

6. "Handling Device Capability Variation" contains a lot of detail. Would be good to extract from this which parts are relevant so we can trim it down without losing key information.

7. Anything else you want to raise, please add it to this thread so we can form a rough agenda... In particular, the document is large and we keep adding to it. Please critically review BPs and identify any that can be cut (don't provide sufficient value) / need expansion (are too woolly) / can be refactored (have significant overlap with other BPs).


thanks,

Adam.

Received on Wednesday, 15 October 2008 14:05:27 UTC