"Maybe the dream of an email-free future isn't dead; maybe it just means a future in which email is merely a sliver of our communication rather than the whole pie."
Email is victim of its own success, like cars & highways in America.
Highways are not bad per se, they were and are an incredible revolution. But too much of them means the value we collectively subtract constantly diminish. We need alternatives: walkable neighborhoods, bike lanes, tramways, trains, bus, etc.
It's the same with email, we need alternatives. Chat services like Slack & HipChat are good examples for internal communication.
Email's decentralized nature and ubiquity mean it's the perfect tool for external communication. I don't see why this would change.
Last week I did a visualization of all email clients in time from '79 to now (http://email-apps-timeline.missiveapp.com). It shows that there is a lot happening in the email space right now, even if the technical barrier to entry, as the author implies, is so high.
Given that the set of folks that are interested in and capable of making widely used end-user communcations software, and the set of people who are not interested in making walled gardens appears to have no overlap, you're going to be waiting for approximately forever. :(
Just as long as part of your glorious future is a fully open and Libre protocol, federated servers, and -at a minimum- feature parity with email I'm 100% okay with it. :D
The barrier to entry isn't high at all. The author was able to create an email client in 3 weeks. That's not a lot of time.
Yes, making a solid GUI app will take a year. But that's the case with any solid app, and I doubt email is significantly harder than other productivity apps.
It impossible to overstate how wrong you are. Read some of my comments in this thread.
One of the absolute worst mistakes you can make as a developer is to assume that what you don't know or understand must be easy. That's the path to ultimate project doom -- don't do it.
I never said that I thought it was easy; I just don't see the email-specific barrier to entry. Syncing is hard in general, dealing with legacy systems is a pain, parsing poorly compliant file formats is annoying... But you have that everywhere.
What do you expect? That writing an email client should be as easy as cobbling together a map view with Google Maps? If that's your point of reference, then yes, there is a barrier to entry.
In another reply you said that your MVP took 4 years; but looking at your website I see something that tries to compete with Outlook. That's hardly what I'd consider an MVP.
I'm pretty certain that I could develop a solid email app in a year. Of course, it wouldn't do everything that existing mail clients do, and it wouldn't be compatible with every email provider, and it would probably be limited to a single platform. But it would do some things differently enough that it would be worthwhile for a few people.
If you think there's an insurmountable barrier to entry, you need to take a step back. There is absolutely no need to compete with the best existing clients on a feature-by-feature basis to enter a market. Focus on a small niche, and go from there.
> I just don't see the email-specific barrier to entry. Syncing is hard in general, dealing with legacy systems is a pain, parsing poorly compliant file formats is annoying... But you have that everywhere.
Have you ever written a production grade email client?
So you're claiming that you don't see the email-specific barrier to entry. Which is to say, you're arguing against it. While people who have authored such software are claiming the opposite.
Yet you appear to have zero willingness to entertain the idea that those who have come before you have learned what you don't yet know?
Very arrogant.
There most definitely are email-specific barriers to entry. No reason to list them out again as @dmbaggett (among others) have already been kind enough to give up their time doing so (for the benefit of all to learn).
Not buying what you're selling. So I'm sure you'll continue with your arguing and snap back with a terse reply.
I'm sorry if I offended you. I felt that my argument was discredited by appeal to authority.
I absolutely believe that the difficulties dmbaggett lists are real. I've experienced some of them myself on the few occasions that I've written code that integrates with IMAP and POP3. I don't assume that I could find a solution to all of them in a short time.
But here's what I think: These difficulties are not "a barrier to entry". You don't need to solve all these problems to enter the market. You don't need to compete head on with the best competitors to enter a market. You don't need to make an email client that works for everyone.
You just need to focus on specific audience, and solve a problem that no-one else does. If you do that, people will use your product even though it falls short in other regards. And you can leave the hard parts to the big companies.
Your points are valid, no need for them to be blindly discredited. You obviously have real world experience.
The key here is your approaching the problem from a "here's what I think" standpoint and not a "based on the past 5 years of me doing this" standpoint.
Again, it boils down to no having learned, what you don't yet know.
More thoughts...
I do have to say, though, that integrating email features into software (not an email client) these days can be trivial. For example, Rails makes a lot of it trivial.
But that is a very poor litmus test.
The difference between that and a full blown, production level, narrowly focused, tailored towards a specific audience, solving problems that no-one else does email client... are worlds apart.
You have 2 choices today, third parties (Gmail API, JMAP, Nylas, etc...) or diving into a raw IMAP connections (as an example).
The former provides general purpose layers, abstracting the complexity (to some degree). The disadvantage being they are general purpose, features everyone has.
The latter provides the flexibility to create what has not yet been created. And/Or backfill what the general purpose solution lacks (typically a lot).
In general, your approach to software, products and an MVP is spot on. Obviously you have experience doing this.
The point that I, and others make, is that email does not fall cleanly into that same approach. Why? For all the reason already listed plus a TON more not listed.
This is where you are unwilling to be open minded, and as mentioned previously, it's a classic mistake seen many times before.
Wow, that's great. One immediate bit of insight from the top right of the chart is how the modern email client is almost universally an iOS app, with other platforms if you're lucky.
Agreed...but I wonder if that's because ios folks tend to be more interested in products with more design built into them, in other words there is more of a market for a wider variety of products...? Or, if maybe non-ios users tend to think of email as a utility and figure "design-y" products for such "mundane" things as mail are "meh". Mind you, that's not my opinion, but just curious myself.
As far as I'm concerned chat and email are essentially the same thing: messages that get sent from an individual to a group of other identified individuals (as opposed to a broadcast platform where you don't have to identify all the user in advance). There's nothing to stop you making a UX for a mail app that feels like a chat app, or for a chat app that feels like a mail app.
Here's one difference: Chat is interactive and email is time-shifted. Users may use them other ways, but those are the fundamental designs.
In fact, I think many problems people have with email boil down to response times. If there was a way to senders could designate how soon they need a response, recipients would be face fewer interuptions and deal with email in batches when it fits their schedule.
Email has the priority field, but so few use it that you can't rely on recipients being aware of it and there are no social conventions about its meaning.
I don't think there's really anything fundamental about them that means that chat has to be interactive and email has to be time shifted, I know many people who deal with chat messages in batches much later than they're sent, and people who will respond to email within seconds. I think that's a ux choice, just like encouraging long vs short messages.
I do like your idea of designating a response time, but it probably requires too much from the sender. It might be that you could train rules on the client that could do a good job of working out how quickly things should be responded to so your client could batch appropriately.
I only do email at 09:00 and 15:00 at the moment, I've never had anything bad come of it. Honestly, if something is time-sensitive high-impact, sending an email in a fire and forget manner is close to a firing offence. That's just not an acceptable way to communicate urgency.
That works for some professions/working environments. I did that when I was working in an office and my entire team was in one 2x6 cubicle row. Email becomes much less important. Chat was nearly nonexistent. Now as a consultant working from home, chat is my lifeline (sometimes we even use IM while we're on the phone with each other to exclude some phone participants from a side conversation) but email is everything.
I have clients who aren't on my company's chat system and can't call me because I'm on the phone all day. Chances are if they call I can't pick up. Then there are the client's vendors who will not call me for any circumstance, because that's not their place. They're not paying me, and I hold no control over their wrk. But we'll email back and forth.
Our email system has no "urgent" flag, it's up to you to read them all as they come in and prioritize properly. If you're lucky, you'll have a PM who will spot an urgent email before you do and ping you on chat if you're a few minutes late.
Not really. I sometimes send chat messages when the users are offline knowing they will be read later. Likewise I have email chats where we respond more or less instantly (when my friend doesn't have a chat client). Its a bit clunkier to use, but works.
Eh, chat can be time shifted as well. My team regularly posts chat messages to Flowdock even when I'm not online (and I do the same). It doesn't get overloaded because the # of users are limited to a small team.
Maybe I'm a dinosaur all my experience with Chat comes from IRC in the 90's (which was horrible - net splits anybody) maybe it has gotten much better now. I wouldn't know I use email heavily today. Chat - rarely.
The key difference to me is that Email is broken down into discrete messages by sender and subject it is easy to archive retrieve and resend (forward) those messages with additional attachments if need be. If you can do that with Chat now great.
To pick a nit: in the US, neither the Interstate Highway system nor the State Highway systems have much to do with car-centric design in cities and neighborhoods. [0] I used to live in a vaguely large-ish city that had both a State Highway, and an Interstate Highway that ran through it. These were two four-to-ten-lane [1] roads out of many, many, many other roads of widely varying widths and lengths.
The city was car-centric not because of the two highways that ran through it, but because the city managers never, ever made alternatives to private car ownership a priority of any sort.
[0] I mean, other than vaguely encouraging individual car ownership by making it relatively easy to cross large distances in an automobile. But, both highway systems play a big part in making inter- and intra-state shipping economical. Not only do we derive a huge amount of good from this property of the system, properly funded and designed public transit systems can also take advantage of these roads to enable city residents to ditch their cars.
[1] The Interstate varied in width, depending on where you were. Once you got out of the city, it was most frequently a divided four-lane road.
I think e-mail now in 2015 is like the fax machine was in the late 80s early 90s useful but rapidly becoming obsolete. Sure it will hang on for some reason just like the fax machine has but everyone else will have moved on.
Email is victim of its own success, like cars & highways in America.
Highways are not bad per se, they were and are an incredible revolution. But too much of them means the value we collectively subtract constantly diminish. We need alternatives: walkable neighborhoods, bike lanes, tramways, trains, bus, etc.
It's the same with email, we need alternatives. Chat services like Slack & HipChat are good examples for internal communication.
Email's decentralized nature and ubiquity mean it's the perfect tool for external communication. I don't see why this would change.