This isn't thats complicated:
Because email is dying and is already mostly optimized.
Why it’s so hard to innovate in the e-mail space (2014)
21–30 of 68 posts
Re: Why it’s so hard to innovate in the e-mail space (2014)
#22There are tons of reasons why this is so hard. Leaving aside all of those there are 2 that I see as the biggest: * A 100x improvement over current email is needed for a switch. * It has to be 100x cheaper than the current product. While you can't multiply by 0 and I meant that facetiously, users won't pay for the software or only niche consumers. Which is why email providers that get paid focus on things like securit…
MailChimp? Constant Contact? I may be wrong, I'm not terribly familiar with either, but I believe they're largely focused on email.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#23This isn't thats complicated: Because email is dying and is already mostly optimized.
Email is most certainly not dying.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#24[deleted]
Re: Why it’s so hard to innovate in the e-mail space (2014)
#25This isn't thats complicated: Because email is dying and is already mostly optimized.
Email is most certainly not dying.
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.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#26Why 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…
Because the different transports have vastly different abilities and limitations that are a source of frustration if you attempt to obfuscate the differences between them and aren't served by a unified UI?
Could you be more specific? For example, comparing SMS and SMTP, the two most prominent transports?
Re: Why it’s so hard to innovate in the e-mail space (2014)
#27Why 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…
Sending is easy. Receiving and sorting and filtering is harder.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#28It's hard to make money in that space, yes. I've considered merging mail and messaging, so that email protocols are used to do the things people do with instant messaging, Telegram and such. The first step is to get away from queuing mail. A first step is a new kind of mail forwarder, one for machines that don't have local mailboxes (which is most non-mail servers). It acts as an SMTP server and client. When an email…
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 typing a reply. If you want to add that into a email interface, how do you indicate to your end users that another user will never have associated status information because their account is on a server that is incompatible with the method you proposed?
Plus the behavioral differences between email and instant message didn't blend well: was I going to wait in a mixed email/instant message conversation for a response, or was I going to move on to the other conversations in my inbox and send a reply or archive each so that I could move on to doing other things? And if I wanted to temporarily leave an instant-message-like conversation so that I could deal with some more email-like conversations, would the person I was chatting with know whether or not I would return?
Eventually I stepped back to look at what additional value a user gained by blurring instant message and email in this way. Fundamentally they're both asynchronous text-based communication, and the things you can actually do with them aren't strikingly different. The biggest difference is in the expectations that a user has for each.
Anyway I still wanted to "innovate in the email space", so I decided to go a more extreme route, and I made my own pull-based protocol (superficial similarities to IM2000 - http://cr.yp.to/im2000.html) that retains backwards compatibility with email while adding abilities like stateful plugins (JavaScript apps/widgets) that can share data through the new protocol, editing messages after they're sent (SMTP recipients receive the new version after the update), and inline replies to parts of messages to enable nested conversations. If you're interested, I posted it earlier this afternoon here (https://news.ycombinator.com/item?id=10693535).
Re: Why it’s so hard to innovate in the e-mail space (2014)
#29Earlier quoted context omitted.
Email is most certainly not dying.
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.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#30Why 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…
Sending is easy. Receiving and sorting and filtering is harder.
> Sending is easy. Receiving and sorting and filtering is harder.
I don't understand: Receiving messages on any of the transports is done every day and billions of platforms. After receiving, loading the messages into a common database, including mapping metadata such as sender, date, etc., seems relatively simple. Once in the database, sorting and filtering are simple.
What am I missing?