HN, let's make the 'better email'
I'd be interested in talking to anyone else whose interested in making email better. I'm thinking something along the lines of creating a simple task management web app that integrates all tasks, to-do's, read-it-laters, and email. If interested, reply in the comments, and maybe this will devolve into a Google hangout with stupid moustaches.
6 comments
The problem with replacing email is the fact that, unless you're using the standard email protocols, it's not really email at all. What needs to be done is to write a wrapper around the normal email protocols, and allow integration and interoperability with vanilla email that way. Then, you could write a new protocol if you wished, as long as the old ones kept working. If you want to replace email, you actually need to replace it.
I don't know if that's what you were already thinking, but thinking that they can make the world move to another protocol all of a sudden is a problem I see a lot of "reinvent email" guys having. That and building it so it only works with specific providers (usually just gmail) are big problems. (I use Hotmail, now Outlook.com, for my email, which is @ my own domain).
So, I think this could work, and I'd be interested in helping, but only if - It works on classic email protocols - It supports arbitrary providers (this goes along with the first point).
My suggestions as to features: - I really like the idea that alokhar mentioned of the unnecessariness of attaching a document. You could sort documents in different ways (types, who they're from) and list them along with email (which would be toggleable, for obvious reasons). If you need to send them, you send them with a stub email with some sort of markup in it that lets this service ignore the actual email, but is human-readable so it works with vanilla email. - An integrated inbox would be really nice - this would work well with the calendar/todo list integration. You could have some sort of human-readable, human-writeable metadata that would allow for various functions (setting a due date, etc). - Any email sent to an address by that address could be treated as a note - this would include todo-list entries (mentioned above), as well as just text notes. You could even sync these with external services (such as Evernote), which would be pretty cool. - The first image in an email could be used as its thumbnail in some views (or be overridable by the attributes described below)
These ideas hinge a bit on the idea of "Markdown for metadata" - some sort of obvious, flexible way to include metadata that, when read by a human, just looks like what you might write anyway. For example,
You could use a similar attribute for todo and calendar entries, but these could be inferred from other attributes in most cases.
In order to be as flexible as possible, you'd want to support many different aliases and formats (so I could, for example, write "date" or "when" instead of "due", and use any of the above formats).
These are just examples (the task would probably just be the email title, not an attribute - if it was an attribute, it would at least default to the email title).
I like the paradigm of having one line per attribute, with
You would use this parsed metadata to implement things like to-do lists, calendars, etc, and it would look like something you might type anyway.
Sorry, I've rambled a bit. What do you guys think?
I don't know if that's what you were already thinking, but thinking that they can make the world move to another protocol all of a sudden is a problem I see a lot of "reinvent email" guys having. That and building it so it only works with specific providers (usually just gmail) are big problems. (I use Hotmail, now Outlook.com, for my email, which is @ my own domain).
So, I think this could work, and I'd be interested in helping, but only if - It works on classic email protocols - It supports arbitrary providers (this goes along with the first point).
My suggestions as to features: - I really like the idea that alokhar mentioned of the unnecessariness of attaching a document. You could sort documents in different ways (types, who they're from) and list them along with email (which would be toggleable, for obvious reasons). If you need to send them, you send them with a stub email with some sort of markup in it that lets this service ignore the actual email, but is human-readable so it works with vanilla email. - An integrated inbox would be really nice - this would work well with the calendar/todo list integration. You could have some sort of human-readable, human-writeable metadata that would allow for various functions (setting a due date, etc). - Any email sent to an address by that address could be treated as a note - this would include todo-list entries (mentioned above), as well as just text notes. You could even sync these with external services (such as Evernote), which would be pretty cool. - The first image in an email could be used as its thumbnail in some views (or be overridable by the attributes described below)
These ideas hinge a bit on the idea of "Markdown for metadata" - some sort of obvious, flexible way to include metadata that, when read by a human, just looks like what you might write anyway. For example,
due: may 5
due: tomorrow
due: 2012-06-21
task: development
email type: attachment
You could use a similar attribute for todo and calendar entries, but these could be inferred from other attributes in most cases.
In order to be as flexible as possible, you'd want to support many different aliases and formats (so I could, for example, write "date" or "when" instead of "due", and use any of the above formats).
These are just examples (the task would probably just be the email title, not an attribute - if it was an attribute, it would at least default to the email title).
I like the paradigm of having one line per attribute, with
<attribute> : <value>
You would use this parsed metadata to implement things like to-do lists, calendars, etc, and it would look like something you might type anyway.
Sorry, I've rambled a bit. What do you guys think?
I know this is a little late, but if anyone is interested I'm building a tool with similar function (http://bip.io - its in development right now, updates via https://twitter.com/bipioapp) - treating email as 'just another protocol' infront of an API glue service. We aim to support NLP in message payloads to dynamically assemble (social and API) delivery pipelines... reach out if you're interested in contributing, the code is quickly maturing!
Some thoughts:
o A don't like using calendar apps, just don't like them,
o I frequently use email to email myself links and todos,
o I hate outlook,
o I've been thinking it would be ideal to integrate todo lists, calendar apps, and email all together, and
o Why the hell do I still have to forward emails?
EDIT: to clarify - forward emails between accounts.
o A don't like using calendar apps, just don't like them,
o I frequently use email to email myself links and todos,
o I hate outlook,
o I've been thinking it would be ideal to integrate todo lists, calendar apps, and email all together, and
o Why the hell do I still have to forward emails?
EDIT: to clarify - forward emails between accounts.
> Why the hell do I still have to forward emails? (to clarify - forward emails between accounts.)
Why not just drag the e-mail from one account to the other? (This is easily accomplished with, say, Outlook, which I realize you said you hated.)
Why not just drag the e-mail from one account to the other? (This is easily accomplished with, say, Outlook, which I realize you said you hated.)
The process of attaching a document is entirely unnecessary. Why distinguish between formats? If you want to give somebody a spreadsheet, just send them a spreadsheet, not an email that happens to have a spreadsheet attached.
Further, I like the idea of "posting" on somebodies todo list rather than "emailing" them some letter through an internet postal service.
All these things. Let's talk, but wait for more people to get back.
Hey everybody, we're going to do a hangout tonight:
http://news.ycombinator.com/item?id=4911943
http://news.ycombinator.com/item?id=4911943
Thanks for your interest guys and gals. Would you be interested in talk ing tomorrow (Sunday) at 3pm PST on Google Hangout and discussing a possible project?
Hey - I didn't see the post, as I was out on Monday and Sunday. If you're still interested in doing something, shoot me an email at [email protected].
Features are not the issue. The interface is make or break.