Danno 03 Oct 05

Any chance of 3-way conflict revision capabilities at some point?

Philip 03 Oct 05

No one can accuse the Signals of ignoring user feedback!

JF 03 Oct 05

We don’t have plans to deal with 3-way resolution at this time. Just simple 2-way will solve the the problem for 90% of the people.

Mark Wubben 03 Oct 05

Philip, nope. But makes you wonder if this shouldn’t have been in there from the beginning?

aaron 03 Oct 05

Is this another one of your marketing schemes?

Launch a product and on the day of, add a new feature… you guys crack me up.

Josh Goebel 03 Oct 05

I wouldn’t be surprised if it was the latest marketting ploy, but it’s far more likely that concurrent editing collisions just weren’t really a problem during 37signals internal testing and the public outcry (if you can call it that) came as a shock but a “no-brainer”… hence the immediate response.

Just my $0.02.

Ryan Christensen 03 Oct 05

I’m curious, was this feature intended for later release pushed out early, or was this actually built from scratch over the last 24 +/- hours as a response to user requests?

Danno 03 Oct 05

I’m not saying that Writeboard should handle a 3-way merge, just that it might be able to say “Hey, looks like we’ve got a three-way merge here! Here’s the changes that were made, what do you want done?”

Like, foisting the hard part off on the user, but being nice enough to tell them when they’re being foisted upon.

JF 03 Oct 05

No marketing here. We built this feature in about 2 hours based on people’s feedback today. When you have simple software you can do things like this quickly.

Jim Jeffers 03 Oct 05

Geez.. comments on this blog are highly critical / skeptical these days.

Luis Carrasco 03 Oct 05

I think it would be cool to add another link like:

Alert me by email when the other person is done editing.

Or even cooler: Send me an IM notification, but i guess that would be a little bit more complicated.

Dan Boland 03 Oct 05

Does this mean that the first person to log in and start editing takes precedence over the second person? What I mean by that is, do both people get the same screen? Or does the first person get nothing and only the second person gets the screen? If they both get the warning screen, I can imagine a lot of unnecessary waiting.

Josh Goebel 03 Oct 05

Does Ruby have Jabber library? Might not be so hard to add Google Talk notification as you think if that was the case. :-)

Ben Askins 03 Oct 05

Great feature, thanks.

RyanW 03 Oct 05

OK - I think this post seals the deal for me — I’m dumping .NET and going to Ruby on Rails :)

Anonymous Coward 03 Oct 05

Few feature requests.

1) Any chance that we will get Spell-Checking in Writeboard? I think it is necessary part of any word processing application now days. It would save lot of embarasment if we had a way to spell check our stuff before showing it to our friends and collegues.

2) Also, could we have a option to receive an email or IM (already suggested) whenver someone updates the Writeboard. I know RSS feed is there, but unfortunately 99% of the internet population has no clue about RSS. You should have this feature for commenting on this blog as well.

Love Writeboard’s Simplicity.

Sparky 03 Oct 05

Nice feature - however, it currently doesn’t seem to differentiate between oneself and other users. For example, if I:

* start editing a page
* close that window
* open the same document in a new window
* click Edit

I get the message: is already editing…

Sure, I can just hit “edit anyway”, but it’d be better if it looked at the username here, methinks…

brian 03 Oct 05

Agreed, a username or email addy would be fantastically more helpful than “Someone”. My wife just ran into that problem and was stopped dead in her tracks. “I think it was me, but was it?”

brian 03 Oct 05

Which is odd, because the screenshot says “David is editing this writeboard right now!” And when we ran into it, it says “someone”. What gives?

Don Wilson 03 Oct 05

Why not rely on an Ajax-updater that will update the page every five minutes which will allow for the best results. After 7 or more minutes without an update, unlock on next trial of edit.

Don Wilson 03 Oct 05

Sure, I can just hit �edit anyway�, but it�d be better if it looked at the username here, methinks�

Possibly make an

JF 03 Oct 05

And when we ran into it, it says �someone�. What gives?

If the person viewing the document hasn’t saved it yet and entered their name into the “Name” field then we don’t know who they are so we say “Someone.” Once we know you we call you by your name.

ceejayoz 03 Oct 05

