W3C home > Mailing lists > Public > public-bpwg@w3.org > April 2008

RE: ISSUE-245 (ADC The Un-Dead): ADC, A Wooden Stake and Some Garlic Needed [Mobile Web Applications Best Practices]

From: Jo Rabin <jrabin@mtld.mobi>
Date: Fri, 18 Apr 2008 09:57:57 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4ED313F@mtldsvr01.DotMobi.local>
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]
> 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
> > but should also take a subset of those capabilities and create a
> > device of todays day and age.
> So long as you set the requirement up front that it comes out
> with Opera mini and Opera mobile I could live with that. Otherwise, I
> cconsider that the discussion will take too much of the working
> 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.


Further we go on to look at an example of such a classification in a
(should be non-normative) Appendix.


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
> >
> > - 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
> 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
> > 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
> are some known ways to improve on common design patterns that are
> 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
> Most modern devices have a number of browsers and other pieces of
> available, so referring to a device is a bit misleading. (I have seen
> used to turn statistics into really clear outright lies).

> > - do we willfully refrain from helping authors who cannot use
> > 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,
> we will have to spend a lot of time keeping an up to date repository
> then even more time arguing about which browsers and devices we are
> to put on our "in" list.

I think Kai makes a very good point that needs to be spelled out:


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
> > when some other group comes along later?
> I don't think we can set an ADC now and get consensus before what we
> 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"

Received on Friday, 18 April 2008 08:58:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:51 UTC