Re: MWABP: Revised text for Device Capability Detection.

On Fri, Jun 19, 2009 at 10:58 AM, Rotan Hanrahan <
rotan.hanrahan@mobileaware.com> wrote:

>  Again, I don’t agree (and not just for the sake of not agreeing, which
> certainly would not be my style). As José has pointed out in a separate
> response, the real issue is about awareness of delivery context (of which
> “capability detection” is part). To assume that all delivery contexts are
> the same would be to deny the possibility of variation, which is counter to
> the idea of the Web (given its aim to available everywhere, to everyone and
> on every device). The fact that the original Web (as implemented by Tim) was
> rather homogeneous does not necessarily mean that this is “good” and that
> heterogeneity is “evil”. It was merely convenient at the time. As the Web
> matured, browser diversity expanded. The diversity wasn’t managed properly,
> and we ended up with various hacks to give the Web servers some awareness of
> the delivery context. I concede that the hacks were “not good” but the idea
> of detecting the context in order to have the opportunity to deal with it
> has been there for a long time, intentionally.
>
> Good points. My knowledge is enriched.

> To address the “real point” of this thread, I will offer some text that I
> hope will be useful for this section.
>
> Greatly appreciated. I'll drop this text into the next draft now.

> ·         JavaScript: this is the most common solution. A script
> determines the device/browser properties and either manipulates the content
> via DOM access methods, or sends the gathered information back to the server
> via a HTTP request. Typically the delivery context information is gathered
> at the start of the session, though dynamic information (e.g. the current
> screen orientation) will need to be refreshed during the session. The Ajax
> design pattern makes extensive use of this technique.
>
Within JavaScript the two things you can do are i) adapt on the device; ii)
request the appropriate / alternative content from the server. I'll expand
this point a little as I think the differences could be clearer.

> ·         DCCI: the “Delivery Context: Client Interfaces” (DCCI) is a
> recently introduced W3C specification that enables client-side access to
> device information via DOM methods. It is not yet widely supported, but if
> adopted it will help to improve the implementation and interoperability of
> script-based solutions as described previously.
>
> ·         OMA DPE: the OMA Device Profiles Evolution is an enhanced device
> profiles technology that will enable real-time conveyance of dynamic device
> information from the client to the server. Information can include available
> memory, battery life, screen orientation, mute status etc., which together
> with other known delivery context information will greatly enhance the
> possibilities for adaptation. The OMA DPE specification is expected to be
> released soon.
>
I'm not sure that "JavaScript" and "DCCI" work as sibling bullet-points like
this... If DCCI is essentially the addition of new DOM methods then it's a
subset of the JavaScript bullet-point... I'll have a go at rearranging to
keep the text but not present as parallel bullet-points and we can iterate
in the next draft.

Thanks for the text.

Adam.


>
>
>
> - - -
>
>
>
> I offer this text as a starting point.
>
>
>
> ---Rotan.
>
>
>
>
>
>
>
> *From:* public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] *On
> Behalf Of *Adam Connors
> *Sent:* 18 June 2009 17:54
> *To:* Rotan Hanrahan
> *Cc:* Eduardo Casais; Mobile Web Best Practices Working Group WG
> *Subject:* Re: MWABP: Revised text for Device Capability Detection.
>
>
>
> It's a necessary evil insofar as it *shouldn't *have been necessary in the
> first place.
>
> But the real point is that this is a call for some useful text for this
> section so if you can frame the information you offer below in the form of
> appropriate BPs for 3.6 that would be immensely useful.
>
> Thanks,
>
> Adam.
>
> On Thu, Jun 18, 2009 at 5:29 PM, Rotan Hanrahan <
> rotan.hanrahan@mobileaware.com> wrote:
>
> I object to this sentiment: “device capability detection remains a
> necessary evil”
>
>
>
> Improving the awareness of the delivery context is not evil. It is a
> valuable addition to the process of enhancing the service offered to Web
> users. Some of the means of achieving this awareness have been somewhat
> “hacked” in the past, such as some ugly JS embedded on the page with lots of
> if-else-if-else-if…, which one might characterise as “evil” insofar as this
> approach is hard to maintain, but with the creation of better mechanisms
> such as DCCI, OMA DPE and (blowing a well-polished trumpet) the W3C’s own
> DDR API, device capability detection is angelic by comparison.
>
>
>
> ---Rotan.
>
>
>
> *From:* public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] *On
> Behalf Of *Adam Connors
> *Sent:* 18 June 2009 16:39
> *To:* Eduardo Casais; Mobile Web Best Practices Working Group WG
> *Subject:* MWABP: Revised text for Device Capability Detection.
>
>
>
> Hi Eduardo (and rest of group),
>
> I have been working through my TODOs for the next draft of MWABP. Eduardo
> raised some very interesting points regarding 3.6 Handling Device Capability
> Variation. Here is the revised text. My general feeling is that what is
> being said here is correct, but not necessarily useful...
>
> The thing that is limiting the usefulness is that the really useful things
> we could say are probably a little low-level / technical / specific to be
> useful and there is much that can be said in general terms on this topic
> (except that device capability detection remains a necessary evil). If
> anybody has any ideas about what we are trying to express here your thoughts
> would be appreciated.
>
> Regards,
>
> Adam.
> 3.6 Handling Device Capability Variation
>
> Device capability variation is a basic characteristic of the mobile Web
> environment. Web applications should adapt their content such that they
> render as well as possible on as broad a range of target devices as
> possible.
> 3.6.1 Prefer Server-side Capability Detection 3.6.1.1 What it means
>
> Where possible it is preferable to detect device capabilities and
> characteristics on the server and adapt content before it is sent to the
> client in order to avoid transferring unnecessary data.
> 3.6.1.2 How to do it
>
> Typically used methods of device capabilities detection:
>
>    - The "User-Agent" header can be used to identify the device, and a
>    Device Description Repository (DDR) can be used to retrieve a detailed
>    description of capabilities;
>    - The "Accept" header can be used to indicate specific MIME types
>    compatible-to/preferred-by the device;
>    - The "X-Wap-Profile" header (User Agent Profile or UAProf) can be used
>    both as device identification and as a source of detailed device
>    capabilities.
>
> 3.6.2 Use Client-side Capability Detection Where Necessary 3.6.2.1 What it
> means
>
> For some device characteristics where the configuration is not known on the
> server application behaviour can still be adapted based on capability
> detection on the device.
> 3.6.2.2 How to do it
>
> Use JavaScript to determine device characteristics (screen size,
> orientation) or if a given API is active. Two methods can then be used to
> adapt on the client to differing configurations:
>
>    1. Encapsulate the different behaviours in the control logic of the
>    application. E.g. simply use: if (some_configuration_variable)decision-points in the code and behave accordingly;
>    2. Use an initial "bootstrap" script to assess device capabilities and
>    request the appropriate application bundle from the server.
>
> Option (1) is simpler to implement and is appropriate provided the amount
> of inactive code downloaded doesn't have a negative impact on performance.
> Option (2) is preferred when the application must change significantly in
> response to properties that can only be determined on the client.
>
>
>
>
>