Glad to see the change!

Don Wilson 03 Oct 05

I hope you italicized or differentiated between the words “Someone” and someone using “Someone” as their name.

Pointless? Yes.

Don Wilson 03 Oct 05

In regard to my cutoff post…

Possibly make an onunload attribute for the body tag that will signal the service that the window has closed.

Vann 03 Oct 05

Any chance of integrating writeboard with basecamp?

brian 03 Oct 05

So, how many lines of code is writeboard now?

Aaron Stanton 04 Oct 05

What a cool idea. It’s the simple ideas, obvious in retrospect, that make big changes.

Mike 04 Oct 05

Don: Someone is totally pointless, you’re right ;)

New locking feature kicks ass. Nice job guys.

Don Porter 04 Oct 05

Basecamp integration would allow the collaboration of attorneys (and clients) on a settlement document; a partnership agreement; a litigation discovery plan; or an appellate brief - even now though a useful and elegantly simple tool for small firm and solo practitioners.

Andrew Crow 04 Oct 05

Nice feature. It’s got a home in Writeboard and it seems appreciated…by most of the people here.

Ray Irving 04 Oct 05

Yep, I’d love to see this integrated into BaseCamp.

Will this happen Jason?

Roope Rainisto 04 Oct 05

Hope you don’t take this the wrong way, but isn’t document locking really the totally non-optimal and non-userfriendly way to handle this problem?

The problem is allowing multiple users to edit the same text without replacing and overwriting themselves at the same time. Document locking is the age-old way, but it doesn’t really then achieve the original goal. Proper multiple real-time editing would offer this. Yes, it’s a lot more complicated to implement, but the end users don’t care about this.

If Writeboard be the same as currently, but offer proper synchronous real-time editing for multiple persons, then would I praise it to the heavens… Document locking doesn’t do it for me, frankly.

Dominik Wagner 04 Oct 05

Sorry guys, this is worse. The only thing worthwhile here would be merge on save, if the document changed, with manual interaction and some ajax bliss of showing what was changed in the revisions I didn’t get.

Anonymous Coward 04 Oct 05

He said yes to this yesterday.

Chriztian Steinmeier 04 Oct 05

For what it’s worth: I have absolutely no complaints, whatsoever… it just works. Thanks guys!

Tim 04 Oct 05

How about using CVS or Subversion on the backend to handle merges…?

Jim Thompson 04 Oct 05

The 45-minute timeout is a good thing. It keeps me from falling asleep at my monitor and preventing anyone else from working until I wake up.

But here’s a scenario: I’ve locked my document, and I’ve been working on an update for 40 minutes. The deadline to lose the lock is fast approaching, and I’ve got at least ten minutes work left. I really need to keep lock until I’m done. If I keep working and try to beat the deadline, then I risk losing the lock. If I save, then try to lock another edit, there’s a window of opportunity to lose the lock to someone else.

What you really need is a “save and keep editing” button. It would (a) save changes to the server; (b) extend the lock by, say, 15 minutes.

Actually, you need a “save and keep editing” button anyway. My browser, Mozilla, rarely crashes, but if it did I could lose work. It’s true that I can save anytime I want, and then immediately edit again, but a “save and keep editing” button would make that just a little bit easier. And it’s the little things that make a great UI, right?

James 04 Oct 05

A “Save and Keep Editing” function would be helpful for end users in BaseCamp, as well. Just the other day I had one extremely ticked off client because their browser crashed after an hour of editing a BaseCamp post, that they hadn’t copied to clipboard or saved at all.

I’ve also had clients confused as hell by hitting “preview” to see their post, and then using the browser’s “back” button to go back to their original - which is no longer there. Breaking the back button for me? Not such a big deal, but this tool ends up being used by people that aren’t saavy as to know what’s up.

One of the huge benefits of OS-based editing tools is the ability to recover from things like this. Browsers and web-based apps seem very weak in this regard.

Mike Moscow 04 Oct 05

Wow! like Philip said, “No one can accuse the Signals of ignoring user feedback!”

How can some of you guys dismiss this as a marketing ploy? - ridiculous…

James 04 Oct 05

