RE: [minutes] CT Call 6 january 2009

[Moving this thread to public-bpwg since that seems to be where we are
supposed to post now.]

Comments inline below.

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Eduardo Casais
> Sent: Tuesday, January 13, 2009 8:25 AM
> To: public-bpwg-ct@w3.org
> Subject: RE: [minutes] CT Call 6 january 2009
> 
> 
> 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.

True, if the user has requested a restructured desktop experience, HTTP
requests will be made with altered headers and the user will view
transformed versions of desktop sites (except for sites that would
prefer that the user see the mobile version).

However, if the user prefers to have a mobile experience, then the user
will see the mobile version of sites that have both a mobile and desktop
version.  In that case, the user may still want some "light
transformation" applied to mobile sites--assuming that content provider
has not disallowed transformation with a "no-transform".  This is the
user choice I am proposing.


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

I was thinking more in terms of transformations to fix things that
plainly don't work on a particular device, not trying to improve the
usability of a site in general.  However, there may still be some
general things that could be done, e.g., detection of phone numbers.

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

Obviously, a CT proxy wouldn't want to make a transformation to remedy a
problem that has already been compensated for by the CP.  CT proxies
look for conditions in the markup that would cause a problem on a
particular device or group of devices.  If the problematic condition
does not exist or it is ambiguous whether the CP has already corrected
for the condition, then probably no transformation should be made.

There are some transformations that almost always make sense, however.
For example, a page designed for high end phones like the N95 might
require pagination to work on a less capable device.

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

As mentioned above, the user may not have requested a restructured
desktop experience, so the user will get mobile sites.  The user may
still want some transformation--like toolbars.  The fact that this adds
functionality and doesn't correct device discrepancies is probably of no
concern to the user.

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

True, but browsing without a CT proxy is out of scope for the CT
guidelines.

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

Correct.  All sites will be transformed except for sites that signal
that they don't want to 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.

This is true if all traffic between the device and the CP goes through
the CT proxy.  However, in deployments where the CT proxy depends on
links to be rewritten to receive traffic, this won't work.  If the
mobile page contains a link to a desktop site that isn't rewritten, the
CT proxy is taken out of the equation and is not able to transform the
response.


> 
> 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 Thursday, 15 January 2009 00:11:13 UTC