HN, let's make the 'better email'

https://news.ycombinator.com/item?id=4890858

by willthefirst • 14 years ago

9 13 14 years ago

news.ycombinator.com

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.

alokhar3• 14 years ago

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.

alokhar3• 14 years ago

Further, I like the idea of "posting" on somebodies todo list rather than "emailing" them some letter through an internet postal service.

willthefirst3• 14 years ago

All these things. Let's talk, but wait for more people to get back.

alokhar3• 14 years ago

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.

saurik• 14 years ago

> 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.)

nwh• 14 years ago

Features are not the issue. The interface is make or break.

benaiah3• 14 years ago

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,

  due: may 5
  due: tomorrow
  due: 2012-06-21
  
  task: development
  
  email type: attachment

This last one could be used for something like the stub emails I mentioned earlier, where a dumb email client would just ignore this and display the text, while a smart email client would hide the email and just add the atttachments to the inbox. You could include some explanatory text ("This is an attachment from johndoe@example.com"), but if this attribute was set to attachment, then it would be ignored by the smart email client. You would probably include a way to see these hidden emails anyway, to mitigate accidental invocation.

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>

Attribute and value could be parsed on a case-by-case basis - see the several different date formats I used above.

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?

dignati• 14 years ago

YAML seems like a perfect candidate for "Markdown for metadata".

benaiah3• 14 years ago

I wasn't previously aware of YAML, though it seems like it would work very well - even allowing for features like adding/exporting multiple entries.

willthefirst3• 14 years ago

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?

benaiah3• 14 years ago

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 contact.benaiahmischenko@gmail.com.

willthefirst3• 14 years ago

Hey everybody, we're going to do a hangout tonight:

http://news.ycombinator.com/item?id=4911943

feralmoan• 14 years ago

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!

HN, let's make the 'better email'

Related Stories