Re: ACTION-551 Re: Content Transformation Action Items

Once again I'm jumping on this a bit late.
I like most of the text proposed here. I think it should be merged  
with the one proposed by Sean plus, of course, my comments. ;)

I think the problem of HTTPS is an important one. I am not convinced  
users would be happy to know that a proxy somewhere on the internet  
is reading their SSL connection, transforming the content and  
delivering it without SSL to the client. Especially if it's a proxy  
in the open internet like Google's, I don't think users would be  
happy about it.
My conservative suggestion is that if SSL is required the proxy  
either lets the user-agent go and try OR alert the end user that a  
content possibly unsupported was requested and let the user decide  
what to do. I'm sure clients of Bank of America, Citibank or Fineco  
(if you're in Italy) would not be happy to have a proxy in the middle.

I haven't seen any text, so far (and I might have missed it since I  
joined only very recently) that tells how a transcoding proxy should  
recognize a mobile page. I think mobileOK is a good starting point.  
The group is also working on an open implementation of the checker  
and that is one possible good plug for everyone. Also an approach  
like dotMobi's ready.mobi where sites get a score, is a good one.  
Using ready.mobi as an example where sites get a score from 0 to 5  
where 5 is the best, a transcoding proxy might decide that anything  
that scores below 4 is not mobile-friendly.
I think that the document should have some direction towards at least  
some key elements that are considered clear identifiers of a mobile- 
friendly or -unfriendly site.

The mention of external CSS might need some tuning to be more in line  
with what is in the best practices.

- Andrea


Il giorno 02/ott/07, alle ore 16:19, Jo Rabin ha scritto:

>
>
> Reposting as ACTION-551 for trackbot
>
> -----Original Message-----
> From: Aaron Kemp [mailto:kemp@google.com]
> Sent: 22 September 2007 21:06
> To: Jo Rabin
> Cc: public-bpwg-ct@w3.org
> Subject: Re: Content Transformation Action Items
>
>> A gentle reminder, folks, that the action items on the Transformation
>> Guidelines are now past due.
>
> Apologies for not getting this done on time.
>
> I have not had time to do anything with 2.2, but I have some  
> content for
> 2.3.
>
> A version is available online [1] but I have included the text in this
> message as well.  Since this is the first time I have contributed to
> such a document, I hope it is at least somewhat appropriate.
>
> 2.3 Guidance for Content Transformation Server Developers
> Most mobile devices have a limited capacity for receiving and
> displaying content that was originally designed for a desktop browsing
> environment.  A content transformation server may be used to adapt
> desktop content in such a way that it may be successfully retrieved
> and rendered by a mobile device.  A few of the well known limitations
> include:
>
>     * Poor or non-existent support for markup other than well-formed
> XHTML
>     * Limited image format support (eg, JPEG only)
>     * Limited memory capacity for document retrieval and processing
>     * Poor or non-existent HTTPS support
>     * Poor or non-existent CSS support
>
> In many cases, sending a mobile content that it was not prepared to
> process will cause serious failures, often forcing the user to reset
> the device.  A content transformation server can ensure that the
> content will be suitable for display on the device, allowing the user
> to access the information they desire.
>
> Even in cases where no actual content transformation is strictly
> necessary, a content transformation server can improve the experience
> greatly by reducing the amount of data that must be transferred to the
> mobile.  Decreasing the number of connections required by in-lining
> style sheets and other resources can also dramatically reduce the
> amount of time spent retrieving and rendering page content.
>
> Some websites provide a mobile alternative that is suitable for
> display on some mobile devices.  Unfortunately, the vast majority of
> websites do not, and those that do often cater only to a small subset
> of the mobile devices that are in active use.  Furthermore, many sites
> actively detect and divert non-desktop browsers to "incompatible
> browser" pages and the like, preventing the user from seeing any
> content at all.  In these situations, a content transformation server
> that "pretends" to be a desktop browser on behalf of the mobile can
> provide a better experience by retrieving and processing the original
> desktop-oriented site.  In the event that a website author does
> provide a viable mobile alternative, any content transformation
> servers in the delivery chain should recognize this content as
> acceptable for mobile display and not attempt to modify it.
>
> In order to increase the chances that a website will provide a viable
> mobile alternative, content transformation servers should preserve and
> pass on any information about the delivery context that is available.
> This includes but is not limited to preserving the HTTP User-Agent and
> Accept headers.
>
> [This is an issue I am not actually sure what we want to do about.  On
> the one hand, we need to present valid device information to the
> origin server so that it may provide a mobile experience, but we also
> want to masquerade as a desktop browser to cover the (much more
> common) case where the site will refuse to send content for unknown
> user agents.  There are several possible strategies, but we will need
> to come up one that we can all agree on to present here.]
>
> [TODO: Details of how content transformation servers communicate with
> the rest of the delivery chain]
>
> ----
>
> [1] http://docs.google.com/View?docid=dgx7k6xj_22d62rh5
>

Received on Tuesday, 2 October 2007 15:19:54 UTC