Re: MWABP: Revised text for Device Capability Detection.

Thanks Jose, very useful.

I will look at wording along the lines you suggest.

Regards client-side detection -- I have no particular objection to cutting
this BP, in its current form it's probably misleading (perhaps we can
resolve to do this on Tuesday unless anyone objects). It emerged from some
progressive adaptation text we had that was too detailed to be included in
full. Using a bootstrap javaScript file *is* a pretty standard and useful
technique [1,2] (which is what this BP is really driving at in a roundabout
way) but it's not really about adaptation and is sort of covered in other
parts of the document.


1.
http://caridy.name/2009/05/bootstrap-using-yui-loader-and-yui-get-utility/
2.
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ_WhenDoModulesLoad


On Fri, Jun 19, 2009 at 8:40 AM, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>wrote:

>  Hi,
>
>
>
> Various comments on this:
>
>
>
> 1) The name of the best practice "capability detection" is not very correct
> from a more formal point of view. I would prefer "Dealing with variations of
> Delivery Contexts". Also I have my concerns as the term "capability" sounds
> biased to an specific DDR (WURFL) and I would prefer using a more "vendor
> neutral" term.
>
>
>
> 2) This phrase it is not correct and needs to be improved:
>
>    - " 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;
>
> It seems that you are saying is that first you need to analyse the
> User-Agent header, figure out what it is the device and afterwards call a
> DDR to get the device properties. This is not actually the case. Typically
> DDRs contain information about User-Agents and their matching to specific
> devices. That means that in practice the only thing you need to do is to
> call the DDR passing a "Context Key" (evidence) which it si typically the
> HTTP request and then you get the properties. This is how things work in the
> DDR Simple API [1]
>
>
>
> Regarding the usefulness, being aware of the context is a needed feature.
> So the detection of the Delivery Context is  a must
>
>
>
> What I have my serious doubts is on the text you provide on client-side
> detection of the Delivery Context. IMHO it says nothing and should be
> dropped unless you provide better content, explain it in more detail or
> provide a rationale for including it.
>
>
>
> [1] http://www.w3.org/TR/DDR-Simple-API/#sec-Service-getPropertyValues-1
>
>
>
>
>
> *De:* public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] *En
> nombre de *Adam Connors
> *Enviado el:* jueves, 18 de junio de 2009 17:39
> *Para:* Eduardo Casais; Mobile Web Best Practices Working Group WG
> *Asunto:* 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.
>
>
>