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

Yes, and noted that this is thanks to your probing questions.
 
Let's make sure that when we have decided we know what we are talking
about that we take care to capture the discussion and present it in an
understandable form, so that we don't end up continually going round in
circles like we have done on the DDC. In fact it would be a good idea to
re-express the meaning and significance of the DDC at the same time.
More on this below ...

> 
> > > > 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?
> 
No, we don't bundle the capabilities. We discuss how the application
designer should bundle capabilities according to the demands of their
application. Some applications might be interested in location and so
they'd be interested in whether the device has GPS, whether it exposes
CellID and so on. This might be of complete irrelevance to a non
location sensitive application which would not feature those facilities
in its bundling.

> 
> 
> > > > 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.
> 
Well, I think this is a bit back to front. My guess is that most people
want to develop effective applications that work well on a reasonable
spectrum of devices. This benefits their business plan. 

I'm guessing that few business plans would benefit from saying that the
purpose of the application will be to gain W3C BP2 Gold Accreditation.
If we provide useful advice to people to help them provide effective
interoperable applications then I think folks will reference the work. 

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

We're not trying to teach people how to be interaction designers,
graphic designers etc. and any of the other skills that are required to
build a good online experience. We are explaining how to build
interoperable applications that use features that may be present only in
varying degrees in different devices.


> 
> 
> 
> >
> > > > - 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.
> 
No, I don't agree. I think that it's as we put it in BP 1:

"... it is possible to create a site that is consistent with the Best
Practice recommendations without carrying out adaptation at all. However
it is likely that a more sophisticated and enhanced user experience will
be achieved if adaptation is used."

So not YOU CANNOT BUILD GOOD MOBILE FRIENDLY CONTENT WITHOUT ADAPTING
IT, more YOU CAN'T USE FEATURES THAT MAY NOT BE PRESENT IN ALL DEVICES
WITHOUT USING ADAPTATION OF SOME FORM. USING THOSE FEATURES CAN
CONTRIBUTE TO AN ENHANCED USER EXPERIENCE.

BP2 is about using capabilities to provide a more sophisticated and
enhanced experience and about detecting whether the facilities are
present and about accommodating their lack of presence or presence in a
non-optimal form.


> 
> 
> 
> > > > - 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 think it is actually quite different in nature. We defined the DDC as
a minimal set of capabilities that must be there to consider a device
Web capable. Consequently we were able to tell designers that they could
rely on their content working if they made DDC assumptions when
preparing their content, because BY DEFINITION a device that could not
handle that is not a Web capable device.

The DDC does not represent a target for development, it represents a
minimum below which developers do not need to stoop. We never said that
the DDC provides for a good online experience, we just said that the
experience on anything less was likely, in general, to be too dreadful
to be bothered about developing for.

mobileOK basic tries to ensure that they stoop that low.

BP2 should be about ensuring that people who want to use advanced
capabilities (and are just targeting the iPhone today) don't just give
up when it comes to any other device and send 406, "Your browser is not
supported." And that they have a clue about what the alternatives are to
that 406 response.

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

No, I think the point is to exploit a set of capabilities that are
relevant to the application in question.

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

No, Adaptation, not Content Transformation, they are different things,
in my view. 

Lots of people have Adaptation at their disposal. Using @media in CSS is
adaptation. Using the fall back capabilities of the Object element is
another means of adaptation [which incidentally is why the fact that we
got its processing wrong in the last draft of mobileOK Basic is so
important to fix]. Testing for the availability of XMLHTTPRequest in
script is also a method of adaptation. 

Server side adaptation is also in the reach of the huge mass of
developers too. That's why we spent a couple of long and sometimes
painful years working on the DDR Simple API.

> 
> 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.
> 
Again, I don't agree. This is about building inter-operable applications
that work across a reasonable variety of devices. It's actually not
really at all about building "great mobile applications" as it says in
the document at the moment, I now realise, thanks to your pointing it
out.

Jo

Received on Friday, 18 April 2008 18:11:12 UTC