6 ms·
Neither. Wherever possible, design your code to use undo rather than confirmation, Gmail-style. Saves the user time and avoids training them to click through
by comex 13y ago
Neither. Wherever possible, design your code to use undo rather than confirmation, Gmail-style. Saves the user time and avoids training them to click through confirmations (and perhaps eventually be sorry).
- tsudot 13y ago> design your code to use undo rather than confirmation I can think of two ways to implement undo. 1. Use flags in the database, this method has its own drawback since the entry is not really deleted but flagged as one. 2. Client side. Delay the actual delete request to the server.
- a_bonobo 13y agoCould you just delay the COMMIT for a few minutes/seconds/until the user navigates away? And if the user clicks UNDO, do a ROLLBACK? Edit: Of course, if anything goes wrong before the COMMIT, you loose the transaction.
- TylerE 13y agoThat's not really feasible in a real world environment where database connections are frequently re-used and user requests are very short lived. Database transaction are like try/except blocks - designed to clean up unexpected situations instantly, not as a state mechanism.
- a_bonobo 13y agoThank you for the answer and explanation!
- darylteo 13y agoThere actually is another way. Event-Sourcing. I've never seen this technique in my limited experience though, but theoretically this would be the optimal way to implement such a feature, and obviously has to be a engineering decision from the get-go. Alternatively you could also have a very primitive form of version control : recycle-bin (edit: actually this is the same as point 1 =) )
- jonahx 13y agoHow would the Event-Sourcing method work?
- darylteo 13y agoFirst you start treating each event/operation as a fundamental part of your problem. Each Event can then have a opposite reverting Event. So if you want to reverse an action, you can just apply the opposite event. You can also display a list of recent events that have taken place easily: - user X modified article Z - user Y deleted article Z (revert?) Note that I've only studied this in passing, and have never applied this in practice, so I can't answer just how effective this could be. Also not really sure how this works when other actions have already taken place, or how you can detect if an event cannot be recovered from (if there is such a thing).
- lomnakkus 13y agoA useful analogy might be how accounting ledgers work. You never really delete anything; you just keep appending records saying what you've done. The balance is just the sum of all those operations. (Ledgers are a bit special in that usually all the operations in a ledger are commutative (+/-), but other than that it seems a pretty good analogy.)
- nl 13y agoSee also Operational Transform[1]. There be dragons, though. [1] http://en.wikipedia.org/wiki/Operational_transformation http://en.wikipedia.org/wiki/Operational_transformation
- darylteo 13y agoI liked this part: "Similarly, Joseph Gentle who is an ex Google Wave engineer and an author of the Share.JS library wrote: Unfortunately, implementing OT sucks. There's a million algorithms with different tradeoffs, mostly trapped in academic papers. The algorithms are really hard and time consuming to implement correctly. ... Wave took 2 years to write and if we rewrote it today, it would take almost as long to write a second time."
- tiziano88 13y agoI think no one would implement it client side in practice; if the user clicks delete and immediately closes the browser, what happens to the action?
- dkuntz2 13y agoDo what Gmail does and say "actions are still pending" as confirm box...
- MichaelApproved 13y agoThe delete flag in the DB could be null or the date the delete was requested. You could batch the commit cleanup hourly giving a delete at least X hours before it's committed.
- noblethrasher 13y agoIt depends on how you interpret “delete”. Most people seem to want to make it synonymous with “erase”, but it should really mean something like “forget”. In that case, it’s easy to see how you would implement “undo”: just drop all (root) references to the record(s) in question and collect as garbage at a certain time (in, say, 30 days).
- jowiar 13y agoOne standard "undo" mechanism is to store a stack of actions (per user), with each action having a method to undo itself.
- kyllo 13y agoAnother standard way is with the command pattern, and using one "undo" stack, with another "redo stack". When you perform a command, a command object is pushed onto the "undo" stack. When you undo a command, it's popped off the stack, its undo() method is called, and it's pushed onto the "redo" stack. When you redo a command, it's popped off the redo stack, and executed. When you execute a new command (not an undo or redo) you push it onto the undo stack and clear out the redo stack. See this SO question for further detail and links: http://stackoverflow.com/questions/701131/data-structure-used-to-implement-undo-and-redo-option http://stackoverflow.com/questions/701131/data-structure-use...
- deleted 13y ago[deleted]
- qq66 13y agoMaking 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 agoHow many situations does the small startup have where they're going to be destroying something?
- deleted 13y ago[deleted]
- diminoten 13y agoWhen 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 agoCRU
- raldi 13y agoI 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 agoThat'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
- enscr 13y agoI've found Undo prone to failure. E.g. - In Android's gmail, sometimes undo does not recover the message (probably a bug) - When I'm swiping pictures in Android and accidentally delete a picture and by the time I realize, the momentum of my action has already dismissed undo. - Gmail undo : disappears after a time span. What if I delete & suddenly get distracted by something. By the time I return, I've to dig through trash to recover my action.
- mantrax3 13y agoDoesn't help if you click somewhere by accident and delete an email without noticing.
- MarkTee 13y agoAll you need to do is ensure that the undo option is highly visible (just like Gmail's; I've never caused irrevocable damage while using their web client).
- pbreit 13y agoNo, that's confusing, even to intermediate users. A dialog box is fine with the "Delete" action more pronounced. Another nice touch might be keeping around a "trash" that can be recovered from. No need to get too clever.