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

Funnily enough I am not unsympathetic to this view and I, for one, would 
like to see more in the document about this.

One of the themes that the document espouses is that it develops the 
dangling BP1 "Exploit Device Capabilities", which immediately suggests 
that you need to know what those capabilities are.

In any case it has (I think) been agreed that we will collect together 
as an Appendix a list of properties that are implied by MWABP, i.e. "in 
order to do these things you need to know these attributes of the 
devices". That could be a vocabulary or a starting point for one.

I agree with your point that this is established practice, even if the 
Simple API is not yet established. In fact BP1 refers to this topic but 
does not dwell on it.

Jo

On 15/10/2008 15:15, Rotan Hanrahan wrote:
> Naturally I have a certain sympathy for what José has said (having chaired the work that led to the aforementioned API). In order to head-off the inevitable comment that the "DDR Simple API" cannot be a best practice because it is so new that few people have had time to make it a practice, I wish to point out that the "technique" itself (that of using device capability knowledge at the server) is an established practice and its use is growing. The creation of a standardised API for this technique is part of the path towards it becoming a best practice, for the appropriate circumstances, and it would be most beneficial if W3C could draw attention to it.
> 
> The API is expected to become a Recommendation soon, at which point we hope to see more adoption (and more vocabularies to go with it).
> 
> ---Rotan.
> 
> [1] http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/
> 
> 
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of JOSE MANUEL CANTERA FONSECA
> Sent: 15 October 2008 15:05
> To: Adam Connors; MWI BPWG Public
> Subject: RE: MWABP stable draft for F2F (no update I'm afraid).
> Importance: High
> 
> 
> 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:27:55 UTC