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).
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.
>(1) Sally deletes an employee record
>(2) Bob deletes that employee's department
I would argue that a good design would actually prevent you from deleting important records like these. i.e. when Bob clicks delete, it just marks the object as deleted and it stops showing up in reports/interfaces. Then maybe you have something clean it up 90 days later or something.
Yes. This is pattern I've seen in both companies I worked for, and it makes so much sense.
Similairly you don't make table ARTICLES with column AMOUNT and KIND. You make table CHANGES with DIFFERENCE and KIND, and only ever add rows to that table (possibly with negative DIFFERENCE).
In the first case, you only know the AMOUNT. You can't undo transactions because you only have 1 object stored, the total amount. If you store DIFFERENCE, then you'll have a table of every transaction and can undo them individually. The cost is having to sum the table whenever you want to know the amount (which is usually worth the flexibility).
Regarding the performance - you can add triggers writing to additional table with a sum, or maintain that table in the code that adds rows, or calculate it each time you want to know the sum.
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.
Yes, it gets complex fast in collaborative setting. To my understanding, there are two robust approaches to collaborative editing:
- git-style 3-way-merge
- Google Wave -style operational transform
If somebody is experienced on the topic, I'd love to learn more about different approaches. Also, it would be awesome to have these as an open source DB projects (well, we have git) or even offered as IaaS.
(3a) No, because your data model never allows physical deletes.
(3b) And because you modeled up to 6NF with temporal keys, you've got the record from (1) and (2) and you know at what times they were related.
If Bob truly has the authority to decide that the entire department can be deleted from the database, and if the employee record really does have a dependency on the department, then the correct response is either:
a) Sally's interface has already updated to reflect the fact that the department has been deleted, so she doesn't even have the option to delete anymore
b)(where realtime updating of the interface isn't possible) - when Sally tries to modify the deleted record she is presented with a message stating that the action failed due to the department having been deleted by Bob. Sally can now either undo Bob's delete first (or ask Bob to do it), and then undo her own change.
User confirmation dialogues are a UI smell, in the same way that a module of code stuffed with if statements and flags is a code smell. It's telling you that your design has a fundamental flaw that needs to be fixed in a non-trivial way. Just t hink about the basic question - should red be "delete" or "no". Either way, the question implicitly recognises that this situation is confusing, and that Sally has a good chance of making a mistake. Knowing that her problem has arisen because she clicked on the wrong button ("when it was clearly coloured red!") is not going to make Sally like your software. Make it so that she can fix her error, not so that she doesn't make the error in the first place.
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?
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})
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.
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.
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.
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.
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?
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.
> 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.
The 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.
It 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).
Another 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.
There 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 =) )
"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."
A 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.)
First 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).
- 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.
No, 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.
All 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).
As suggested, I'd change "Delete it" to just "Delete", might seem minor, but it's less to read and the word "it" doesn't add any information the user didn't already have...
(2) Don't use many words when 1 will do.
"Cancel" "Delete"
(3) Don't use words when an icon will do.
(4) Don't use cognitively conflicting symbols and colors.
Red be cautious, green it's safe, but deleting something can be dangerous in either direction, safe in either direction. A better mental model is action vs inaction, then it's more clear to highlight the response that causes an action.
(5) Avoid blocking interfaces altogether.
Avoid interrupting the users flow. Perform all actions immediately, but only ever offer recoverable actions. Undo is not the only choice, and probably not the best for things like entire documents. Like loading a file, delete is often not meaningful in the undo stack (though it can be). Another paradigm is moving an item to a differentiated group, such as trash, an undisplayed group or a low rating. This approach is idempotent and allow things to be recovered out of order (it's also easer to implement than undo especially asynchronously). It can also be it's own valuable feature like edit tracking for word processors.
Colours are fine.. Either way works although for my sensibilities the red works for the Delete button. I am red/green colourblind and the two have distinct enough values that I can easily tell them apart.
But I think YES and NO shouldn't be there. It's an extra piece of information that demands the original context of "Do you want to delete this album". It might seem like a small mental investment to ask of your users but people have varying degrees of comprehension at different times, whether due to temporary distraction or because of more permanent conditions such as dyslexia and such.
Instead I would just say "You are about to delete this album" And have the buttons read "Cancel" and "Delete"... Or something similar.
Undo would also be preferred as comex mentioned.. Or even better a git-like revision history so you can undo any action in the past. This comes with other technical challenges I'm sure but it's the most powerful solution.
It is sad nobody mentions book The Humane Interface by Jeff Raskin.
Raskin would say, that this is not a question of red or green. It is a question of habit. If user deletes enough items, you will train him to press "Yes" button and not to think about the question. It will be his habit. Uninterruptible sequence.
Anybody deleted his important files just because he is "trained" to press sequence F8 - Enter in his favourite file manager?
Raskin recommends to provide undo. User content is sacred and should not be lost. You can also try to randomize the dialog. User will stop the sequence and think what he is doing. But if user performs the delete operation often, he will be greatly annoyed.
"Cancel"/"No" should be on the left (go back) and "OK"/"Yes" on the right (proceed).
(There may be guidelines that do the opposite and I guess RTL locales may reverse it).
Deliberately ignoring HMI guidelines and switching button placement is irritating and does not remove the muscle-memory (?) problem. Doing it randomly is nuts and leads to mistakes that are IMO not the users fault.
It you want to interrupt a sequence, there are kinder ways of doing it like double confirmation.
That's really the MacOS vs MSWindows disagreement, and then the "whom should we emulate?" disagreement among Linux desktop people. Oh, and the OpenWindows and CDE people before them.
I'm biased, but I think of this as another one of those "well, Microsoft got it wrong, but people are so used to it now that we have to perpetuate it or we look like we're just willfully antagonistic" situations.
User studies can be produced to prove either side, of course.
I would prefer solid blue for a confirming step, and a blue border with no fill for a cancel button. The contrast of fill vs no fill for the button highlights better than two colours.
Just a note that X percent of the population is colorblind. I'm not, but I have a couple of colleagues who are, and I've made graphics that are unreadable for them.
For most operations, "delete" should be reversible, so there are no consequences for clicking delete. If you really get the UI right, you shouldn't need confirmation. (Gmail's message like "this post has been archived <unarchive>" after you archive a message seems about right to me. It implies something like "you did something destructive, and we can cancel it right now. or you can undo it manually later." Much better than confirm/cancel dialogs.)
For things like "yes, I'm afraid of the NSA, wipe those tapes forever", that's another issue. In that case, you want a "flow" rather than a button, I think.
I think "Yes" should be "green". The question is clear... green reminds me of the traffic ligths, green means "go on" or "go ahead".
Maybe "yes" and "delete" shouldn't be in the same button because it seems that "yes" has a positive meaning (green) and "delete" a negative/alert meaning (red), that is why (maybe)you got this paradox... Hope that was helpful.
Green denotes a good, positive action. Red denotes a warning, negative message.
That being said, I would have a tendency to put [yes delete] as green. If this was a "delete forever and destroy the world" button, then [yes delete] should be red.
It is up to you based on how permanent this delete is. As has been noted, Gmail style with undo is best.
Red is still the color of emergency, alert, STOP, etc..in China. We are at orange alert on pollution right now, if it gets any worse, we will be on a red alert.
Now if we are going to talk about the meaning of check marks and crosses in the Japanese market....
I'm of Asian descent and cannot confirm. They still use red stop signs and traffic lights. Red is also the color of blood - similarly, there's a fair amount of literature supporting the evolutionary emergence of red as a signal of danger.
> Recent research has shown that the color red influences psychological functioning. Red is hypothesized to be linked to aggression and danger in evolution, and these links are enhanced by culture-specific uses of red. Thus, color meanings are thought to be grounded in biologically based proclivities and learned associations. However, to date, there has been no direct evidence for the influence of experience on the red effect. This study focused on whether experience could change the psychological effects of the color red. In the context of the Chinese stock market, contrary to the meaning generally associated with red as negative and green as positive, red represents a rise in stock price and green stands for a decrease. An experiment using a 2×2 between subjects factorial design demonstrated that red (compared with green) impaired Chinese college students’ performance on an IQ test (in accordance with the red effect), but the opposite effect was found among stockbrokers. These results provide direct evidence of learned color meanings, in support of the general model of color effect. ...
which suggests that red has a non-trivial learned color meaning on people, and leaving open the possibility that it's mostly, if not all, culturally based.
> in a series of 7 experiments we demonstrate that women perceive men to be more attractive and sexually desirable when seen on a red background and in red clothing, and we additionally show that status perceptions are responsible for this red effect.
They hypothesize that red is not a general signal of danger, but has many meanings. NOTE! http://www.ncbi.nlm.nih.gov/pubmed/23398185 points out that there's likely publication bias in this experiment, so there might be no signal. I bring up the study anyway to point out that many people have different interpretations for the "evolutionary emergence", and the evidence is low.
> Claims of universality pervade color preference research. It has been argued that there are universal preferences for some colors over others (e.g., Eysenck, 1941), universal sex differences (e.g., Hurlbert & Ling, 2007), and universal mechanisms or dimensions that govern these preferences (e.g., Palmer & Schloss, 2010). However, there have been surprisingly few cross-cultural investigations of color preference and none from nonindustrialized societies that are relatively free from the common influence of global consumer culture. Here, we compare the color preferences of British adults to those of Himba adults who belong to a nonindustrialized culture in rural Namibia. British and Himba color preferences are found to share few characteristics, and Himba color preferences display none of the so-called "universal" patterns or sex differences.
Since you say that there is a "fair amount of literature" on this topic, can you point it out? I've not been able to find anything rigorous which supports your statement. Certainly nothing which is stronger than that last citation.
Whilst it is true that colors are seen differently in various cultures, the universality of red as the color of stop signs makes it a sensible choice for a color that is intended to make someone consider the consequences of an action.
Not the OP, but there is a fair bit of literature which could be construed to support their point. Indeed, 2 out of the 3 references you cite could support their point.
1) Note that the general Chinese student performed worse when red was used - despite the generally positive Chinese cultural values put on red. The fact that training could overcome this does not invalidate that point. Indeed, the learnt value of red indicates that it may be sensible to use it in UI, simply because it is fairly standard.
2) Studies have shown that many women find dangerous men more attractive[1]. Perhaps this supports the idea that red represents danger?
3) Without access to the full study there is no way of determining exactly what this says.
The wikipedia link is strong support for the idea that stop signs are universally red. Every pictured sign, from Argentina to Zimbabwe, is at the very least framed in red, and most are considerably redder than that. The text notes "The white legend/red field appearance is usually the same [from country to country]".
The imgur link shows an unexplained green sign. Any thoughts as to why it's green?
Not clear why that instance is green. I think I've seen arrive photos of green stop signs too. The point of my post wasn't too be flippant though: the GP was talking about stop signs being universally red, and that being basis for red labels/buttons. It only takes one example to disprove universality, I showed multiple.
To point of labeling and actions though:
1) I'm proponent of button labels being verbs ("Delete" vs "Yes")
2) Undo-able where possible
Actually, the post you responded to specifically argued that the universality (= every country, not necessarily every sign) of red stop signs makes red a good color for warning dialogs. That argument doesn't require that all stop signs be red everywhere, it requires that red stop signs be typical everywhere, which they are. The only non-red stop signs described by wikipedia are several decades old.
As to the topic, I agree that the "yes" doesn't belong on the buttons, and have no particular opinion on undo vs no-undo.
A guess would be that there are strict rules and regulations about placement of official road signs even on private property. These signs are probably unofficial signs placed by property owners to regulate traffic on their property and thus legally have to look different from the signs placed by the local department of transport (or whoever is responsible)
Nevertheless even going back as far as 1931, the Geneva convention "CONVENTION CONCERNING THE UNIFICATION OF ROAD SIGNALS" says:
Signs Prohibiting Passage: For these signs, the colour red must clearly predominate and must be used so as to bring into relief the general contour of the sign. The other colours to be used are optional except in the following cases[1]
I still say stop signs are universally expected to be red. Some singular counter-examples don't disprove that - they just show there are some weird things that happen.
I'd also note that linked example was posted from Reddit (in a joke sub-reddit) and it is entirely possible it was photoshopped. Other examples of green stop signs found by Google seems to be almost all photoshopped or on private property.
The OP suggested that the universality of red in this fashion was evolutionary in basis. Stop signs as an example of universality. But stop signs are closely coupled to a specific, near-universal machine culture.
The presence of early non-red stop signs suggests that "red = stop" is a learned association. Indeed, as the Wikipedia article states, the early standardizations used a yellow background instead of red. I conjecture that it was originally yellow for visibility reason, then turned red for better contrast with yellow used for caution signs. A full analysis would need to dig into the reasoning for this decision.
A more complete analysis would need to look into how color was used in the 1800s, before driving culture appeared. For example, was red the predominate color of danger in steam engines? (Note also that in Swedish and Finnish cultures, Falu red/punamulta is associated with an idyllic country-side life. These houses are not considered "dangerous" despite being red.)
The first and third literature references I gave are not in opposition to the idea that red has a (near) universal meaning. They instead cast doubt on the conjecture that the associations are evolutionary. The first suggests that even the observed psychological effects might be culturally learned, and the third suggests that we have a rather wide-spread global culture, making it hard to determine what is cultural and what is evolutionary.
Stop signs are also nearly universally octagon in shape. I very much doubt there's any sort of evolutionary reason for this choice.
My challenge was for the OP to defend the statement that the choice of red = blood = danger = stop is based on evolutionary reasons, with scientific research to back it up. The paper I quoted show that there's very little research which can distinguish between a shared culture (and yes, China and the US have a shared culture) and evolutionary universalism.
One need only read http://en.wikipedia.org/wiki/Linguistic_relativity_and_the_c... to see that even the basic color terms across cultures, and the evolution of color terms, is still being debated. It would be hard to ask someone "is red a dangerous color" if that someone doesn't distinguish between red and yellow.
Although I prefer the method in the best chosen answer, if I had to choose between red and green, I would choose green. You are confirming an action when choosing yes. The button to cancel the operation should be red.
You are also being warned about something, and warnings are red. The "warning" aspect should trump the "confirmation" aspect, and imo it's not even a close decision.
But what I did find interesting was this comment getting so many votes -
117 "Neither, if you're red-green color blind like 10% of men. – Roddy of the Frozen Peas Jan 12 at 5:31"
With a obvious reply, but less votes -
53 "@RoddyoftheFrozenPeas (1) while some degrees of color blindness are quite common, thinking that 10% of men are red/green color blind is totally insane, (2) solely using a color to point out something is bad for color blinds, but if the color is something "extra" on top of the main information, then it's perfectly fine. I'm quite surprised and worried that your horribly wrong comment managed to raise 4 votes... – Lohoris Jan 12"
It's amazing people really can't think for themselves and just meaninglessly up-vote because it seems the right thing to do, as compared to what the logical thing to do is.
Nearly 10% of men are colorblind, though not all red/green. It is by far the most common type though, and I'm red/green colorblind. A common misconception is that reds and greens are indistinguishable to people like me. That's not really the case.
Most reds look red and most greens look green. It's just that some particular shades of each are ambiguous. For me, the reds and greens produced by displays tend to be tougher to distinguish than natural hues, but the shades in the Stack Exchange question are as different as can be. It's tough to explain. It's also so subtle that many people with my particular type of colorblindness live and die without ever knowing the difference.
I only learned I was colorblind after being explicitly tested for it in 6th grade. I was pretty surprised! Though it did explain how I always seemed to mess up school assignments that involved coloring maps.
