- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Fri, 18 Apr 2008 09:57:57 +0100
- To: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
> -----Original Message----- > From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On > Behalf Of Charles McCathieNevile > Sent: 18 April 2008 02:27 > To: Scheppe, Kai-Dietrich; Mobile Web Best Practices Working Group WG > Subject: Re: ISSUE-245 (ADC The Un-Dead): ADC, A Wooden Stake and Some > Garlic Needed [Mobile Web Applications Best Practices] > > > On Thu, 17 Apr 2008 17:54:30 +0200, Scheppe, Kai-Dietrich > <k.scheppe@telekom.de> wrote: > > > As per ACTION-737 I am going to do what I was already doing :-) > > > > I propose that we do come up with a means to exploit every capability, > > but should also take a subset of those capabilities and create a typical > > device of todays day and age. > > So long as you set the requirement up front that it comes out compatible > with Opera mini and Opera mobile I could live with that. Otherwise, I > cconsider that the discussion will take too much of the working group's > time, and not be able to move as fast as devices today, and that it is > therefore a rat-hole worth avoiding. An altogether less vendor-centric perspective on this is that we do state that it is good practice to classify devices according to the perspective of your application. http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile -bp2-20080409#bp-devcap-classify Further we go on to look at an example of such a classification in a (should be non-normative) Appendix. http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile -bp2-20080409#device-classification So I think that the combination of the above and the spelling out of the characteristics of interest goes close enough to the objective of helping people target their implementations without getting into the muddle that I think most of us agree would be introduced by trying to define a specific ADC. Look at it as a "soft ADC" perhaps. > > > I believe that we should ask some questions regarding the intent of BP2: > > > > - is it merely a guideline on how to create good content with devices of > > today? > > Not quite. It describes how to improve content by using capabilities that > are *sometimes* or *often* available today, without wrecking the > interoperability of the content by doing something as limiting as > designing for a single browser on a single device. Agree with Chaals here. > > > - do we implicitly state that any modern device will make a reasonable > > online experience possible? > > no matter how badly the content is put together? > > Of course not. There are a zillion ways to get things wrong - even > following all our good advice. We cannot anticipate all of them. But there > are some known ways to improve on common design patterns that are flawed, > and design patterns that are known to be bad. We can advise how to avoid a > bunch of pitfalls and how to take advantage of some good possiblilities. > > Most modern devices have a number of browsers and other pieces of software > available, so referring to a device is a bit misleading. (I have seen it > used to turn statistics into really clear outright lies). > ditto > > - do we willfully refrain from helping authors who cannot use content > > adaptation by giving them a grouping of guidelines to adhere to? > > After all, which devices can do what > > Yes, because otherwise not only do we have to have Device Description, but > we will have to spend a lot of time keeping an up to date repository and > then even more time arguing about which browsers and devices we are going > to put on our "in" list. > I think Kai makes a very good point that needs to be spelled out: YOU REQUIRE SOME KIND OF ADAPTATION FOR BP2 TO BE MEANINGFUL i.e. there is no prospect of "Exploiting Device Capabilities" without selectively enabling or disabling those aspects of your content that aim to exploit capabilities not present in all devices. That's not to say that server-side adaptation is required in all cases. Client side adaptation takes its place in the sun in this document [though not at the expense of page weight, of course :-)] > > - since technology will move on, whatever we write today will be > > outdated to tomorrow. > > Do we think we will not be able to set a new bar, to define a new ADC > > when some other group comes along later? > > I don't think we can set an ADC now and get consensus before what we say > is outdated. I don't think a later group will be able to do so either. > I don't think it is merely a question of pragmatism. Defining an ADC is "Design for iPhone Only" think. In that respect: "ADC Considered Harmful" Jo
Received on Friday, 18 April 2008 08:58:42 UTC