One other “Save and Keep Editing” related comment, is God forbid that I or my end users accidentally refresh the wrong browser window/tab (ie - the one that is being used to compose a post). It annihilates my work. Even integrating a simple “Save to Clipboard” icon, that puts the text in the OS clipboard, would be an improvement.

SR 04 Oct 05

Wiki’s are icky? This is looking more like a wiki everyday. Maybe a usable wiki or a wiki done right.. but surely a wiki.

This is a good feature, but since this product is based of of wiki it should be expected. I think it’s silly to think this wasn’t planned.

Anyway doesn’t really matter. It’s a good product!

Don Wilson 04 Oct 05

A few suggestions…

1) When someone sends you an invite to join editing a document, could you please include the given email, or at least give the person an option to include his/her email.

2) In said email and any others, those that are using the body of the document as the subject of the email should be plain-text, not htmlized.

Dave Churchville 04 Oct 05

Good responsiveness, must be that new alien on staff ;)

So, out of curiousity, how did you come up with the original feature set of WriteBoard?

Getting Real says “no functional spec”, but do you think a couple of use cases would have raised this issue sooner?

Or did you think about it, but wanted to wait to see if people really noticed or needed it?

Obviously the ability to respond quickly makes this almost a moot point, but for non-hosted apps, missing a key feature would be sort of painful.

JF 04 Oct 05

We came up with the idea because we needed the product.

JF 04 Oct 05

BTW: Just added HTML export as well.

Brad 04 Oct 05

Really like it.

However, i’m not sure about the delete option that is available to anybody who logs in.

Can’t there be one owner (the page creator) who alone has this right? If there are five collaborators and one doesn’t know what they’re doing or are malicious or for whatever reason deletes the wb, it’s all gone Pete Tong.

Or maybe you had a theory about this and a reason. Could you explain?

Don Wilson 04 Oct 05

Maybe that’s why theres a password for editing the documents? :)

Brad 04 Oct 05

Maybe, it just seems vulnerable to me, that’s all. Especially if it’s important. Hence all the rollbacks and versions. But all the versions are moot if someone just deletes the page.

Dan Boland 04 Oct 05

That’s a good point Brad, but no software on earth can prevent someone from being a dick (or just a dope).

ceejayoz 04 Oct 05

Sure, Dan, but that doesn’t mean you can’t limit the damage they can do.

Making only the document creator able to delete the page (thus wiping out all revisions of it) would be a sane restriction, in my opinion.

Garrett 04 Oct 05

This is good stuff. The backpack integration makes it priceless. This is the first product ya’ll have released that I had an immediate need for.

As for all of the criticism…

If you are not being criticized, you may not be doing much. - Donald Rumsfeld

John 04 Oct 05

Is there any chance that the RSS will be updated regularly for the Writeboard?

My feed hasn’t been updated for more than 24 hours!!!

Thanks …. I hope you are working hard.

RS 04 Oct 05

Brad, if anyone deletes the writeboard an email is sent with a recovery URL to the creator. The writeboard can be recovered if the link is clicked within 7 days of deletion.

Todd Warfel 04 Oct 05

What about “view current “someone’s” edits” prior to making the decision to overright or not?

Adrian 05 Oct 05

I second Brad’s point that delete should only be available to the Writeboard’s creator.

I know that the delete has a rollback option, but that is not enough. (Try it by setting up a dummy WB and deleting it.)

I’m working on a board that has numerous contributors and for which the password is effectively public. So far people have been good but it’d only take one idiot to veto the whole thing by repeatedly deleting the board.

If this wasn’t a use case that WB was created for, fine. But I’d ask that it should be considered and therefore this enhancement implemented.

Greg 11 Nov 05

Hi,

First, Backpack rocks. I’m a paying customer at the $9 rate.

Second, a few questions:

1. I got a lot of IE errors in the last few days, and as of 9:52 EST they seem to have gone away. Most had to do with overflow values. Am I imagining this?

2. With TaDaList, it seems to work fine if I put non-trivial HTML (for instance, an image reference) in the list note. This is very handy. Any problems with this? The TOS seems to allow it.

3. I’d be _so_ happy if BP users could share whiteboards as web pages the same way we can share BP pages. Any thoughts on this?

Best wishes,

-greg