RE: MWABP: Revised text for Device Capability Detection.

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.