A lovely Easter weekend:

• 4 days of lie-ins, catching up on sleep I'd bartered away over the first 3 months of 2008;
• 3 films - Invasion, Rendition, and Cloverfield - and I found something to enjoy in each of them;
• 2 and a half books read: finally finished Bruce Chatwins Songlines (which was absolutely fantastic), Presentation Zen, and started on The Player of Games (to my shame, the first Culture novel I've read);
• 1 tech sabbath: I switched off my mobile and laptop for Sunday, and kept them switched off. It felt horrific for the first 12 hours, lovely for the second 12 :)

All that plus a night out with the Good Doctor, Dangermouse Dave's birthday bash and a succession of meals and cake.

So now I'm rested and relaxed - a good thing, with a busy few weeks ahead: our fortnightly planning day on Wednesday followed by a Girl Geek Dinner, Mobile Internet in Berlin the following week, Over The Air in London the Friday after I return, the first "Chatham House" software meet the following week and a trip to Airenjuku London (mob-handed, I suspect) to say au revoir to Chris on the 12th April...

I love this article about conquering the galaxy through self-replicating probes (via Mr Jones, I think). I reminds me of trees. In less lucid moments I've often wondered what it must be like to have to grow somewhere in order to go there.

The talented Mr Rieger and I will be presenting on day 1 of Over The Air, an upcoming conference in London focused around mobile development. Expect a gentle stroll through the night sky, courtesy of the Royal Observatory Greenwich and brought to you by SVG, RSS, microformats, open APIs, the WURFL, iCAL, and the one web.

A small cadre of Future Platforms munchkins will be in attendance for the 2-day event - it's looking like a fun couple of days :)

After another conversation on the WMLProgramming mailing list concerning automatic transcoding and proxies, it occurred to me that the debate hasn't moved on a a great deal. The extremely vocal criticism of transcoder vendors by Luca and others, online and offline, hasn't translated into more restrained and considerate development and deployment of automatic reformatting tools from operators: Sprint, Vodafone Ireland, and others have all launched more of these things.

So in a moment of uncharacteristic optimism I wondered what positive steps might be taken to improve the situation, and two thoughts came to mind:

1. Rather than attacking transcoder vendors and operators, perhaps they and developers could jointly agree a few sensible, easily-agreed-upon guidelines which might lead to a better mobile experience for end-users.
2. Whitelists of mobile-aware are being actively used by operators. Whilst I don't personally think that they're a pleasant solution or one which scales up, it might be useful to provide an aggregated whitelist of sites which any operator could freely download and use to augment their own whitelists - i.e. reduce the burden for individual site owners of adding themselves to the whitelists of multiple operators worldwide. This feels in a way similar to the problem that WURFL solves: handset vendors not supplying details of their devices (clearly A Bad Thing).

So, I've set up a short post - which I'll edit over time - to document the former. The latter feels like something which might be best realised using a wiki, Google docs, or more formal tool.

Feel free to comment here or there, or email me direct. This isn't intended to be an exhaustive list, but rather a set of items on which mobile site developers and transcoding vendors/deployers can readily agree; there are undoubtedly better places than this blog to debate the contentious items.

Avoid reformatting pages which are marked as already fit for mobile consumption

Pages may be marked as mobile-ready in one or more of the following ways:

1. The HTTP response returns the a header "Cache-Control: no-transform"
2. The page is on a domain which starts "m.", "wap.", "mobile.", or ends with ".mobi"
3. The page is on a domain which contains the word "iphone" or starts "i."
4. The page is served with the MIME type "text/vnp.wap.wml", or "application/vnd.wap.xhtml+xml"
5. The contents of the page contains one of the following DTDs:

   <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

   <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.1//EN" "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile11.dtd">

   <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN" "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">

If a page indicates it has a mobile-ready alternative, use it

If a page contains the META tag below, redirect to the URL supplied in the HREF instead of reformatting the current page:

<link rel="alternate" type="text/html" media="handheld" href="http://example.mobi/" title="Mobile/PDA" />

Allow mobile sites to adapt their own content

The owners of mobile sites may have already taken steps to adapt their content for mobile consumption. It is likely that if they are doing this, they will make use of the User-Agent HTTP header to recognise the handset being used to access their service. In modifying this header, a transcoding proxy prevents the site from using a well-recognised mechanism to adapt its content for the viewing device.

Others

Other suggestions should live here

Removed

I've removed a few suggestions from the list above, but left them here for posterity (and in case there's a good reason to bring em back!):

• do not adapt pictures (suggested by Luca Passani, Russ Beattie pointed out that photo transcoding is a significant reason to use a transcoder, I'd be inclined to agree - any takers?)
• Do not reformat pages that are less than 30kb no matter what (limit can be a bit lower, but only as long as you can positively tell a feature phone from a smartphone) - again, Russ pointed out that RAZR devices, the most popular in the US, have a 5k page-size limit, so require transcoding.
• do not reformat pages with MIME type "application/xhtml+xml", Russ pointed out this is not a mobile-specific MIME type