Nick (user nickbw) and I applied to YC a year ago with a sketch of an idea and didn't make the cut. But rejection was just the motivation required, and we incorporated and launched while holding down jobs.
Please have a look. All comments welcome. Some questions:
How should we think about pricing? For instance, as it is, the highest tier of service is quite expensive but allows you to run riot on our server. Is that worth offering, or does it look scary to have that big dollar amount on the signup page?
Draftastic sounds a lot like Google Docs, but it's quite different in practice. (GD is like a whiteboard; we're like a revision control system.) Should we worry about making that crystal clear up front, or does it look weird to define ourselves that way to new users?
Given that it could be marketed to practically any kind of business, what are some good sorts to concentrate on? Where do we look for people stuck in the mail-a-Word-file-around groove?
How can we persuade more casual visitors to try it? We made the free signup process as easy as possible, but it's still several clicks. Is it worth trying to maintain an open sandbox? Does a sandbox even make sense when we're designing for cooperative groups?
A few things: You position your app as a "collaborative editor", yet it took me almost two and a half minutes on the videocast to even get a look at it. I know you want to show how easy it is to sign up, but is that really necessary? You're not selling a sign-up/sign-in page, you're selling your service. Furthermore, if I were selling an app that does collaborative editing, I wouldn't harp on on the whole "revision control system" angle. It's redundant knowledge - I know it's there by seeing the amount of dates & times (and it's also briefly shown in the videocast), so I'll use it when I need it. See how Wikipedia does it: They don't go on and on about how each page has a "History". All that they do is put an "edit" button on each page or page section. Less in your face == much happier users.
Next, when I read the description, I was thinking of something like MS Word, online, with multiple people working on the same document, yet it comes across as an ajax-ified blog engine: "Version 1 by Nick today at nn:nn pm" isnt really information I need staring back at me at all times.
Some nit-picks: I would edit out the breathing-into-the-mic. No offense, but it's kinda grating :) And Charlie sounds kinda bored/indifferent...
The screencast sucks. We know it, and we're in the middle of redoing it. We threw it together quickly because we'd heard from a few people who wanted to demo the service to bosses or co-workers, but thought signing up for a test account was too much effort or "commitment". We want to get people over that activation barrier.
Suppose we had an extremely short video that showed only the live multi-user editing, and ignored the permissions and revision control features. If you were a business with a use for a collaborative editor, would that be compelling enough for you to sign up and try it out?
For people who want "MS Word, online" Google Docs basically has it covered. We don't want all those Word features -- we just want live sharing that isn't painful, which is the one thing GD doesn't manage. I take your point, though, that we're trying too hard to emphasize our own feature list.
What if I want "shared MS Word" (presumably online) or "collaborative MS Word docs"?
If signing up is complicated enough that a video is a reasonable way to explain it, the signup process is broken. Why not fix it instead of explaining it better?
Why have sign-up at all? Why not let new users "start a doc and tell people about it", which should be very simple. After they've established that they can do what they want, biz users will then ask "how do I protect my docs?".
For collaboration, continuous editors drive me nuts. Someone inevitably winds up typing over someone else. It's tedious in SubEtha with just two users, and gets worse with more users or with the added latency from web apps.
We're trying to impose just enough structure to eliminate collisions.
Any suggestions for ways we might soften the hit to flow?
Maybe a good compromise would be to make each line a "block". If you're the first to click a line, you get a lock on it to edit it. Make a new line (i.e. block) by hitting enter/return.
I disagree that people typing over each other is a problem with continuous editors. If you're editing different lines it's not a problem at all. If you're editing different parts of the same line SubEthaEdit can handle that fine. The only ambiguous case is when your cursors are at the exact same point when you start typing. Since SubEthaEdit shows you where each user's cursor is you can clearly see if you're about to conflict with someone else. The key to this type of collaboration is it need to be very much real-time, the lower latency the better.
Please have a look. All comments welcome. Some questions:
How should we think about pricing? For instance, as it is, the highest tier of service is quite expensive but allows you to run riot on our server. Is that worth offering, or does it look scary to have that big dollar amount on the signup page?
Draftastic sounds a lot like Google Docs, but it's quite different in practice. (GD is like a whiteboard; we're like a revision control system.) Should we worry about making that crystal clear up front, or does it look weird to define ourselves that way to new users?
Given that it could be marketed to practically any kind of business, what are some good sorts to concentrate on? Where do we look for people stuck in the mail-a-Word-file-around groove?
How can we persuade more casual visitors to try it? We made the free signup process as easy as possible, but it's still several clicks. Is it worth trying to maintain an open sandbox? Does a sandbox even make sense when we're designing for cooperative groups?