Live data from Hacker News

Why it’s so hard to innovate in the e-mail space (2014)

medium.com

51–60 of 68 posts

Re: Why it’s so hard to innovate in the e-mail space (2014)

#51
post #11

Why do people blog about what their company is building without so much as mentioning the name of their company or product or even a hyperlink? In the author profile at the very bottom of the page, in small letters, there is a URL (but not a link) to https://frontapp.com/ and the email client the author works on is apparently called Front. But why should her readers ever care about that?

You're right. When I wrote this article I was more interested in replying to Des Traynor's article than promoting our product. I've added a link (even if I'm not sure people care)

Front is a great product. It lets us manage emails and SMS support together!

Re: Why it’s so hard to innovate in the e-mail space (2014)

#52

Why are messages separated by transport? That is, why are messages sent to/from me via one transport (e.g., SMTP) read and composed in one application, and those sent via another transport (e.g., SMS, Twitter) read and composed in another? Why, as a user, do I give %#@%! what the underlying transport is? I think the focus on a particular technology (SMTP) rather than a service (messaging) is why email clients don't a…

I'm really glad email doesn't change quickly. It works, and there's nothing really wrong with it.

Re: Why it’s so hard to innovate in the e-mail space (2014)

#53
post #43

At a very high level, email is primarily used for discussions. With this view, successful innovation in the e-mail space requires innovation in the nature of discussions themselves. Tinkering around with better usability or feature improvements will not be sufficient to overcome the massive inertia of 'traditional e-mail'. We are a startup that just launched ( https://tmail21.com ) that aims to rethink the discussion…

At a very high level, email is primarily used for discussions.

I guess it depends on what you mean by "primarily" but my inbox is overwhelmingly notifications and announcements, not discussions. There's remarkably little of my inbox dedicated to actually talking to people.

Re: Why it’s so hard to innovate in the e-mail space (2014)

#54
post #29

Earlier quoted context omitted.

Yes it most certainly is on a secular decline. It is no longer growing at rates that are keeping up with the online user base. New internet users are no longer even setting up email accounts. Email is dying. Its not dead, but it is no longer the go-forward internet communication platform.

> New internet users are no longer even setting up email accounts. What percentage of new internet users do not have any email accounts? I haven't been able to find any reliable data.

Seems like a strange claim, considering many sites that new internet users use will not let you sign up without an email account

Re: Why it’s so hard to innovate in the e-mail space (2014)

#55

Earlier quoted context omitted.

I tried some similar things when making Zombition, but I found that blurring the line between email and instant message mainly results in a more complicated UI and more details for end users to remember. For example, with instant messages you generally have some status information about whether or not the other user is online, whether or not they may have read whatever you just sent them, and whether or not they're t…

> inline replies to parts of messages to enable nested conversations. Just to be sure: You know that that is really easy with email as it existed until about 20 years ago, including BBS networks, usenet, etc., and that it is still trivial with good email clients? That was a solved problem that made email really efficient, until some clueless developers and users came along and disinvented (is that a word?) the soluti…

Actually I didn't know; thank you for telling me! (That also makes me realize that I could likely do it in a much easier way than I currently am...) What are the email clients that allow that kind of behavior?

Re: Why it’s so hard to innovate in the e-mail space (2014)

#56
post #53
post #43

At a very high level, email is primarily used for discussions. With this view, successful innovation in the e-mail space requires innovation in the nature of discussions themselves. Tinkering around with better usability or feature improvements will not be sufficient to overcome the massive inertia of 'traditional e-mail'. We are a startup that just launched ( https://tmail21.com ) that aims to rethink the discussion…

At a very high level, email is primarily used for discussions. I guess it depends on what you mean by "primarily" but my inbox is overwhelmingly notifications and announcements, not discussions. There's remarkably little of my inbox dedicated to actually talking to people.

You are right. There is a mix of notifications and discussions with the mix varying between the two based on the nature of user's communication. In more collaborative scenarios, it may be 80%-20% discussion-notification. In other scenarios the ratio may be reversed.

On the pure notification front, we have friendly tracking numbers (so that notifications can be referred to from other places like spreadsheets, chat, apps, voice etc.). These tracking numbers look something like 124-1234-1234. We also support Certified Mail, Certified Forwards, Certified Read Acks etc.

Having said this, we currently support outbound notifications (from TMail to TMail/EMail). On the inbound side we support TMail to TMail. We do not currently support EMail to TMail notifications although we may add this if we see sufficient demand.

Re: Why it’s so hard to innovate in the e-mail space (2014)

#57

It will be easier to build a new email spec that's more feasible/modern with security built in mind than it is to build a sustainable email client that tries to comply with various email services (GMail is the worst offender for not being consistent with IMAP spec). Mailmate is my fav OS X client that focues more on power user features but it has a boring classic interface which doesn't bother me at all. Despite havi…

It's not as ugly as Thunderbird or a web-app. At least it follows most of the OS X conventions. Anyway the existence of Mailmate shows how the premise in the article is totally wrong - it's not hard to create a decent modern email client - it already exists and only takes one developer.

A better title would be: Why is it so hard for users to use a good email client?

Re: Why it’s so hard to innovate in the e-mail space (2014)

#58

Earlier quoted context omitted.

> inline replies to parts of messages to enable nested conversations. Just to be sure: You know that that is really easy with email as it existed until about 20 years ago, including BBS networks, usenet, etc., and that it is still trivial with good email clients? That was a solved problem that made email really efficient, until some clueless developers and users came along and disinvented (is that a word?) the soluti…

Actually I didn't know; thank you for telling me! (That also makes me realize that I could likely do it in a much easier way than I currently am...) What are the email clients that allow that kind of behavior?

Well, essentially, all of the traditional text-only clients do (such as Mutt, which is what I use), I think Thunderbird does as well, beyond that, no clue, but there probably are others.

Traditionally, if you chose to reply to an email, the mail client would put the mail you were responding to into your editor, with > marks in front of every line. The only socially acceptable way[1] to write your answer was to insert your responses in between those quoted lines, without > marks, and to delete everything of the original mail that was irrelevant to establish the context for the reply.

That's how easy it is.

Usually, a good mail client would also color quoted lines so that it's easy to see and read only the response lines in a received email, so you'd only have to read the quoted text if you weren't sure about the context.

Clueless developers and users around the turn of the millenium then somehow didn't understand the purpose of providing you with a quoted version of the email you replied to, and started putting the reply above the quoted mail, thus ending up sending a copy of the mail they just received back to the person they received it from ... and nobody seemed to notice how idiotic an idea that actually is, and so it became sortof the new norm in large parts of the internet to attach large blobs of completely useless and often close to unreadable text to every mail, up to the point where some people even invented justifications for the behaviour that mostly tend to describe how this "feature" allows them to work around the lack of proper thread handling in their mail clients.

Obviously, easy quoting traditionally relies on plaintext only mails with fixed (short) line length, but format=flowed encoding has since been invented (the original RFC is from 1999) to accomodate screens and windows of variable width while maintaining backwards compatibility with old clients.

[1] https://www.netmeister.org/news/learn2quote2.html

Re: Why it’s so hard to innovate in the e-mail space (2014)

#59

Because. It. Doesn't. Need. It. Email isn't broken.

Not necessarily broken, but certainly outdated. What do you think about spam, encryption, attachment sizes?

Imagine being able to publish your email address online without worrying about spam; even in your profile you've been forced to obfuscate your own a little. Or to know that every message you send can only be read by the recipient and nobody in-between - without having to explain PGP to non-techs. Or being able to send a 50-100MB file without resorting to third party or public hosting - any of those features would be a bonus, in my view.

Not broken, but can be improved, don't you think?

Re: Why it’s so hard to innovate in the e-mail space (2014)

#60

Earlier quoted context omitted.

I agree with that. I don't mean that I want to send my email messages visa SMS. I mean that I want all my messages sent/received and read in one messaging client, whether they are transported via SMS, SMTP, etc. If the HTML message should go via SMTP, I expect my software to deal with that. I want the content; the transport is an obscure detail for developers to worry about (speaking as a typical end user).

You're asking for a magic genie content router that does not exist. It does not exist because its a hard problem . Not only would you need to interoperate with open standards, you'd have to attempt to integrate with unwilling participants (Facebook, Google Hangouts). Are you prepared for that level of pain?

You also have to consider that facebook already do this. They tried to wrap up email, messages and an SMS replacement on your phone into a single package where they own the whole thing.

I look at iMessage and I think it works pretty perfectly, SMS when no internet or to a non apple user, iMessage whenever possible. What I want is for whatsapp (and I suppose facebook and plausibly email) to do the same all in my single messenger application.

But. Ignoring the need to get the tech owners to consent to this new "trillian", I'd also have to trust the app itself. Good luck making money on that.

Post reply on HN