Where along the UI line should multiple accounts/personas be exposed?
These thoughts provoked by Chris Messina’s Social Agent work, Brennan Novak’s A Better Friend idea and work done on Indieweb Messaging (referenced from indiewebcamp.com/projects)
Taking the example of sharing some link with a friend. The friend has an account on several identity providers (e.g. Facespace/Twittle/Gooter).
Chris’ Social Agent UI proposes to expose all identities to me in a sharing UI, leaving it up to me to decide which one is most appropriate.
The problem with this is that I may not be the best person to decide what communication channel is most appropriate. One of the big ideas behind Indieweb Messaging was that the sender of a message had one endpoint to send messages to: a url. It was up to the recipient to delegate any received messages to other services, allowing advanced behaviours.
Some possible advanced behaviours include:
- Message filtering based on sender, content, etc.
- Message length/content-dependant delegation
- E.G. if message is < 100 chars send it via SMS, otherwise email
- Schedule–aware buffering and delaying of messages
- E.G. if it’s from friends/family deliver it during a lunch break, if it’s from a work person deliver it as usual
- Geolocation–aware delegation, e.g:
- if I’m at home, send via SMS
- if I’m at work, send via email
Almost all of these use cases revolve around the fact that the recipient has all the control. Schedule–based delaying/message bundling can be implemented without sharing your private calendar with anyone. Geolocation–aware delegation can be implemented without sharing your location, and so on.
The downside to this approach is the added uncertainty for the message sender. They have no way of knowing whether or not their message has arrived, been read, or ignored altogether. There are a couple of possible solutions:
- The message handling server could return an immediate response to the sender which explains how their message has been handled and when it might be read
- The message handling server could use a webhook/salmon slap/something similar as read receipt infrastructure, allowing the sender to see in real–time exactly when their message has been read