The challenge presented by Raindrop to improve the aggregation/presentation of emails is, I feel, both great and wrong. Great because it is rooted in the current status of email communications. Wrong because it is limiting itself to the confines of what email is, when I believe it should be looking into what email can be. This is constantly moving inside me.
A few days ago I was looking at an email received from IntenseDebate (the commenting engine I am using on my personal blog). The email is very useful – it gives me a context (the post on which a comment was left), the comment itself and information about the person that left it and some options to immediately act on the comment. I can approve/dismiss/spam the comment either by using links inside the formatted email or by replying to the email notification with keywords – if I reply with “approve” then the comment on my blog will be approved without having to go to my blog’s comment administration interfaces.
When this message arrives in my email inbox it has been compromised – it has been watered down to what the abilities of an email message. Now Raindrop has to wonder what this message is and how to treat it. I believe there is a better way to do this.
XEMail is of course just a nick name I conjured up – a mixture of XML & Email. Suppose Raindrop created a new protocol/standard for packaging information inside the existing email communication standard (POP3…) – using something as common as XML. Suppose a service, for example IntenseDebate could be configured to send XEMail notifications instead of email notifications.
The IntenseDebate XEMail container would contain meta-data that Raindrop could use to better understand the message – it would know that it is a blog comment notification, it would know from which blog, it would know from which post, it would know from which user (all these properties gain context within an XEMail container!). Raindrop could then easily aggregate for me all “blog comment notifications” or “blog comment notifications on post x” or “blog comment notifications from userx”, etc.
Raindrop would then have more options to process/act and render this information, instead of being confined to the limited presentation currently delivered.
Topify is an example application of the potential of this approach. When Raindrop receives an incoming XEMail message (in this example: new follower from Twitter) it could launch a plugin (for which there could be many flavors) that aggregates additional information and creates a better/more useful representation of it for a user. Topify looks like a great service, I don’t use it because it another example of web-identity fragmentation – this is my data and it should happen in my space.
This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.
XEMail
The challenge presented by Raindrop to improve the aggregation/presentation of emails is, I feel, both great and wrong. Great because it is rooted in the current status of email communications. Wrong because it is limiting itself to the confines of what email is, when I believe it should be looking into what email can be. This is constantly moving inside me.
A few days ago I was looking at an email received from IntenseDebate (the commenting engine I am using on my personal blog). The email is very useful – it gives me a context (the post on which a comment was left), the comment itself and information about the person that left it and some options to immediately act on the comment. I can approve/dismiss/spam the comment either by using links inside the formatted email or by replying to the email notification with keywords – if I reply with “approve” then the comment on my blog will be approved without having to go to my blog’s comment administration interfaces.
When this message arrives in my email inbox it has been compromised – it has been watered down to what the abilities of an email message. Now Raindrop has to wonder what this message is and how to treat it. I believe there is a better way to do this.
XEMail is of course just a nick name I conjured up – a mixture of XML & Email. Suppose Raindrop created a new protocol/standard for packaging information inside the existing email communication standard (POP3…) – using something as common as XML. Suppose a service, for example IntenseDebate could be configured to send XEMail notifications instead of email notifications.
The IntenseDebate XEMail container would contain meta-data that Raindrop could use to better understand the message – it would know that it is a blog comment notification, it would know from which blog, it would know from which post, it would know from which user (all these properties gain context within an XEMail container!). Raindrop could then easily aggregate for me all “blog comment notifications” or “blog comment notifications on post x” or “blog comment notifications from userx”, etc.
Raindrop would then have more options to process/act and render this information, instead of being confined to the limited presentation currently delivered.
Topify is an example application of the potential of this approach. When Raindrop receives an incoming XEMail message (in this example: new follower from Twitter) it could launch a plugin (for which there could be many flavors) that aggregates additional information and creates a better/more useful representation of it for a user. Topify looks like a great service, I don’t use it because it another example of web-identity fragmentation – this is my data and it should happen in my space.
This is an example of what I meant when I said that Raindrop should sit on the shelf closer to HTML then Thunderbird – it can become a new defacto communication standard – as simple as email, as rich as anything that Internet has to offer.