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

On Fri, Apr 18, 2008 at 6:22 AM, Scheppe, Kai-Dietrich
<k.scheppe@telekom.de> wrote:
>  I believe, if we keep going as we have been, we will create a set of
>  useful guidelines to exploit single capabilities of devices. Yes.
>
>  How much of this somebody implements is up to them.  The document will
>  be useful, but will not change much in the Web.
>  It will be limited to a few content providers who have CT at their
>  disposal.

I basically agree, but state it differently:

I don't think it's impossible to write tests for a batch of
conditional best practices ("if devices supports A, then do B,
otherwise do C").

But I do think it's hard because then we must, for each "A", define
how to detect "A", and I do not see much if any writing on that yet,
which makes me suspicious about whether it will appear, especially for
some capabilities which I don't know how to detect. Then we have to
write tests for "A supported" and "A not supported". And you can't
pass unless you are explicitly handling both cases; it's not enough to
ignore whether A is supported.


And if all of your "A"s add up to a pretty clear profile, I wonder out
loud whether it isn't worth saying what it is you're implicitly
defining in the first place.

People keep saying "don't make this a design-for-iPhone doc!" While
brand names should of course be left out, if this is basically what
we're doing, it would be far more useful to make this clear. I do feel
we're taking pains to make this hard to grok to the developer
community.

BP1 quite elegantly said, given a certain fictional but realistic and
easily understood profile, what should and shouldn't you do? BP2 could
and should quite naturally be about a different and more timely
profile. Trust me, people will try to understand BP2 as "BP1, but for
a more capable profile" because that is the most manifestly natural
thing to think about it. I appreciate the arguments about writing
less-specific things, but, sometimes more specific is better; I think
this is a lot of work and thinking going towards making this document
hard to understand to a lot of people.


Sean

Received on Friday, 18 April 2008 11:05:03 UTC