Submittable (YC S12) raises $750K to replace email
pandodaily.com
pandodaily.com
The part where it turns out "replace email" actually seems to be "replace usage of email for an apparently narrow document-editing task" is some good old-fashioned link baiting.
Anyhow, I'll bite.
What does this tool do that SharePoint doesn't? Or other email-integrating document management tools such as (shudder) TRIM?
it turns out "replace email" actually seems to be "replace
usage of email for an apparently narrow document-editing
task" is some good old-fashioned link baiting.
From what I understand of the description the idea is that it becomes a management layer on top of email for submissions (hence submittable) that need some collaborative management. Similar to how google docs forms work, but instead of the results ending up in a spreadsheet they end up in the collaborative document editing system.After looking at their website the use cases seem clear, the Pandodaily article does seem to lack a simple explanation: http://submittable.com/
There's definitely a market here, as the zillions of DMS vendors have demonstrated.
I guess I'm a curmudgeon who feels annoyed when people pass off as REVOLUTIONARY HYPERNEW AMAZING ZING BOOM CRASH things that, upon closer inspection, turn out to be nice implementations of a known genre.
(I hasten to add that the blame, if any, seems to rest with the journalist, not the Submittable team).
(I hasten to add that the blame, if any, seems to rest
with the journalist, not the Submittable team).
I went back and read the article again and it really is quite questionable how the company is presented. The author seems to have tried to spin some sort of "email is terrible" narrative and got lost along the way.I think the author should have tried to explain how Submittable would provide value to a company like Pandodaily and that would have been better at putting across the value. For example Pandodaily has a "tips" email which would be the perfect use case for the editorial portion of Submittable, yet that is unmentioned and instead the author tries to explain what seems to be a summary of watching someone use the site for 10 minutes.
They also do not seem to have mentioned any of the other specific types that Submittable cater to, which includes resumes, audio / film submissions and grant applications, all of which have their own systems to enable proper management.
Hopefully Submittable will be covered again by someone else and properly so they have a fair shot at being exposed to the masses, because this article is really doing a poor job of even hinting at what Submittable is about.
That said, as others have already pointed out, Submittable seems to be something completely different anyway, with no ambition to do what email does.
E-mail needs two things done to it but they're difficult to wrap one's head around.
The first thing it needs is to get more simple. E-mail has a lot of quirks, crust, special cases, and other things. This applies to SMTP but also to addresses (TO, CC, etc). Just as one example did you know that technically almost any character is valid in an e-mail address? Did you also know that EXAMPLE@ and example@ are two totally different addresses (case is as equally differentiating as characters)?
I liken this to the XHTML effort (to make HTML more strict). We need to take e-mail as it is used today, and essentially call the "edge cases" illegal. This would be compatible with 90%+ of existing implementations but would make future e-mail implementations (both client and server) far more straight forward. As it stands today you cannot build an effective client or server e-mail system by just looking at the respective spec's since there are so much strangeness.
Secondly AFTER the above has been done AND adopted they need to develop a new standard to replace HTML as the display format for e-mail (XML based). This should include things like signatures, quoting, in-line pictures, tables, and a small subset of text styling. Essentially take HTML, remove 50%+ of the functionality and then ship it as a standard people can cheaply implement.
Why? People who like HTML emails are happy with it; people who prefer plain-text emails (like me) won't like your solution either, since it's XML.
I think we already have a decent format for lightly formatted email, and it's the plain-text conventions (in which Markdown was based). Or Markdown itself, if you want something closer to a standard.
Plain text should stay as is. HTML is the problematic format that needs addressing. When they first started using HTML for e-mails it was just the natural thing to do, but with the benefit of hindsight it was a mistake.
So I am suggesting we take a subset of HTML, add a very small set of e-mail specific features (signatures, quoting, etc) and then deploy. This format should be entirely display-able with a single XSL (as the easiest implementation).
I disagree: Libraries to render HTML already exist and will continue to be developed, since they are used in web browsers anyway. The development effort would be greater if we introduce another (new) format specifically for email. Every E-Mail Client that wants to do so already implements HTML display.
Most of the security issues are mitigated by not running Javascript and disabling loading of remote resources, by default. Then it's as safe as a web browser with NoScript.
The problem with HTML mail in my opinion is simply that it is overused. Often it is unnecessary bloat, and plain text works just fine.
Also I would assume that the product also uses email, or does the person submitting go through a web app for the whole process.
I think this is purely a case of a link bait title and an article that does a poor job of explaining what the product actually does. Which isn't ideal as the method your startup first gets exposed to a wider audience (first time I have seen it anyway).
This is like Google's pitch being "Our search will dominate because we use a single text field, and we have a 'surprise me' button."
If you want to "replace email" you have to replace its infrastructural value to the internet too, not just the superficial day-to-day convenience of messaging. As long as every website requires email to register, messaging is a secondary consideration.
I think that 750k could have been used for a failure-less-obvious.
EDIT: for tone.
Email is a really general purpose tool, but I think we will continue to see tools that take out a small chunk of email use cases.
e.g. google docs, IM, facebook messaging
Look at what we have now - basecamp, all kinds of free instant chats, group video chats, all kinds of organizational SaS, etc etc etc. Yet we still have ridiculously long email chains that often branch off and start to have a life of their own.
Why? Because
1) Everyone knows how to use email. Most employees don't want yet another way to communicate.
2) Your average office employee is pretty... average. And roughly half of the employees are dumber than that.
3) Training is expensive. One quick demo on a projector will not train your employees to use some new software. It's like half-life, 50% will learn after a month, 75% will learn after another month, etc.
4) You will always have employees who don't get this new software, many will probably not give a shit about learning a new tech, while they have a perfectly working way of sending a message. They will realize that when they change jobs, chances are, they won't be using this new software. But email will be there.
5) It is similar to the craigslist syndrome - it's awful, but everyone uses it, because... everyone uses it.
I agree with your comments about average employees. But perhaps this is changing? People are used to different messaging systems now, with various social networks and smart phones exposing them to better (or at least different) ways of communicating.
That said, my personal take is that you should start with kids. In contrast to the "dumb" people in the office, my younger sister's friends don't know how to use email. It's what their parents use (gross!). FWIW they use Facebook and a random collection of mobile apps for all online communication.
This is like saying I doubt people will be using phones 20 years from now. Email was been around for nearly 40 years[1] It is the de facto standard for written communication between two computers and de-centralized systems need standards in order to work efficiently.
Although it was probably said earlier, the first time I recall hearing it was around 1980. It was "I doubt 2 years from now people will be using email." at that time. Maybe it wasn't exactly 2 years, but it was much less than 20.
Then it's soon the late 1980s, and we're still using some form of email. We hear, "I doubt 5 years from now people will be using email."
Quickly enough, we're in the early 2000s. Hotmail has really taken off, Yahoo! Mail is pretty popular, too, and Gmail will be coming along very soon. Nevertheless, people are saying, "I doubt 10 years for now people will be using email."
Here we are, about a decade later. Guess what? We're still using email, and more than ever. And what do I read today? "I doubt 20 years from now people will be using email."
I'm quite confident that when we're in the 2030s, we'll still be using email.
This simply isn't true. Most people don't know how to use email, which is why these stupid memes of "everyone hates email" and "email must be destroyed" persist. What people hate is email being used in a dumb way. Or to be more blunt: People hate dumb people. No surprise there, really. So a solution is to get better at getting rid of dumb people. One way to do this is to persist in using email well, and demonstrating (with persistence and persuasion) the better way when rolling across crap use.
This is one of those (rare) situations where the technology and infrastructure is fine; the people using it are the problem. Email can be incredibly effective when used correctly.
Mind you there are certainly email clients which make it far too easy to use email poorly.
The conclusion is still the same. This won't solve the "problem" with email.
Which is not to say that you don't have a point either, but rather just that your assertion of "simply isn't true" well...isn't true.