Depressing thought: if social networking tools bring us all closer together, what happens when a generation that grew up hyper-connected starts to pass on. How will all this affect the grieving process?

Too many links to write about and Netnewswire is creaking at the seams (well, not really - but navigating 400 tabs gets boring) so here they go - out into the wild.

First off, a load of design-related stories:

• Clive Grinyer: technology doesn't work and design basics>; I was fortunate enough to work with Clive when he was at Orange - a very smart chap;
• Building the UX dreamteam;
• Multi-touch in Safari
• Applying Turings ideas to search;
• Interactions Magazine, which is frankly fantastic;
• Information architecture for audio
• Swype, a new mechanism for text entry on phones
• When not to listen to your customers

Then a pile of development-related stuff I've never gotten around to commenting on:

• Writing testable code
• Circular Dependency in constructors and Dependency Injection
• Singletons are pathological liars
• Where have all the singletons gone?
• Sleeping != synchronisation
• Root cause of singletons
• GrailsCrowd a Groovy/Grails community site;
• Data driven traps
• Test first is fun
• Location-enabling web applications and using OpenCellID
• Yet more GeoWeb with Geode
• Checking code pre-submission
• Where to test?
• Packaging Flash Lite for S40
• Testing all the fucking time: "sometimes you’ll come to a point where you can’t TDD. At that point, I’ll offer some advice… you most likely don’t understand the problem as well as you think you do. What you may need to do is try it again from a different angle or maybe you need to think larger and stop scoping so small."
• How Flickr does queueing
• Lessons learned building an iPhone site
• James has noticed more Vodafone proxy nastiness - minify and downgrading images, something I think Orange has done for a while now too...
• Mocking out your environment

...mobile industry bits and bobs worth noting:

• Google CEO Schmidt: ‘We Can Make More Money In Mobile Than We Do On The Desktop’
• 8 million iPhones and counting!
• Nice Guardian article on the Flip
• The US overtakes Europe in 3G takeup
• Independent app store Phoload launches
• Nice piece from David Wood on Opera Mini and mobile web browsing;
• Google still dreams of mobile money-making; my favourite quote: "we've been waiting 13 years now for real mobile Internet monetization, and we're still not seeing where it's going to come from"
• ...and the big G is bundling barcode readers into Samsung devices
• iPhone vs Kindle!
• Mobile banking RSN
• Hutch are launching a handset business focused purely on social networking
• Will the Web 2.0 industry move to pro accounts?
• Opera's state of the mobile web
• Flickr and Geolocation - really interesting piece...

...and finally some related to project management:

• Planning Poker cards from Mountain Goat Software;
• Establishing a common baseline for story points - starting to do our estimation and planning with story points rather than ideal hours is on my TODO list for FP;
• On our project, we're always 90% done;
• How to launch software
• How I learned to love middle managers
• Doing the impossible
• David Wood asks who says design by committee is bad?
• The product managers' lament
• Lean startups vs lean companies

Back in September, I mentioned that I've been invited to work with the W3C Mobile Web Best Practices Working Group, specifically to help with Content Transformation (CT).

It's a really contentious topic. The event which I think provoked the whole discussion was Vodafone foolishly deploying a transcoder which prevented mobile sites from identifying the device used to access them: effectively breaking large chunks of the mobile web. A particularly nasty aspect of this was that the sites most badly affected were the ones which had been specifically written to deliver the best mobile experience.

The W3C CT group is creating a set of guidelines that deployers of transcoding proxies and developers can use to ensure end-users get the best possible experience of mobile content. Involved in this effort are parties from across the mobile value chain, though mostly from larger organisations which tend to participate in these sorts of things. I'm there to try and ensure that smaller parties - content owners and mobile developers - are better represented.

There have been other attempts to put together similar guidelines - the most prominent being Luca Passani's Rules for Responsible Reformatting: A Developer Manifesto, which has quite a few signatures from the development community, as well as a number of transcoder vendors. There's a great deal of overlap between the contents of Manifesto and the CT document. I think this is because the two are concerned with a quite specific set of technologies, neither are trying to invent any new technology, and both have the same aim in mind: to ensure that a repeat of the Vodafone/Novarra debacle, or similar, doesn't recur.

What I like most about the CT document is the responsibilities it places upon transcoder installations, if they're to be compliant - and with Vodafone in the CT group, I think it's reasonable for us to expect them to move their transcoders to compliance at some point. The document is still work-in-progress, but right now some of these (with references) include:

