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

I see we are having a discussion :-)

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


If I may summarize, we list capabilities, but also come up with bundle
of capabilities that represent a typical device of today?



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


My point is getting a bit turned here.
I was asking about our intent of the document.  Here we leave out any
mechanism to control what people do with the document.  This may be
fine, but will tend to produce no results.

In other words, we toss the guidelines out there and let people fend for
themselves to with it as they wish.
No labels, no trustmarks, no means to demonstrate you have done
something special

If that is what we want then I predict that industry uptake will
imperceptible to slow, as long as it is not clear what the benefits are.
"Benefit" has a strong monetary drift to it 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


The goal was from the beginning to provide a good online experience.  
If we don't say anything how to get there, it cannot be defined what a
"good online experience" is.  

So what are we exactly telling people?  
"...Follow these guidelines. They're cool....no, we cannot tell you how
far you should implement them in order to get good content.
You need to find that out for yourself."

There is some truth in that too.  If we want to say that, then ok.  I
just want us to be conscious of it.





> 
> > > - 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 :-)]


Ok that makes more sense, because we would not be leading people on.
However, the usefullness of BP2 is then greatly diminished.

To sharpen what Jo said a bit:

YOU CANNOT BUILD GOOD MOBILE FRIENDLY CONTENT WITHOUT ADAPTING IT

That, however, is quite a statement towards the masses of authors out
there.




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


Ah but it is precicely that which I wish to avoid!  Currently the group
keeps referring to the iPhone, so we must be careful.
By defining an ADC we focus on real capabilities, not slick interfaces.

But I see the fear lies in attempting to take a stand on what a device
should be able to do in order to provide a good online experience.
That is precicely what we did for the DDC, only this time we should
focus on something a bit more sophisticated :-)






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.

So what will we have achieved, other than creating a business case for
content adaptors?

Sure we will have improved things bit, but I think we would fall short
of the mark.



Kai

Received on Friday, 18 April 2008 10:23:35 UTC