Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 4 down vote favorite

I'm making a ticket system, and on each ticket users and employees can add replies. I'm just wondering, would it be a good idea to allow users to edit replies?

A lot of web apps/websites allow users to edit posts/replies but I don't know if it would be good to allow them to edit on this type of system.

What do you think would be best?

share|improve this question

5 Answers

up vote 9 down vote accepted

You could do it the "Basecamp way" by allowing editing within a time window (5 mins), in case they make a typo, then lock it down.

share|improve this answer
See also: this very site, and all other Stack Exchange powered sites. – peteorpeter Mar 29 '12 at 14:12
@peteorpeter, this site uses two different schemes, both of which are interesting. Comments can be edited within a small time window (and leave no history); posts can be edited at any time and leave a trail. – Monica Cellio Mar 29 '12 at 14:49
@Monica Cellio Right on - I was thinking of the comment system, but the same applies to Q&A. (And since more editing is allowed in Q&A, more problems occur there with the conversations being out of synch.) – peteorpeter Mar 29 '12 at 15:02
This is a good idea. I will consider the time window of 5 mins of editing like SE comments. – Nathan Mar 29 '12 at 23:56
Yeah, I will do it this way and it will show the date & time it was edited and if it was edited more than once within that time window, it will say how many times as well. I don't feel like creating another table and adding all edits to it to save all edits though :) I don't even know how SE does it (the comparison thing how it shows which parts were taken out or put in) but it's very neat. – Nathan Mar 30 '12 at 1:42
up vote 1 down vote

I think StackExchange is one of the few formats where it makes sense to allow edits, as it's not an ongoing conversation as it is a archived answer to a specific question.

But in any type of system where replies create linear conversations, it makes little-to-no sense to allow people to come back and edit responses.

share|improve this answer
(StackExchange -> Stack Exchange (stackoverflow.com/legal/trademark-guidance). "on going" -> "ongoing") – Peter Mortensen Mar 29 '12 at 9:42
1  
The logo says StackExchange. Therefore, that's what I call it since I am not a lawyer and this answer isn't a legal document. ;) – DA01 Mar 29 '12 at 15:05
I don't think I can convince you, but in general, what is on a logo has nothing to do with how it should be spelled (for instance, it is Twitter and Facebook, not twitter and facebook). The reference I provided is not so much a legal statement as a definition of how it should be (it could have been stated in another context). In any case, consider my second suggestion, ref. en.wiktionary.org/wiki/ongoing#Adjective – Peter Mortensen Mar 29 '12 at 18:48
1  
OK, OK. Fine. Ongoing fixed. Next time, though, feel free to click the EDIT link. I won't mind. – DA01 Mar 29 '12 at 19:27
1  
Anyways, thanks for the answer. I'm not too worried about grammar in your answer, as this is not English class :) – Nathan Mar 30 '12 at 0:44
show 1 more comment
up vote 2 down vote

What is the purpose of records in the ticket system? I can think of two:

  1. To provide a complete history of what happened all in one place.

  2. To provide a clean record of the problem and solution, e.g. your ticket system is also your knowledge base.

Deciding which of these goals is more important should inform your approach to editing.

If you support editing you should do it in a way that doesn't lose data that you would want for auditing. Whether you make the revision history available to your users, or only to admins of some sort, depends on how your users use the system: should they simply operate on the current state without regard to what happened along the way (think 911 dispatch), or should they have access to all the history to provide a better solution (think software-bug-tracking system)?

share|improve this answer
up vote 5 down vote

No, for the simple reason that it would be hard for anyone who is joining the conversation late to know if a reply was edited (you could store the edit time stamp like how Stack Exchange does it), but he might not know what was added or deleted. Keeping a steady flow of conversation with updates and responses will help the user understand the flow of the ticket from it being created to what are the steps taken to resolve it.

share|improve this answer
On SE you can see what was changed by clicking on the edit timestamp, BTW. – Monica Cellio Mar 29 '12 at 14:50
1  
LiveJournal (a blogging site) allows a comment to be edited until somebody replies to it, at which point it is locked down to prevent conversational confusion. That's an interesting model that I don't think I've seen elsewhere. – Monica Cellio Mar 29 '12 at 14:51
@Monica,Nice note about SE,I didnt know about this till now and I like the second model you suggested – Mervin Mar 29 '12 at 20:38
That's true. I might do what @aaron suggested above, which is allowing editing for only 5 mins and then lock it down. – Nathan Mar 29 '12 at 23:57
@MonicaCellio Only problem with that is that in my system you don't reply to replies, but you reply to tickets and they are all put under the ticket. I mean, I could use an if statement and determine if there are newer replies than it and then lock it down once there's another reply after it, but I'm just gonna do the 5 minute time window. That's a good idea though. – Nathan Mar 30 '12 at 1:47
show 1 more comment
up vote 1 down vote

In your situation, no, I don't think allowing reply edits is a good thing. One of the purposes of a ticket system is for creating an audit trail; what the issue was, what work was done, what the resolution was. If you allow replies to be edited you introduce the possibility that this audit trail can be forged, possibly when users want to cover-up mistakes they made.

Take this instance:

  1. User raises a ticket saying their password isnt working.

  2. Support fix it by clearing out the password table so user can submit a new one.

  3. Support leaves a reply on the log detailing this action.

  4. The action the support person took accidentally wiped all users passwords.

  5. Support person goes back to the ticket log and edits the last reply to remove reference to clearing the passwords so they don't get blamed for all users losing their login details.

While the users probably appreciate being able to cover up their mistakes I'm not sure the business would.

share|improve this answer
This is very true. I don't think the business would like it because some employee could actually end up doing that. (I don't know why the business would allow the employee into the actual DB though, when they could just make a web based user management system for employees (which wouldn't be too hard). Thanks for the answer. – Nathan Mar 30 '12 at 0:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.