• Leaving content alone when a Cache-control: no-transform header is included in a request or response (4.1.2);
• Never altering the User-Agent (or indeed other) headers, unless the user has specifically asked for a "restructured desktop experience" (4.1.5);
• Always telling the user when there's a mobile-specific version of content available - even if they've specifically asked for a transcoded version of the site (4.1.5.3). I think this is lovely: as long as made-for-mobile services are better than transcoded versions (and in my experience it's not hard to make them so), users will be gently guided towards them wherever they exist;
• Making testing interfaces available to developers, so that content providers can check how their sites behave when accessed via a transcoder (5)

There's also a nice set of heuristics referred to, which gives a hint to content providers of what they can do to avoid transcoding.

The big bugbear for me (since joining the group) has been the prospect of transcoders rewriting HTTPS links, which I believe many do today. I've been told that in practice Vodafone maintain a list of financial institutions whose sites they will not transcode, presumably to avoid security-related problems and subsequent lawsuits - which would seem to support the notion that this is a legal minefield.

The argument for transcoding HTTPS is that it opens up access to a larger pool of content, including not only financial institutions like banks which absolutely need security, but also any site that uses HTTPS for login forms. Some HTTPS-accessible resources do have less stringent requirements than others (I care more about my bank account than my Twitter login, say), but it's not a transcoders place to decide when and what security is required, overriding the decisions a content provider may have made.

The CT group has agreed that the current document needs to be strengthened. Right now it is explicit that if a proxy does break end-to-end security, end-users need to be alerted to this fact and given the option of a fully secure experience. Educating the mass market about these sort of security issues is likely to be difficult at best; I take small comfort from the fact that they'll be given a choice of not being forced into an insecure experience, but this still feels iffy to me.

And security isn't just for end-users: content providers need to be sure they're secure, and beyond prohibiting transformation of their content using a no-transform directive there's not much they can currently do. So I suspect there's more work cut out for us on the topic - and the amount of feedback around HTTPS would seem to confirm this.

The fact that we need to have either the CT document or the Manifesto is a problem in itself, of course: infrastructure providers shouldn't be messing with the plumbing of the mobile web in the way that they have been. But given where we are right now, what are we to do? Luca's already done an excellent job of representing the anger this has caused in the mobile development community; I hope the CT work can complement his approach.

I'm also going to write separately about the process of participating in the group; I've found the tools and approach quite interesting and it's my first experience of such a thing.

So, Trutap has launched a load more IM transports, putting the app well on the path to being the best connected mobile IM service in the world. Not that we can take much credit for this (beyond the front-end and MIDlet which we created) - the server team at TTHQ have done a stirling job here.

But we've been busy beavers nonetheless. All will be revealed in the coming weeks :)

There's so much news right now about mobile applications and stores, it feels like time to take stock.

When iPhone launched and I got my greedy mitts on a jailbroken Shiny from the US, one of the things I liked most about it was the dodgy "installer" app which the kind man who jailbroke it for me put there. At the time it definitely felt like the best experience I'd had of downloading and installing third-party mobile applications, and Apple have gone on to improve on it with their official Application Store.

Conventional wisdom had been that users don't download mobile apps, a generalisation which flies in the face of our experience; we know we've had well in excess of 750,000 downloads of apps incorporating our Cactus UI library to date, plus the installations we're unable to track ourselves. And our experience isn't unique. But there's definitely been some problems taking owners of conventional smartphones through the process of downloading and installing an application:

1. Text into a shortcode
2. Receive a WAP Push or text message
3. Find it, open it, click on the link
4. Ignore the warning that you might go online
5. Pray your mobile phone has correct connection settings
6. Go online, wondering how much this is costing you
7. Find out your phone isn't supported (whatever that means)
8. Wonder what all the fuss is about

So... application downloads to date have been by customers who are educated enough, driven enough or persistent enough to deal with this infernal procedure.

Just one more thing...

I love the mobile web. It's getting better every year as devices and networks improve, it's still got a long way to go, and it's the most cost-effective means of getting a mobile service launched.

But isn't it strange that Apple are getting massive success selling applications via a an application itself - that they're not selling and distributing iPhone apps via the web, either on the device or through iTunes? And it looks like Google are taking the same tack.

Isn't this a pretty strong endorsement of application as a route to online content, rather than the web? And isn't the success Apple has enjoyed with their application store testament to the fact that even in situations where the web might provide a perfectly serviceable experience (such as e-commerce), applications are a better route to take? Not that I'm suggesting we don't need to wait and see on this one, or that there won't be problems down the line as the quantity of content available via these stores increases.