

Ask Hacker News: Review our block-based collaborative editor - celoyd
http://draftastic.com/

======
celoyd
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?

~~~
slater
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...

~~~
nickbw
Thanks for the feedback!

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.

~~~
anamax
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?".

------
tlrobinson
Looks nice, but I much prefer continuous (not block-based) collaborative
editors, like SubEthaEdit.

Having to switch between blocks (or create new ones) isn't hard, but that
slight effort required breaks up the "flow" of editing a document.

I haven't seen anything quite as good as SubEthaEdit on the web yet.

<http://www.codingmonkeys.de/subethaedit/>

~~~
nickbw
I love SubEthaEdit for single-user editing. It's built into Coda, which is my
preferred web development app.

<http://www.panic.com/coda/>

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?

~~~
tlrobinson
Make it continuous ;)

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.

------
there
suggestion: remove the brushed gray background on the website, it makes the
site look cheap.

