

HN, let's make the 'better email' - willthefirst

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.
======
benaiah
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
YAML seems like a perfect candidate for "Markdown for metadata".

~~~
benaiah
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.

------
feralmoan
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!

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

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

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

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

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

------
willthefirst
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?

~~~
benaiah
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.

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

