Hacker News Reader

Metadata is a bit of a strawman.

There is sufficient information in the text to determine that the email is for a feature request - otherwise the author wouldn't know it was one.

What's needed is an intelligent engine for processing email. Improving email is an AI problem not one which requires an email to contain more information.

One difficulty I see is that developing a system for intelligently processing email is not necessarily the sort of thing a startup can tackle - the required data set for testing and validation is too large for a small company to obtain naturally and test under real world conditions. It's the sort of problem that lends itself to an "eat your own dogfood" approach - and thus justifiable at an existing large company.

My gut tells me that outside the corporate world, this wants to be a desktop application, not a web based one. The intelligent engine needs to know about the files and documents on my computer to make better sense of the contents of a message - I don't want to have to share all that with a web service and I don't want to enter a bunch of metadata to create rules.

The software should know it's a bug report because I write a lot of code for the product, have other bug reports on my computer, and posted ten bug fixes to the code repository. not because I spent four days writing a CLIPS program to handle bug reports.

It's a nasty problem if one tries to just grep it into submission. The answer to the email problem is a poem, not an equation.

"What's needed is an intelligent engine for processing email"

They already exist; the normal name for such a thing is "secretary" =D

I don't know about the inductive logic behind your "humans can solve this problem, therefore it is solvable by a computer". To create an algorithm that could classify email as well as a human, you'd need to create an algorithm as advanced as a human.

Furthermore it would not help much. You still would have to monitor the algorithm decisions. Otherwise you loose control over your work.

Never ever I would allow an algorithm to decide what is a bug and what is a feature request.

Your argument changes the premise. The email problem persists because it is hard (or impossible) to solve by humans.

Solving the email problem, in so far as it depends upon classifying email, must classify email significantly better than a human. One of the things computers do better than humans is working tirelessly, and at its heart the email problem is Sisyphean.

Google serves personalized advertising. Facebook customizes your feed. Your grocery store prints coupons at checkout.

All without homunculi.

So why not simply begin with a mail client plugin for that?

I imagine something like that:

When the user clicks "New Email" and types in the mail address the mail client would automatically connect to that domain and retrieve a list of the required metadata. Or you'd need to send an email that nobody except your server will ever see. But that may be too slow.

Then in the mail client you will get a notification (hopefully not an annoying popup) that the server supports "semantic mails" and that when using it you make the lives of people easier and probably get an answer faster.

What types of mail does it support? (Bugreport, Task, ...). That's the first thing you chose.

What fields are required? What fields are optional? What data type does each field take? You then can just draw appropriate widgets.

That would be a basic idea. Probably needs some tweaking, but doesn't seem that bad to me.

I agree some metadata would make life easier, but we are trying to simplify the process of extracting the data from an email and getting it where it needs to be quickly and easily.

We are experimenting with different ways to do make this easy for the user, which is why we need feedback from users who have a different background than our own.

Sadly you can't write email for programmers and expect everyone else to understand it :(

While I felt it defocused my post a bit to say this, it is true that you can make some things easier. In particular the Great Semantic Divide doesn't apply to yourself talking to yourself, so anything you do with custom scripts or code to make your particular life easier does indeed work. But I got to my point by reading about your specific complaints in your post. Making it easier to handle the flow mitigates the complaints in your post, but doesn't actually eliminate them. But mitigation is possible; life isn't hopeless.

I have seen a couple of cases of people (or machines) saying "Send an email to <address> with <some word> in the subject line." That seems easy for a human to carry out and for a machine to recognize. This seems to address your objection:

In this perfect world this supposedly is done by the sender... but that, too, is fraught with problems, because that takes a certain level of skill on the sender side and now you've lost the aspect of email where you just click "New Email", bash on the keyboard for a bit, and hit "Send"

It is indeed possible to define little machine interfaces like this and for users to learn and use them. A more complicated interface would of course be more difficult; maybe you would only try to ask technical users to do that, and have a machine send back "Did not parse correctly" if it did not parse correctly. If it becomes common and useful enough, perhaps you could make email applications that provided buttons or whatever to machine-generate machine-readable instructions, and big-business clients could instruct their employees that deal with your machine to use such an application. And maybe you could bug Gmail developers into implementing it as an optional feature, disabled by default--maybe in that "Gmail Labs" thing, although this has a different source. If that doesn't work, then maybe you could duplicate all of Gmail's nice functionality so that those employees feel fine using your email application. Eventually you might get something that could be called a standard out of this, but you would start with just a small use case.

It does seem likely that expecting an interface to work with no prior exchange of instructions ("put word in subject") between the receiver and the sender is, well, hubris. But I suspect you can get a fair amount done with tiny interfaces that are easy to learn. See also:

http://unqualified-reservations.blogspot.com/2009/07/wolfram...