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