5 ms·

Making an action undoable often more than doubles the development cost of that feature. Google can do it, for a small startup it only makes sense in a few situa

by qq66 13y ago

Making an action undoable often more than doubles the development cost of that feature. Google can do it, for a small startup it only makes sense in a few situations.

raldi 13y ago
How many situations does the small startup have where they're going to be destroying something?
- deleted 13y ago
  [deleted]
- diminoten 13y ago
  When your startup allows users to create categories or unit groupings, maybe? Removing credit cards, as well. I dunno, do you really think it's rare for startups to be deleting data?
  - brandoncapecci 13y ago
    CRU
  - raldi 13y ago
    I think they delete data all the time. But I think there are just a small number of situations where it happens. For example, someone on HN probably deletes a comment every few seconds. The site is therefore deleting data constantly. But all that only counts as one single situation. Is there any other situation where an HN non-admin ever deletes data?
    - diminoten 13y ago
      That's a good point; I don't think I can delete my submissions or my account on here, but even then 3 total use cases revolving around delete isn't exactly a huge number.
MarkMc 13y ago
It is particularly difficult in a collaborative application with 'hard' links between records. For example, consider this scenario: (1) Sally deletes an employee record (2) Bob deletes that employee's department (3) Sally tries to undo the deletion of the employee - will the employee be restored without a department?
- rangibaby 13y ago
  Intuitively, I would expect it to restore both the department and employee, or throw it into a "Bob and Sally: Please fix this conflict" kind of box.
  - NovaS1X 13y ago
    I'd expect it to depend on the permissions of the user restoring or deleting the groups. Under complete presumption: Bob is an HR member while Sally is a Manager. Why? The ability to manage entire groups should be left to people higher up in the administration chain where individual users should be delegated to HR or other staff. Bob should have permissions to manage users but not groups. Sally should have permissions to manage both. If Bob deletes a user, then Sally deletes the group, there should be no reason that Bob should be able to anything outside his domain. The group should not be restored and Bob should be given a clear, 'plain English' reason why he can't do such an action. If both Sally and Bob are managers of a group and said situation occurs, no group should be restored when Bob restores a user. Only a readable error message should occur. In fact no data to be restored should be there in the first place unless it has been backed up or cached. What is a possible solution to this logic? 1.) You could implement an optional backup system. All deletes are final in the context of the action. Think of a common tree structure: if no main branch is there to support a twig then no twig can hang. No restores via users can be performed until the group has been restored. The deleted data could be stored in a cache until certain parameters are met; once these are met the data is deleted (IE: Recycle Bin) 2.) Users could be restored belonging to a default group. If a recently deleted member of a recently deleted group needs to be restored, they could be assigned to a default 'holding' group or other similar group with restricted permissions. This retains all specific user data which is not lost and by default the user will not be given extraneous or extra permissions. They can then be assigned to an appropriate group. 3.) Removing a group does not affect users within it. This is the opposite of a tree structure. This is analogous to Linux group and user permissions. A group can be assigned to users so they can access a resource. They are not interconnected in any way other than their usage to control permissions. Users can be removed and restored at will and so can groups. No conflicts of hierarchy are incurred. In summary, restoring an individual resource should never restore the controlling body without given consent. This would create a lot of problems if it did.
mbesto 13y ago
I 100% agree `Undo` is the best way to go about this. Equally, I'm very curious to hear how others have implemented this in their app. The complexity for such a small feature is actually quite high, because we start playing with the database (and therefore, in many cases a robust ORM) Anyone have experience with doing something like this in Rails?
- ericingram 13y ago
  We solve it using an "archive" collection in mongodb. Deleting moves a document from one collection to the archive, while undo moves it back. We also implement ability to find deleted documents by id, by searching the archive if the record is not found in the original collection. API looks like this: // delete something delete("/products/123") // see it in the archive get("/archive/products/123") // undelete it put("/products/123", {$restore: true})
- ForHackernews 13y ago
  One simple implementation is just to queue up the action without committing it, then "undo" actually just cancels a pending action. The downside of this approach is "undo" becomes a limited time only offer.
- runner84111 13y ago
  Actual deletion occurs on app close (or next open). The "delete" the user sees just hides the data.
- weavie 13y ago
  I just stick an isDeleted column on my tables. It does mean I have to remember to do a `where !isDeleted` on all my main queries, but apart from that the cost of undoing is incredibly cheap.
new_guy123 13y ago
It doesn't - the undo action is not a permanent option since it is only a replacement for a yes/no prompt. The implementation then could be a delayed action. Might not work for all use cases, but good enough for most, especially in a start up situation.
troym 13y ago
> Making an action undoable often more than doubles the development cost of that feature. Every time I've added the feature, it's bordered on trivial (start a timer to execute the actual delete request, show a link to cancel the request, hide the DOM element). I suppose if you were doing all the work server-side, then yah, it would be difficult. But the way GOOG does it (IIRC) it's not that hard at all.
- dsego 13y ago
  That is cancellation then, not undo.
grn 13y ago
But you can still mark the buttons with colors so your users will make less mistakes. I think that the two issues are orthogonal.
SixSigma 13y ago
Saving dev costs by making your users pay with their data loss is extraordinarily short sighted. If you cant code with an undo feature, perhaps this is not the discipline for you.

