Isn't this taking a somewhat narrow definition of "the e-mail space"? Slack, Twitter, Facebook, Snapchat, etc. all seem like successful innovations that lots of people use to communicate instead of email.
Why it’s so hard to innovate in the e-mail space (2014)
41–50 of 68 posts
Re: Why it’s so hard to innovate in the e-mail space (2014)
#42Earlier 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.
It is declining, but it's not dying.
People are not using it for instant communication as other apps have taken the place of that, but email is very much used and useful.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#43At 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 itself. In our view, one of the major problems of e-mail (and chat for that matter) is that the discussions are not goal-oriented. So, discussions/threads can meander around with no outcome or accountability.
So, we enhance the notion of discussions to be goal-oriented.
Now, once one has the notion of goal-oriented discussions, a natural next step is to evolve a goal-oriented discussion into a Lean Process (which is basically a goal-oriented discussion with more structure) . Examples of a Lean Process might be a Blog Article process, a Product Deployment Process, a Feature Design Process, an Issue Escalation Process etc.
We've done all this in an email-LIKE interface. I guess we'll leave it to others to decide whether this constitutes innovation in the e-mail space :)
Re: Why it’s so hard to innovate in the e-mail space (2014)
#44The biggest problem is that E-mail demography tends to be broader than many of the other services.
Some of E-mail users are very conservative and specific about how they handle their E-mail. (Some of which are very risky behavior, which I actually tried to correct by explaining why that's bad idea, but ultmately given up...)
There are demography between novice and expert. Novices tend to not care about changes so much; some even won't notice changes, as long as features are somehow accessible. Experts may have some particular tastes, but they'd be quick to find solutions to change things around when they have to. But people in between tend to be very vocal about any changes and they can't (or not willing) to find and accept "solutions" -- they will be the first one to complain when UI elements like buttons shift around the screen. Unfortunately, as universal E-mail gets, a lot of E-mail users fall under category. (Though, in different ways, "experts" can be very particular about how they handle things can be very stubborn when there's no good reason presented to change -- but it's a bit different context.)
I can't even imagine how tough it will be to migrate some of people I know to anything other than what they are used to.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#45Earlier quoted context omitted.
SMS is used to send tiny chunks of text, and SMTP can be used to send message content in HTML format and rich text in addition to plaintext. I haven't worked much with rich text format, but HTML format for sure would be relatively impractical via SMS (XML adds a lot of characters, so you would have a lot of little chunks to send if you wanted to send HTML over SMS).
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?
Re: Why it’s so hard to innovate in the e-mail space (2014)
#46It'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 t…
It's also very hard to push the benefits of the integration without having the product on both sides of the communication. A similar issue popped up in Windows phone 8. They combined sms and Facebook messenger -- but if you
Re: Why it’s so hard to innovate in the e-mail space (2014)
#47I'm trying to build an email platform too, yes it's hard. But I thought it was only because I'm a beginner and 1 man team. Some of the reasons why I think it's hard: * I don't think security was a big deal to many of the mail applications when they were being built. I tried and gave up so many times trying to find a strong hashing algorithm that both dovecot and ruby supported. There was practically no documentation…
> Sometimes emails have "
" in them and sometimes they have "\n".
" in them and sometimes they have "\n".
One of those should have an HTML MIME type, one should have a plaintext MIME type. The decoding is specified in detail in RFCs and W3C recommendations, please follow those rather than try to implement this using try and error.
> Not everyone uses the RFC standards!
That is unfortunately true, ...
> I thought the RFC said that a subject can only be 78 chars long.
... and one of the major reasons why is because people think but don't read. There exist all kinds of crazy myths about the content of RFCs, which is how all those broken implementations arise, this seems to be one of them--but feel free to point out which RFC says this where, in case I really have missed it.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#48Earlier quoted context omitted.
SMS is used to send tiny chunks of text, and SMTP can be used to send message content in HTML format and rich text in addition to plaintext. I haven't worked much with rich text format, but HTML format for sure would be relatively impractical via SMS (XML adds a lot of characters, so you would have a lot of little chunks to send if you wanted to send HTML over SMS).
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).
Well, if you want that, then you should support open protocols. The business goal of twitter, facebook, etc. is to lock you into their communication system, so if you expect developers to integrate those, you really expect them to invest into integrating with those who want to destroy the open ecosystem that they rely on and who will do whatever they can to hinder the integration.
Re: Why it’s so hard to innovate in the e-mail space (2014)
#49It'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 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 solution in order to make email easy to use (or so they claimed).
Re: Why it’s so hard to innovate in the e-mail space (2014)
#50It'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…
> Then, a threaded email client.
Just to be sure: you are aware that that is a standard feature of email? There are headers that provide threading information, at least if you use non-crappy user agents.
> It would help to have the convention that an email with subject but no text, text but no subject, or text the same as subject is displayed like an instant message.
No, that would be a terrible idea, you never ever should redefine the semantics of existing messages. If you want to encode a new type of message, use metadata to mark it as such, that is what those extensibility mechanisms are for. Add a header to indicate that the sender is following some new convention, or add a multipart/alternative MIME part with a new MIME type that encodes such messages, with a fallback text/plain part for clients that don't understand the new convention. But whatever you do, never encode new semantics in a form that already has an established decoding/interpretation/meaning, and also always do it in a way that provides as much of the same functionality as possible with software that doesn't know about your new invention.