Quite often, one of the easiest ways to think about S+S is when thinking about multiple channels for exploitation from a central service: desktop, web, mobile clients talking to a cloud service.

Whilst I don't think this describes S+S fully, it's a relevant and useful story - I talk about Exchange and it's various clients (desktop, web, mobile, voice) as an example of S+S myself. Though in the case of Exchange, there are also other things to think about: hosting location and attached services for example.

Let's explore the multiple channels issue a little more.

When I discuss new projects with customers then more often than not most will have some kind of view as to whether they'd like to create a 'mobile' version of the software. This is typically driven by market, or a particular feature of the solution (e.g. "most of our market is web" or "video on mobile is still a pain, so we'll concentrate on web"). More often than not, there isn't a lot of thought on the differing experience that mobile (or whatever) can provide.

Exploiting multiple channels is a Web2.0 phenomenon too: there is a (perceived) need to surface a solution/product offering in many different 'web-flavours' such as gadgets, or Facebook apps (or Netvibes, or PageFlakes, or or...). One of the solutions in the Web2.0 space is to create the core proposition yourself, and then rely on the 'wikinomics effect' to have the crowd construct all of the other channels for you. This has worked extremely well for Flickr, for example. A great example of a 'really simple idea' that is exploited in multiple channels is Remember The Milk.

Apart from the exploitation, it is worth thinking about the experience. I feel a sense of dismay when I see a mobile offering, or even a web gadget that tries to do what the original experience did. Different channels can serve different purposes. Taking the gadget example - when Apple released OSX, complete with widgets, they wrote a best practice guide on widget construction and specifically said something about 'complementing' rather than replacing a Web UI (I've searched but can't find this original guide - other folks' references also point to a 404).

Last year, Ray Ozzie said: "In my view, we only have one shared future as a software industry. And that is centrally deployed code that has a different lifetime associated with it on the device it's deployed to."

Ray was thinking about software construction and related issues, but since I read this then I've considered that one of the useful ways to think about the exploitation of available channels, and the experience they should offer is around the 'lifespan of a user session'. So, on a desktop, this could be a lengthy period of time - I have many of my desktop apps open all day - but on the web is likely to be much more transient. This transience is increased with 'gadget'-type platforms as it is likely that the gadget is merely one part of some sort of aggregation. Mobile channels are useful for 'directly relevant information, right now'.

Small pieces of software such as the Flickr uploader, Windows Live Photogallery, or Picasa can significantly enhance a user experience for the central cloud service: the smaller lifespan of my browser session means that upload of photographs are less reliable, and less natural than the use of a long-lived desktop session.

Any given channel will have attributes that require consideration before exploitation: cross-platform for desktop, richness and response for the web, geolocation for mobile and so on. Lifespan of a user session is applicable across all of these in different ways.