by qq66 13y ago

Making an action undoable often more than doubles the development cost of that feature. Google can do it, for a small startup it only makes sense in a few situations.

raldi 13y ago

How many situations does the small startup have where they're going to be destroying something?

deleted 13y ago
[deleted]
diminoten 13y ago
When your startup allows users to create categories or unit groupings, maybe? Removing credit cards, as well. I dunno, do you really think it's rare for startups to be deleting data?
- brandoncapecci 13y ago
  CRU
- raldi 13y ago
  I think they delete data all the time. But I think there are just a small number of situations where it happens. For example, someone on HN probably deletes a comment every few seconds. The site is therefore deleting data constantly. But all that only counts as one single situation. Is there any other situation where an HN non-admin ever deletes data?
  - diminoten 13y ago
    That's a good point; I don't think I can delete my submissions or my account on here, but even then 3 total use cases revolving around delete isn't exactly a huge number.

MarkMc 13y ago

It is particularly difficult in a collaborative application with 'hard' links between records. For example, consider this scenario: (1) Sally deletes an employee record (2) Bob deletes that employee's department (3) Sally tries to undo the deletion of the employee - will the employee be restored without a department?

rangibaby 13y ago
Intuitively, I would expect it to restore both the department and employee, or throw it into a "Bob and Sally: Please fix this conflict" kind of box.
- NovaS1X 13y ago
  I'd expect it to depend on the permissions of the user restoring or deleting the groups. Under complete presumption: Bob is an HR member while Sally is a Manager. Why? The ability to manage entire groups should be left to people higher up in the administration chain where individual users should be delegated to HR or other staff. Bob should have permissions to manage users but not groups. Sally should have permissions to manage both. If Bob deletes a user, then Sally deletes the group, there should be no reason that Bob should be able to anything outside his domain. The group should not be restored and Bob should be given a clear, 'plain English' reason why he can't do such an action. If both Sally and Bob are managers of a group and said situation occurs, no group should be restored when Bob restores a user. Only a readable error message should occur. In fact no data to be restored should be there in the first place unless it has been backed up or cached. What is a possible solution to this logic? 1.) You could implement an optional backup system. All deletes are final in the context of the action. Think of a common tree structure: if no main branch is there to support a twig then no twig can hang. No restores via users can be performed until the group has been restored. The deleted data could be stored in a cache until certain parameters are met; once these are met the data is deleted (IE: Recycle Bin) 2.) Users could be restored belonging to a default group. If a recently deleted member of a recently deleted group needs to be restored, they could be assigned to a default 'holding' group or other similar group with restricted permissions. This retains all specific user data which is not lost and by default the user will not be given extraneous or extra permissions. They can then be assigned to an appropriate group. 3.) Removing a group does not affect users within it. This is the opposite of a tree structure. This is analogous to Linux group and user permissions. A group can be assigned to users so they can access a resource. They are not interconnected in any way other than their usage to control permissions. Users can be removed and restored at will and so can groups. No conflicts of hierarchy are incurred. In summary, restoring an individual resource should never restore the controlling body without given consent. This would create a lot of problems if it did.

mbesto 13y ago

I 100% agree `Undo` is the best way to go about this. Equally, I'm very curious to hear how others have implemented this in their app. The complexity for such a small feature is actually quite high, because we start playing with the database (and therefore, in many cases a robust ORM) Anyone have experience with doing something like this in Rails?

ericingram 13y ago
We solve it using an "archive" collection in mongodb. Deleting moves a document from one collection to the archive, while undo moves it back. We also implement ability to find deleted documents by id, by searching the archive if the record is not found in the original collection. API looks like this: // delete something delete("/products/123") // see it in the archive get("/archive/products/123") // undelete it put("/products/123", {$restore: true})
ForHackernews 13y ago
One simple implementation is just to queue up the action without committing it, then "undo" actually just cancels a pending action. The downside of this approach is "undo" becomes a limited time only offer.
runner84111 13y ago
Actual deletion occurs on app close (or next open). The "delete" the user sees just hides the data.
weavie 13y ago
I just stick an isDeleted column on my tables. It does mean I have to remember to do a `where !isDeleted` on all my main queries, but apart from that the cost of undoing is incredibly cheap.

new_guy123 13y ago

It doesn't - the undo action is not a permanent option since it is only a replacement for a yes/no prompt. The implementation then could be a delayed action. Might not work for all use cases, but good enough for most, especially in a start up situation.

troym 13y ago

> Making an action undoable often more than doubles the development cost of that feature. Every time I've added the feature, it's bordered on trivial (start a timer to execute the actual delete request, show a link to cancel the request, hide the DOM element). I suppose if you were doing all the work server-side, then yah, it would be difficult. But the way GOOG does it (IIRC) it's not that hard at all.

dsego 13y ago
That is cancellation then, not undo.

grn 13y ago

But you can still mark the buttons with colors so your users will make less mistakes. I think that the two issues are orthogonal.

SixSigma 13y ago

Saving dev costs by making your users pay with their data loss is extraordinarily short sighted. If you cant code with an undo feature, perhaps this is not the discipline for you.