Fred Wilson provides insight into his email habits and wishes … and again Fred provides another great example for what I call contexts… this time the context is “priorioty email contacts” … this is such a simple thing to implement … and a killer feature for a new and alternative messaging system.
Fred Wilson’s post about Facebooks new Social Graph … does a great job of explaining what I mean by contexts…
Some things I want to share with everyone…
Some things I want to share with family…
Some things I want to share with work associates…
Some things I want to share with no one…
Right now startup companies and their investors are feeding on specific contexts by developing niche social networking tools. In doing this they are tearing apart online personal identity.
An alternative could be that my one-home-on-the-web-WordPress-installation could have a context entity – around which I could publish and share information with others…what are not niche services should become plugins – add on behaviors to MY online home.
This is a draft of a core idea on a tool for configuring and managing a WordPress navigation menu. My understanding is that this is a typical menu of either pages or categories that appears in the (or just below) header area. Following is a quote of the challenge as presented by Jane Wells:
Challenge #2: Better menu management. Right now the core development crew is working on a way to manage site menus from the admin. They started from existing plugins and widget code, and as a result, it could use some UI help. I don’t want people to start from scratch and submit their dream model, because there’s already work in progress. Just drop by the Trac ticket and provide UI feedback/suggestions.
After reviewing the Trac ticket and gaining some (hopefully relevant) perspective and inspiration from some mockups by Lari I put together this suggestion which is offered as a starting point for discussion (click on image to enlarge):
Basically the idea is to use existing capabilities from widget configurations to create a menu which can be populated by elements from the website:
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.
Following is a sample contact information view that includes an application of the relationship proximity idea. The context is viewing a single email message.
Additional Thoughts:
I feel like I’m in a conversation with Dave Winer tonight… this time he’s calling out to twitter client application to bypass Twitter itself (if you’re not in the tech-loop – then yes it is possible and and there are already two working technologies that do this).
A while back I described an RSS reader that I’d like to have integrated for me (not for my readers) in the Wordpress Admin (with in-line features for publishing information directly from my reader) . Now I want an updated version of it.
I’d like a WordPress plugin for Microposts:
This also demonstrates where I think Mozilla Raindrop should be heading – it should be the open-source communication infrastructure for all of my incoming and outgoing communications. I don’t really want an RSS Reader and a Micropost reader on Wordpress. I want one robust, reliable, adaptive, customizable, extensible application – and Raindrop is a great candidate for that.
Dave Winer writes about creating a single feed of all his on-line writing. I definitely support this – but I see it happening another way – actually the other way around. Dave is actually “collecting a single feed” – which actually embraces something that is wrong to start with. There shouldn’t be any need to collect. It should all start from one place, my space… and then disperse and disseminate in any number of formats/technologies/mediums.
For example – currently:
The way it should be:
It should all start with me. If I had Dave’s programming skills – I would be doing similar work – just the other way around. We make a mess and then collect the pieces to recreate order. That’s OK once or twice when getting started, but once we know what we want – there is no reason to keep doing it like that.
It should all start with me. What would all the parasitic business build around my content – I don’t really care, but I am curious to find out.
Twitter suspends an account for only sending links and violating Twitter Rules
Dave Winer On Dropbox
Dave again brings up Dropox – which I agree is a great service. I also agree there should be an open-source alternative to it… BUT I believe that what is needed is not an open-source technology – since that would only be available for technically-proficient end-users.
What we need is another Dropbox open-source PRODUCT – something anyone can use. But that’s exactly what Dropbox is!! So why do we need another one? We don’t!
But if there was an open-source Dropbox plugin for WordPress (for example) – that would be amazing!
Open-source really needs to mature beyond “technologies” and “projects” – if it is going to make a difference – it has to mature into mature products. I don’t think programmers can do this on their own – this is why open-source needs designers!