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

> Jo suggests defining an ADC, but doesn't say so :-) (Enumerating
> capabilities and dealing with them is kind-of, defining an ADC)

I hadn't meant to do that, so apologies if I was unclear.

The crucial difference, I think, is that the capabilities listed may or
may not be present in any particular device and need to be treated on an
individual basis. i.e. you can't "develop for an ADC", you have to
develop for advanced features on a piecemeal basis.

Jo

> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Scheppe, Kai-Dietrich
> Sent: 17 April 2008 08:53
> To: 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]
> 
> 
> Hi,
> 
> This really is an interesting issue.
> Chaals argues from the browser point of view - understandable but
there
> is more to the issue
> Jo suggests defining an ADC, but doesn't say so :-) (Enumerating
> capabilities and dealing with them is kind-of, defining an ADC)
> 
> I perceive the expectation of the community to be:
> 
> - Not having to deal with a plethora of devices.
>   It's a pain and while companies that do content adaptation do a
> marvelous job, life would be easier if we didn't need their services.
>   No, having an ADC would not alleviate the necessity for content
> adaptation, but having an ADC may make life easier for many authors.
> 
> - Ease of use.
>   If there is a set of capabilities that ought to be taken into
account
> by an author, then they would feel good as we assume they will while
> using the checker, then everything else on top is gravy.  It's simply
> easier to have a defined target than having to deal with the open
ended
> question of optimization for individual devices
> 
> - Creating decent content without CT
>   Most people do /*not*/ have access to CT and unless we provide a set
> guidelines in the form of an ADC they will have to guess how to
> structure their content.
> 
> - Refocussing on the devices in general
>   The ADC would dispell some of the hype around iPhone by putting
> content creation on a solid base of instructions, derived from general
> devices.
>   Furthermore we could also take Android and that potential fallout
into
> consideration
> 
> 
> Kai
> 
> 
> 
> > I find myself in strong agreement with Mr McCathieNevile.
> > [Whoa! Hang on .... OK - having carried out a preliminary
> > sanity check, I still find myself in strong agreement]
> >
> > The reason we dropped ADC was exactly as he says. There is no
> > real prospect of resurrecting it, in my opinion.
> >
> > As discussed previously, and as mentioned en passant in the
> > Abstract of the document, it is to a substantial degree a
> > follow up to BP1, especially where it teasingly says:
> > "Exploit Device Capabilities" but then doesn't say what type
> > of capabilities nor how to exploit them.
> >
> > So this document should
> > i) enumerate the capabilities, (that's sort of what the first
> > appendix is there for I think, so we can list what a DDR
> > would have to store)
> > ii) suggest how to determine their presence (other than by
> > looking it up in a DDR) and
> > c) say how you can use them to good effect.
> >
> > This process I think also covers Jeff's 1990's style points
> > about upgrading and degrading gracefully. So 1996 or not -
> > that's absolutely what we are saying is good practice.

Received on Thursday, 17 April 2008 08:06:24 UTC