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

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