Catching the Next Wave

We have a saying in engineering about improving something until it no longer works. Another one goes “if it doesn’t fit, force it – and if it breaks, it should’ve been replaced anyway.” Both may apply to Google’s recent short circuit.

ArsTechnica staff explain their attempts to incorporate Google Wave into their communications portfolio:

http://arstechnica.com/software/news/2010/08/google-wave-why-we-didnt-us...

I find it interesting that quite a lot of people take a few things for granted:

• Email is good, but needs to be improved… somehow.
• Sustaining communications with multiple people/groups over multiple protocols is hard.
• The solution must be to roll all of our protocols into a single interface.
• Nobody has yet found a way to successfully integrate all those in-need-of-fixing protocols into a single UX.

So email has become less satisfying, but IM, SMS, MMS, IRC, voicemail and plain old voice aren’t scratching the itch well enough. A few years ago, I resisted when my boss required everyone to be on IM. I told him that I thought IM as a mode of business communication was horrible. His response was that people 10 years ago probably felt the same way about email. Touché. But that seems to highlight the problem: rather than evolving a protocol of communication to offer new flexibility and features, we continue to add new protocols. A hundred years ago, telephones had no buttons or even a dial – you turned a crank to alert the operator (when was the last time you spoke with an operator?) to place a call for you. Then we added a dial, then push buttons, then call lists, voicemail, voice dialing, visual voicemail – all extending the ‘protocol’. We didn’t add five types of telecommunications networks – imagine a bank of five phones on your desk, each used for different sorts of communication – such desks actually existed at one time.

For quite a while, I’ve felt that, rather than try to develop a UX to integrate multiple protocols that have quite a bit in common, and in concert develop ways collect and curate disparate contact lists, what’s needed is an extension of a single protocol to meet modern needs. Standardize such a protocol, along with address book information architecture. The “communications apps”:

• Email.
• (Visual) voicemail = email with voice “channel”.
• IM = email + presence.

Note that I do not include social apps in this protocol. Nor do I include collaborative editing in the list.

While Facebook, Twitter, LinkedIn, Gowalla, Foursquare and 50 other services are doubtless valuable, there is no standard, and I’d argue there shouldn’t be: these sorts of apps, indeed even the “medium”, is under such rapid evolution that conformance with a set of standards would probably inhibit innovation.

Regarding multi-person concurrent document creation, the workflow is so different from messaging that I’m actually surprised that Google decided to shoehorn it into Wave in the first place. Sharing creation of a document by ping-ponging it between editors is rarely satisfying beyond a very small number of edits or editors (say 2). Incorporating that workflow into a messaging client hardly bodes well for either messaging or document collaboration.

That said, the architecture for an address book for communications apps should be designed to be extensible in order to incorporate information and access control parameters for social/other (e.g. content) applications as well as geotagging and provisions for future developments in digital signatures.

So what would the basics be for an ideal communications protocol? For starters:

• Basic messaging capability (I send you a message; you reply, rinse and repeat). I include in “basic” everything we take for granted these days:
  • Address book integration.
  • Media/document attachments.
  • Group capabilities.
• Mobile-class stability – this implies store-and-forward: I lose my connection (network drop, close my laptop too quickly, etc) and you still get my message.
• Presence – you know when I’m available, and you know when I’m typing (ala IM as opposed to “see what I type letter by letter”).
  • Probably with on/off preferences that can be tuned to a certain degree for recipients/time of day/other or integrated as part of ACL.
• PKI integration – you can verify it’s from me, and only you can read it if that’s my intention.

And the address book?

• The usual:
  • Name/phones/emails/IMs/addresses/personal info.
  • Digital signatures/encryption keys etc.
  • Presence preferences.
• ACL – Access Control Lists.
  • Who gets to see/listen to/download what.
  • Groups.

Really, it seems to boil down to email + voicemail + presence + more full-featured address book. Can it really be that simple? Somehow I doubt it – but this seems a worthy direction for exploration.