W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > January 2009

RE: [minutes] CT Call 6 january 2009

From: Eduardo Casais <casays@yahoo.com>
Date: Tue, 13 Jan 2009 06:24:31 -0800 (PST)
To: public-bpwg-ct@w3.org
Message-ID: <545987.27709.qm@web45005.mail.sp1.yahoo.com>

This kind of proposal risks leading us down a path that 
will take quite a lot of time to travel. 

Let me consider the various elements in turn.

1.	Explicit permissions.

The suggestion:

> *  if the user has given explicit permission to the 
>    CT proxy to apply transformations to mobile sites.

is already covered by section 4.1.5.3 -- if the user 
selects a restructured experience when having the 
choice, then that is what will be delivered.

2.	Usability modifications.

Suggestion:

> *  in cases where the transformation is needed in order
>    to make the site useable  

Usability assesses the ease of operation of a user interface, and it is quantitatively measured by 
a) how quick it is to learn the application,
b) how efficiently one can use it afterwards,
c) how fast one can re-learn the application after not 
using it for some time,
d) how many errors users make and how easy they recover 
from them,
e) how pleasant it is to use the application.

Substantiating individual transformations based on usability
considerations obviously entails quite some work. If there
are some generic automatic transformations that can be 
considered as usability improvements a priori, it would be 
interesting to know what they are.

Besides, one must not forget that it is the usability of the
accessed application that must be assessed (and improved) -- not some extraneous functionality or 
application.

3.	Corrections.

The suggestion:

>    and/or display properly on the user's device,

revolves around compensating for errors in the way a 
mobile browser renders mobile content. 

Mobile browsers do exhibit quirks. Application providers 
that generate content based on a recognition of the requesting
terminals often take these into account (on the basis of 
advanced terminal capability databases or special tools).
Thus, because Openwave browser ignored the <title> markup,
applications tended to repeat the title string in the text
content for those devices using Openwave software (or even
systematically, for all browsers). Some early Sony Ericsson
browsers did not display all options in a selection list
(under some specific conditions I no longer remember, but
that had to do with the pre-selection of options).

The whole difficulty is that there is no reliable way to 
identify whether an application has already taken care of
potential issues on the device side and adjusted delivered
content accordingly. Duplicating these adjustments, or 
supplementing them with other adjustments with the same
intent most probably degrades, rather than improve, the 
end result.

But once again: automatic transformations that would 
compensate for device discrepancies in a consistent and 
reliable way are in principle legitimate -- just hard 
to come by.

4.	Examples.

This examples:

> *  The user may want to see a toolbar to make it easier to 
> access CT features (e.g., bookmarks, history, etc.).
> *  The user may want links to be rewritten so that all 
> content continues to flow through the CT proxy (even if there 
> is no visual change to the content).  This avoids the problem 
> of accidentally following a link to a regular desktop page 
> that can crash the browser and/or phone. 

are not quite on the mark.

The first one clearly means that the end-user has explicitly
chosen to rely upon a restructured experience -- which is 
provided for by the CTG as indicated in point (1) above. 
Notice that the suggested transformation assumes something 
about the capabilities of the browser (toolbars), does not
make the site accessible (it is already a mobile site), 
does not make it more usable (bookmarks and history are
extraneous functions), and does not correct for device
discrepancies (it adds functionality, it does not correct
errors).

In the second case, 
a) If the user has chosen to or can only browse without a
CT-proxy, then tough luck; this kind of problem occurs on the 
desktop Web as well -- I have had my share of sites sending
my desktop browsers into a tailspin, too.
b) If the user has explicitly chosen a restructured experience,
i.e. explicitly selected to go through a CT-proxy, then there 
should be no problem: everything will be transformed.
c) If not (i.e. the user wants unadulterated mobile browsing
but Web accesses are mediated by a CT-proxy), then there should 
be no problem either. As I demonstrated in a previous message, 
link rewriting within the mobile page is not required in this 
case -- the proxy can simply wait for the HTTP request 
corresponding to the problematic URL, retrieve the content, 
figure out that it needs to be transformed to a mobile format, 
and then return it to the terminal.

5.	Intended effects.

Tom Hume asks:

> After all, would anyone deploy a transcoder with the  
> intention of doing anything other than improving the 
> user experience?

First of all, I note that "user experience" is not formally
defined, and that it appears that everybody seems to have 
a say whether that experience is improved or not, except 
the users themselves.

Secondly, we seem to drift from the major goal of these
content transformations: making sites accessible to end
users, i.e. (from the W3C pages) providing equivalent 
content that fulfills essentially the same function or 
purpose upon presentation to the user as the original,
which, as such, cannot be operated upon by the end-user.

Transforming a desktop site to a mobile content
is an accessibility improvement; transforming mobile 
content to mobile content (or desktop content to
desktop content for that matter) exceptionally makes
accessibility possible. I gave one of the rare examples
of this: eliminating garbage before XML declarations;
notice that this neither modifies the look and feel,
nor the control flow, nor the usability of the application
-- it just makes it accessible (otherwise, most browsers
just refuse to render the content). 

Finally, there are indeed superior reasons that go against
an "improved user experience", but that would have to be
implemented: legal ones. Many countries implement, or 
mandate the implementation of filtering proxies that 
expurgate all content deemed to violate family values / 
State security / prohibitions against racism / the honour 
of the Monarchy / the sanctity of the Religion / the 
infallibility of the Party / etc. 

If we want to make a detailed list, we will have to deal 
with this case, too. I am not sure the discussions can be 
kept short.

E.Casais


      
Received on Tuesday, 13 January 2009 14:25:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 January 2009 14:25:55 GMT