RE: MWABP: Revised text for Device Capability Detection.

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.