Our book:
Defensive Design for the Web: How To Improve Error Messages, Help, Forms, and Other Crisis Points
Available Now ($16.99)
Most Popular (last 15 days)
Looking for old posts?
37signals Mailing List
37signals Services
Syndicate
The anatomy of a new feature: Editing comments
04 May 2004 by Jason Fried
We recently added a new feature to
Basecamp that people have been asking for since we launched
back in February. It’s a simple little feature called comment editing (people have always been able to edit their posts, just not their comments on a post). Yep, now people can edit their comments after they post them. Big whoop, right? Well, it was. Here’s the process dissected.
When we wrote Basecamp’s blog-like messages section, we followed the current blog convention which was to not allow people to edit their comments. We thought it was time tested and reasonable. When you say something you say something. That’s the way it’s been and we saw no reason to change it.
Well, we got an earful. People complained that they were unable to fix their honest spelling mistakes, formatting mistakes, grammar mistakes, and more. We’re all human. We all make mistakes. Good software should let you correct your mistakes. Right? Well, yes, but…
A question of accountability
As we started to think about adding comment editing, we ran into a major road-block: Accountability. Sure, we want people to be able to fix honest mistakes, but what if a client posted “We approve this project” and then a day later they edited their comment to say “We don’t think this is right… Change this, that and the other thing.” That’s a problem. The ability to change history — especially when it deals with sensitive time/money issues — is a tough thing to let into a system.
Lots of options
So we continued to think about how to handle this. We came up with a variety of ideas ranging from the status quo (not allowing anyone to edit comments) to tracking all the different versions of a comment, to color coding changes, to saving just the last 2 versions of a comment, etc. We must have come up with 4-5 solid possibilities. But, they all seemed overly complex (both from a utility and UI point of view). Complexity is something we’re absolutely committed to keeping out of Basecamp.
The solution: Time-based editing
So, last week we were discussing the dilemma with a Basecamp customer and they made a very reasonable suggestion: Allow time-based editing of comments. Of course! Honest mistakes would probably be spotted right after the comment was posted, so if we allow a reasonable window for people to edit their comments after they posted them, we should be able to get around the “changing history” issue 24 or 48 hours later. We settled on a 15 minute time frame to edit a comment after its been posted.
So, now when a comment is posted, the person who posted it has 15 minutes to edit the comment before it’s frozen. And, in order to appropriately set expectations, the time remaining is counted down on each page reload so they know just how much time they have left. As you’ll see in the screenshots above, the person has 15 minutes to fix the comment on the top. Then 11 minutes go by and the marker reads “4 minutes.” Then, after 15 minutes have elapsed, the edit functionality has been removed and the comment becomes permanent — forbidding someone to go back a day later and “change history.”
We just launched this new feature yesterday so we’ll keep an eye on it and see what people think. So far the response has been very positive.
BTW: We’re be talking more about how we consider and incorporate new features plus tons of other related material at the Building of Basecamp workshop on June 25. Less than 10 spots remain so don’t miss out.
26 comments so far (Post a Comment)
04 May 2004 | Ryan Brill said...
Very cool. I think I'm going to look into implimenting something like this into my blog. I know I've wished I could edit comments I've made on others blogs, and I'm sure it's the same with people on mine.
04 May 2004 | Mike P. said...
Great addition, something I know that I've wished I could do in Basecamp before.
Sure is a neat idea for a blog too. Save the odd double post when people really foul it up...
04 May 2004 | Michel Vuijlsteke said...
We made something similar to Basecamp a year or two ago and ran into the same problem. Our solution was to allow comment editing as long as no-one except the author had read the comment.
04 May 2004 | Mark Fusco said...
That's a cool feature, I echo that it be nice to see that functionality on some of the general blogging software as well.
One question -
If my client has the email alert feature turned on for comments, does he still get it immediately, is it delayed 15 minutes, or do they get the original comment and the edit?
04 May 2004 | Rob said...
That's pimp'n!
04 May 2004 | JF said...
If my client has the email alert feature turned on for comments, does he still get it immediately, is it delayed 15 minutes, or do they get the original comment and the edit?
Email notifications are instant so they'll get the original, but when they visit the URL at the bottom of the email notification they'll see the latest version of the comment. We don't send notifications on edits (cause who wants a bunch of extra emails with just a few small changes?).
04 May 2004 | pb said...
This is definitely the way browser comments should work.
04 May 2004 | pb said...
I mean "blog comments"!!
04 May 2004 | Bob Chao said...
Super!
05 May 2004 | vaughn said...
anyone wanna make a MT mod like this? :)
05 May 2004 | Andrew said...
Fascinating. "Time" is often totally ignored as a tool in UI design, and it's really a nifty solution here.
One thing though: if so many users were so quickly upset with the default "comments" behavior, perhaps it's because these are not comments. I'm not sure what they are instead, but it seems like this is an aspect of the blog-metaphor that doesn't quite fit the Project Management paradigm. I mean, if users are me-too-ing posts like most blog comments, that's one thing, but your example above of a client "approving" something is clearly very different.
05 May 2004 | pixelkitty said...
Maybe instead of "comments" use "Responses/Questions" ?
I agree with Andrew, they are not really comments. I'm asking my client to approve a change, or let them know how something works etc.
/start fanboy comment - I love BaseCamp - it has totally revolutionised the way I manage client projects - client's think I have a swanky office now, just because their project with me is in this funky online tool. Yay! /end fanboy comment
05 May 2004 | Bruno Figueiredo said...
I think there's something you didn't considered. What if after posting the person who posted the comment doesn't reload the page.
All they see is "there's 15 minutes for you to change this" but in effect, 20 minutes elapsed, and they're not able to change it anymore.
You can say: "hey, how come they didn't see the error sooner?". They could be attending the phone, get a coup of coffee, whatever...
So, if you implement this, I think that a live script would be best. One that doesn't rely on page reloads.
Or - and I don't know if this is a feature yet - after posting people should allways see a preview of what they're posting (and maybe this could be turned off for experienced users on preferences) and get the message clearly stating "this is your comment - carefully review it and press the Publish button. Don't worry about a possible mistake after this. You have 15 minutes to edit it back."
Something of this sort. What do you think of it?
05 May 2004 | Allen said...
I agree with Bruno that the "time remaining" indication isn't concurrent with real-time and might lead to possible mis-judgement for the poster.
Instead of a live script, isn't it simpler just to append an actual time indicating when the comment becomes uneditable? Eg. "Your comment will be uneditable after 9:00pm".
05 May 2004 | Ian said...
Allen, putting a time is not a good idea purely because you don't need the complications of keeping track of each users timezone.
Some alternatives:
Automatic Refresh: automatic refresh into the page to refresh every 5 minutes until the 15mins is up. But then theres the issue of if someone goes offline but wants to retain the page on the screen for viewing later... if it has the automatic refresh, the browser would display a 'Page can not be found' after going offline.
Change the Wording: instead of saying "for another x minutes", try "for 15 minutes since the initial posting, x minutes from last updating this page". Accuracy at the cost of obsucity.
Javascript Updates Text: have javascript that automatically updates the number every minute... counting down until its finished. IMO, probably the best option.
What Im interested in is how it handles:
1) Removing all content... does it delete the comment?
2) Pressing 'Save Changes' after the time is up?
05 May 2004 | Silus Grok said...
I have thoughts along the same lines as Bruno and Allen... and think Allen's suggestion is spot-on.
05 May 2004 | Allen said...
Ian, every comment posted are time-stamped. The images in the article shows a post from Jason Fried on 4th May at 8:45.
05 May 2004 | JF said...
Automatic Refresh: automatic refresh into the page to refresh every 5 minutes until the 15mins is up
And what happens if someone is in the middle of writing a new comment and the page reloads? Ah ha!
There are a lot of variables to consider when adding a seemingly simple feature like this. We considered a lot of different options, but we really feel like this is the best solution at this time. It's the simplest, doesn't require any fancy javascript (which causes other issues), didn't take long to implement (we have to prioritize our development time), is reasonable, and is easy to understand and explain. It's not the perfect solution, but it's the most realistic and reasonable solution given the wide variety of issues (internal and external) we have to deal with.
05 May 2004 | Mateo said...
I agree that Responses/Questions would be much more effective in making clients aware that they don't need to create a new post to answer questions in the first post. My clients do that all the time...
06 May 2004 | Ian said...
Whoops... sorry Alan, I missed that.
06 May 2004 | Conor said...
Pretty cool I should add this to my blog
07 May 2004 | Andreas said...
Pretty useless as I never maik ani mishtakes ;-)
08 May 2004 | pixelkitty said...
One other thing, on the Free Service, the ability to upload files is disabled.
You get a little prompt to upgrade to use the File Upload. While this is good, it would be better if the "Upload File" was not visible to clients and only to the project owner.
Is that something worth considering?
13 May 2004 | JF said...
While this is good, it would be better if the "Upload File" was not visible to clients and only to the project owner.
Clients shouldn't see the "Upload File" tab if your account doesn't support file uploading.
14 May 2004 | Homer said...
This guy darkblue has added a similar thing to his website. Seems to work reasonably well and it even shows the changes (rather neatly) when a comment has been edited.
21 May 2004 | martincohen said...
I'm now trying this new feature in my blog. Just to know if users will be able to use, and understand it. I'm very curious about that.
