RE: MWABP: Revised text for Device Capability Detection.

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.

 

To address the "real point" of this thread, I will offer some text that I hope will be useful for this section.

 

- - -

 

3.6 Handling Variations in the Delivery Context

 

Variations in the delivery context (such as different device capabilities) is a prominent feature of the mobile Web. Web applications should adapt to known or discoverable properties of the delivery context by adjusting the content, navigation and/or page flow,  with a view to offering a good user experience on as broad a range of devices as possible.

 

3.6.1 Use Server-side Detection Where Possible

 

3.6.1.1 What it means

 

Where possible, use the evidence available from the interaction with the Web client to determine the properties of the delivery context, and adapt the responses to the client before transmission, thus improving the user experience and avoiding transmission of unnecessary/incompatible data.

 

3.6.1.1 How to do it

 

In its most basic form, the minimum evidence from the client device is the HTTP Accept header. In practice, this evidence is insufficient to determine the key properties that will help to select/adapt the content appropriately, so additional headers or other sources of information should be considered. Typically, the following headers provide evidence of device capabilities:

 

·         Accept header: this list of MIME types can aid in the selection or creation of alternative content representations to suit the requesting device. The header is not always reliable, especially when its value is "*/*", suggesting that the client can accept every MIME type.

·         User-Agent header: as a generally unique (albeit opaque) string it can be used as a key into a device descriptions repository (DDR). The set of properties recorded in these repositories will vary from implementation to implementation. The W3C DDR Simple API defines a common interface and a means of expressing the vocabulary of properties for such repositories.

·         X-Wap-Profile header: this is a reference to the User Agent Profile (UAProf) for the requesting device. In practice, the  referenced profile is not always guaranteed to be available, valid or up-to-date, so the value of this header is sometimes used with a DDR where corrections to the profiles are stored.

 

3.6.2 Use Client-side Detection Where Necessary

 

3.6.2.1 What it means

 

Where it is not possible to determine certain properties of the delivery context from the server, this information may be available at the client. Once obtained at the client, the information can be used on the client to adapt the presentation or it can be sent to the server for server-side adaptation.

 

3.6.2.2 How to do it

 

There are several client-side solutions available to the developer:

 

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

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

 

For the foreseeable future, JavaScript "sniffing" will continue to be the dominant client-side technique.

 

 

- - -

 

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.