NO. I want to scream. NO. I just began working at a company that uses "distribution groups" (mailing lists) as a "social network". It's awful as it's not threaded, it's not archived, it's not searchable. It's terrible.
NO. It's the fact that the server stores no archive of content. NO. It's the fact that ALL functionality has to be implemented in a thick client. NO. It's the fact that I just started working there, and thus am missing out on AGES of content that have been available to me instantly in FAR SUPERIOR FASHIONS using software that is built to store Wiki, Docs, Forums, etc, in centralized, indexed, searchable, archived formats that is far more useful for "social network" and documentation purposes.
>It's the fact that the server stores no archive of content.
And that's still not a problem of email. That's a problem of your
employer's competence. They should have an archive. Everything else
you mention are client problems.
It's so painfully obvious just from looking at the email model that that is not true. A lack of a central index? Separate content types that by their very nature contain more information? A searchable archive? None of those things are naturally part of email and providing them, at best is work, at worst is cludgy and unnatural.
You're thinking of this in the completely wrong way. Why should email - the protocol -
offer you all of this? It's nonsense, and goes against basic UNIX philosophy (do one thing).
It does another part of the UNIX philosophy very well, though: it's a universal interface.
Email can be used to communicate between all sorts of applications, and those applications
can give you the features you want easily. Which brings us back to what you're complaints
amount to: client problems.
What if someone could create a new messaging system that
works like previous messaging systems such as email and Usenet, but instead of sending a message along with its entire thread of previous messages, or requiring all responses to be stored in each user's inbox for context, message documents that contain complete threads of multimedia messages (blips) are perpetually stored on a central server. These documents are shared with collaborators who can be added or removed from the document at any point during a document's existence.
And I could add much more to my wish list. If only someone, with lots of brains and financial resources would come up with something like this and push it to gain wide acceptance then we would forget about the horror that email is very quickly...
Imagine if someone created that and then completely failed to integrate it with legacy email so that nobody could transition across, ran it as invite only beta for so long everyone lost interest and then failed to succesfully engineer the product so that it had stability issues and was nearly unusable on low end or old computers.
I'm convinced that the world could be a different place now if Google had done just a few things differently with Wave ...
Thank you. I came here hoping someone would point out that all these pain points people have with email were essentially solved with Wave. But instead of seeing the underlying system, people focused on a client UI that accessed the Wave protocol.
Comments
NO. I want to scream. NO. I just began working at a company that uses "distribution groups" (mailing lists) as a "social network". It's awful as it's not threaded, it's not archived, it's not searchable. It's terrible.
NO. It's your mail client makes these distribution groups a pain in the ass, not email.
Agreed. I use Sup[1] and it's wonderful. Threaded, extremely fast search (indexed), configurable, etc.
[1]: http://sup.rubyforge.org/
NO. It's the fact that the server stores no archive of content. NO. It's the fact that ALL functionality has to be implemented in a thick client. NO. It's the fact that I just started working there, and thus am missing out on AGES of content that have been available to me instantly in FAR SUPERIOR FASHIONS using software that is built to store Wiki, Docs, Forums, etc, in centralized, indexed, searchable, archived formats that is far more useful for "social network" and documentation purposes.
>It's the fact that the server stores no archive of content.
And that's still not a problem of email. That's a problem of your employer's competence. They should have an archive. Everything else you mention are client problems.
It's so painfully obvious just from looking at the email model that that is not true. A lack of a central index? Separate content types that by their very nature contain more information? A searchable archive? None of those things are naturally part of email and providing them, at best is work, at worst is cludgy and unnatural.
You're thinking of this in the completely wrong way. Why should email - the protocol - offer you all of this? It's nonsense, and goes against basic UNIX philosophy (do one thing). It does another part of the UNIX philosophy very well, though: it's a universal interface. Email can be used to communicate between all sorts of applications, and those applications can give you the features you want easily. Which brings us back to what you're complaints amount to: client problems.
This is a social problem, not a technology problem. There are many email lists wih searchable archives.
What if someone could create a new messaging system that
works like previous messaging systems such as email and Usenet, but instead of sending a message along with its entire thread of previous messages, or requiring all responses to be stored in each user's inbox for context, message documents that contain complete threads of multimedia messages (blips) are perpetually stored on a central server. These documents are shared with collaborators who can be added or removed from the document at any point during a document's existence.
And I could add much more to my wish list. If only someone, with lots of brains and financial resources would come up with something like this and push it to gain wide acceptance then we would forget about the horror that email is very quickly...
For some more info: http://bit.ly/1aAMNd
Imagine if someone created that and then completely failed to integrate it with legacy email so that nobody could transition across, ran it as invite only beta for so long everyone lost interest and then failed to succesfully engineer the product so that it had stability issues and was nearly unusable on low end or old computers.
I'm convinced that the world could be a different place now if Google had done just a few things differently with Wave ...
Thank you. I came here hoping someone would point out that all these pain points people have with email were essentially solved with Wave. But instead of seeing the underlying system, people focused on a client UI that accessed the Wave protocol.
Doesn't that more or less describe Google Wave?
The link exactly describes (for it is) Google Wave.
Well, that is embarrassing. Currently tethered to an EDGE connection and didn't click for fear of a ginormous page on the other end. Serves me right!
I was one of the few that raved about and loved Google Wave. :(