Presence: a red herring?

[What follows is a bit rough, but if I take the time to try and polish it up, I'll never get round to it. Thus here, true to the blogger code of conduct, is a semi-formed rant...]

The need to incorporate presence information into the mobile experience, has been something of an assumed holy grail in this industry for the past few years. (By presence for this discussion, I'm talking about an icon or message along the lines of that we have with IM clients, that indicate the current state of the user, taking e.g. current location as the standard example.) Multiple worthy studies have been done and large expensive boxes have been sold that purport to deliver this functionality. Unfortunately, they're usually not plugged in, so customer facing presence start with the need to enter settings. DOA.

I've recently realized that the odd feelings I've been experiencing when the "presence" discussion comes up are not just coincidental indigestion. The ability for others to see what you're doing now is perceived by many in the industry to be just the inevitable evolution of our increasing interconnectedness, and the visceral negative reactions generated when 'normal people' hear about this ("but i don't want that") dismissed as the quaint yelps of a luddite. If sharing intimate personal details automaticlly is good enough for Japanese school girls, so the lore goes, it's good enough for the other 3bn mobile users; just give it time. If that is the case, then I guess I'm in the luddite camp. Here are 3 reasons why I think presence as it's currently envisaged, may be a red herring.

i) Unbounded data gives unlimited negative option value.
Your location information is fantastically interesting information for all manner of people and companies. In the same way that option value depends on the potential multiple uses of an asset, giving away generic and highly fungible personal data such as location can result in negative option value. I may have no problems with my friends knowing where I am, but I may not want my enemies to do so. If you do not limit the type of data shared, then you have to limit the recipient list. So that leads to the next problem:

ii) The high transaction costs of limiting the data set.
Are you really going to ascribe certain people the right to see certain types of your data? In theory, you should be doing that at a granular level, so that each time any element of your presence chances, you have the option to change who receives that information. Is "family" or "friend" a useful way to subdivide presence sharing? Enough said.

iii) Context not publisher-centric
This means you are a hostage to your state - regardless as to whether you have your presence information set to be update automatically or update manually. If it is the former, then you have no control over the information that is published. The minute you enter the pub, the world (or the subset that you have laboriously scoped down) knows you're boozing. If it's the latter, then your context is going to be out of date unless you decide to change it - so it's even dumber. You have to perform manual labour, and have no choice in the matter. This matters because you have not been given free reign to publish something of interest according to your terms - they have been dicated according to the context of the application.

So, from this rather esoteric discussion, 3 principles for "non-red herring" presence emerge:

- Limited data set. In the absence of certainty about where your data will end up, and trying to limit who will receive it (painful to implement), it's easier to limit the type of data that you're sharing to application specific things. This will ensure that the benefit to me for giving up my information far outweighs the potential cost (negaive option value) of doing so. This is generally not going to be the case when I am publishing generic information (such as location) that can have multiple uses that I do not control, unless that information is captured and only used by that service provider. Limit presence information to be bounded by a specific application or service - e.g. the music I'm listening to or the books I'm reading. I'm more than happy that anybody sees my last.fm profile because a new band or a friend who likes the same music is much more valuable than the potential privacy cost of people knowing what I like to listen to.
- Zero effort. Remove the transaction costs and make it aligned with what I do everyday. Automaticaly updating is part of the story here, but don't make me have to think about do I want that automatic update posted.
- Asynchronous. Switch from updates that are forced by context to subject specific (see i) updates; this is asynchronous publishing when it is convenient for me (the publisher) rather than you the technology or the context.