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 07:54:02 UTC