Re: [minutes] CT Call 6 january 2009

Sean,

[I write "Sean", making believe that you will answer this email. I know 
you won't. Novarra has chosen to keep away from discussing in the open. 
This is a very wise choice, I have to admit, because I am not sure what 
sensible arguments they could find in their defense, should they choose 
to really discuss their technologies and business practices openly]

you write:

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

So, in your wildest dreams, you would like to place your transcoder in 
the middle of everything HTTP and fix *everything* because Novarra just 
knows better. But what if a new device is not in your system? what if 
the content owner knows better?

I am not sure why W3C is using its resources to create a selling tool 
for a company which wants to move the web (and the mobile web!) from a 
model in which everyone can create content and everyone else can consume 
that content, to a model in which the original content is mediated, 
transformed and (allow me) bastardized in inscrutable ways totally 
outside of the control of the content owner (and outside of the control 
of users too).

Who is Novarra to decide that my page will not work on a given device? 
Who is Novarra to assume that they can play mobile god? why are we even 
discussing these things here?

Interestingly enough, Vodafone had created a similar model (on a much 
smaller scale) a few years back with PML (Partner Mark-up Language). 
Voda's content partners would author content in PML, and Vodafone 
gateways would pick it up and transform it in the best possible way 
(best according to Voda) for devices on their network. This was 
legitimate. Because it was Vodafone's partners.

The project was mildly successful (they are still using it today, to the 
best of my knowledge), but not successful enough that they would solve 
the need to serve loads of cool content to all of their devices for good 
(people would still prefer independent mobile sites with own custom-made 
mobile UX).
Now, how can anyone think that repeating the same model on a larger 
scale by declaring war on the entire mobile ecosystem is a good idea?

Luca

Sean Patterson wrote:
> [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 17:21:46 UTC