User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 Steps to reproduce: Pressed delete and confirmed dialog box. Didn't realise that whole address book was selected rather than individual card. Actual results: Deleted address book with no means of recovery. I know this has been discussed elsewhere and it is better than it used to be. Expected results: Confirm deletion dialogs are too similar. When deleting many contacts in a series you get used to clicking the confirm dialog without reading it. Consider: - 2 dialogs in series to delete an address book, with strong warning in both dialogs - a different way of initiating the delete address book, e.g. under tools menu

I agree with reporter that we have some serious UX problems in this corner. It's possible or even default behaviour that when you change between address books, first contact of that book will be displayed. So it's easy for users to think that this contact has focus, while focus is actually still on AB. Then they press DEL, intending to delete the contact, but in fact deleting the entire AB (albeit with confirmation, but it's easy to get used to that). So indeed this looks like a case of ux-error-prevention. Given that deleting entire AB's probably isn't a very frequent action for most users, I think as an exception we could get away with not allowing simple DEL to delete address book. So most users can use context menu's delete command. But what about keyboard users (accessability)? Robin, if we only allowed Shift+DEL for deleting selected & focused AB, would that help to avoid your scenario? Even ALT+DEL if Shift+DEL still has too much muscle memory from deleting files in file managers. Shortcut will be advertised in menus for those who need it, otherwise it's easy to delete from context menu.

Fwiw, I think after selecting another AB, no contact should be pre-selected, so preview should stay blank, which would also help somewhat to avoid the problem of this bug. Do we have a bug for that?

Seems reasonable to have a shortcut for those wanting to delete multiple address books, if that's a user requirement. Otherwise the menu option would suffice, context or other. Certainly a context menu would help to ensure the user knew where the focus was.

As the screen shot shows, these dialogs are similar but far from identical. I don't see us changing to non-standard key combinations to workaround what is ultimately use error. If one dares to be deleting content at high speed or on auto-pilot, then one must be prepared to encounter the occasional "OOPS that was stupid of me." That said, there may be ways to improve. - change the default choice in the dialog to be "cancel", not "OK" - ultimate solution is undo capability for address book deletion. I don't know about version 24, but current trunk (with my addons enabled) contact preview space is empty after changing address books. What do you see when you use version 31 (beta) from http://www.mozilla.org/en-US/thunderbird/channel/ ?

I think the screenshot actually says it all. If you are rapidly going through deleting contacts it would be easy to miss the subtle differences. I recently reset an Android phone to factory settings. There were something like 10 "No" options and 1 "Yes" option. Clearly the Android people are thinking about the UI and not letting users make the wrong choice by mistake. This is not atypical. I would expect any non-reversible action to have clear and differentiated warnings.

delete address book is now worded as "Are you sure you want to delete this address book and all of its contacts?" - this improvement comes from bug 1319493 The classic solution to issues like this is to provide UNDO via bug 94407

(In reply to Wayne Mery (:wsmwk) from comment #4) Hi Wayne, I'd agree that my new wording which includes the name of the selected AB about to be deleted will make it harder to err here, but only IF one actually takes that second to read the dialog. > Created attachment 8450419 [details] > bug956433.png > > As the screen shot shows, these dialogs are similar but far from identical. > > I don't see us changing to non-standard key combinations to workaround what > is ultimately use error. If one dares to be deleting content at high speed > or on auto-pilot, then one must be prepared to encounter the occasional > "OOPS that was stupid of me." That said, there may be ways to improve. > > - change the default choice in the dialog to be "cancel", not "OK" That would be an option worth exploring, but only for AB's, not for contacts. But if we had UNDO, it wouldn't be required. Then we'd break people's habits again if we take the default back to OK. > - ultimate solution is undo capability for address book deletion. I hope we'll consider data protection because UNDO certainly must be limited to a certain time frame, otherwise it will be seriously compromising data security as people will think the data is gone, but in reality it can all be undone. Maybe we could let the user configure the retention policy for UNDO, but the default should probably be even just showing an information bar and allowing undo for the next 60 minutes or so, or even less. > I don't know about version 24, but current trunk (with my addons enabled) > contact preview space is empty after changing address books. What do you > see when you use version 31 (beta) from > http://www.mozilla.org/en-US/thunderbird/channel/ ? I think "empty preview" is an excellent way of preventing the very scenario of comment 0. We do empty the preview when *changing* AB's, but we do *not* empty the preview when user was showing one contact and is now moving focus to the AB. So focus is on AB, but contact is still shown, and card even looks selected (albeit selection is now grey). That's what provokes the error of comment 0. There would be less reason to click DEL with an intention of deleting the card if the card is not even shown nor selected. And deliberately focusing an AB should imply that card-related actions are done. Windows Explorer also deselects files in file list when clicking into folder list. So I would like to change this. In the long run, we could even show AB properties in the preview pane when AB is selected AND has focus, like big AB icon, AB name, number of contacts, type of AB, etc. Do you want me to open a new bug for this or can we just reopen this one (preferred)?

^^ ni for comment 7

> > - change the default choice in the dialog to be "cancel", not "OK" > > That would be an option worth exploring, but only for AB's, not for contacts. Of course > But if we had UNDO, it wouldn't be required. 1. Undo isn't going to happen until AB is rearchitected - so it's a long way off > Then we'd break people's habits again if we take the default back to OK. 2. When we provide Undo, we should not change a default of "cancel" back to "OK" - these are not mutually exclusive I think changing the default is a more focused, simpler solution than all kinds of other UI trickery. > I'd agree that my new wording which includes the name of the selected AB about to be deleted will make it harder to err here, but only IF one actually takes that second to read the dialog. To wrap things up - I don't think we shouldn't be investing signficant effort and adding significant code to protect users who never read a dialog.

(In reply to Wayne Mery (:wsmwk) from comment #9) > I think changing the default is a more focused, simpler solution than all > kinds of other UI trickery. Point taken. Yet personally I'm hesitant to change the default, because it's also annoying and non-standard - even permanently deleting files on Windows Explorer defaults to yes. Avoiding the ux-mode-error of comment 0 in the first place looks like an equally simple and more sustainable solution to me. If you don't press DEL on the wrong thing because there's nothing which looks like selected for deletion, this error will not occur, and we can keep the confirmation simple and consistent for those who actually need it. > User experience principle: users should not encounter errors because the interface is in a different state than they expected it to be. > > I'd agree that my new wording which includes the name of the selected AB about to be deleted will make it harder to err here, but only IF one actually takes that second to read the dialog. > > To wrap things up - I don't think we shouldn't be investing signficant > effort and adding significant code to protect users who never read a dialog. No worries - it's a one-liner to de-select contacts when the AB list gets focus. Which makes sense because the only reason for focusing an AB is to act on it, where AB actions are very limited, and certainly that implies that I'm no longer interested in the current selection of contact(s). Note that even with several(!) contacts selected, we currently don't remove that selection when focusing the containing AB (for which there is no reason other than to act on that AB). It's also inconsistent that focusing virtually any AB *does* clear the selection, but focusing one certain AB does not, which is quite random (ux-inconsistent). I guess users don't normally select things, then do something else in the same window, and then come back later expecting to act on the old selection. UX-consistency with Windows Explorer is also a worthwhile point imho. WRT users not reading the dialog, any UX guide on the net will tell you to avoid confirmation dialogs because we all tend to ignore them over time if we THINK that we know what we are doing, so we end up pressing ENTER from muscle memory before we even know it. Problem here is that reporter was thinking to delete a contact (and the UI does not do enough to avoid that impression), whereas realiter an AB was selected and focused (with weak/insufficient UI *initial* indication of that). To wrap things up, I guess I'll just have to open a new bug and fix it there, if we can't reopen this one.

> It's also inconsistent that focusing virtually any AB *does* clear the selection, but focusing one certain AB does not, which is quite random (ux-inconsistent). Quite right. I guess correcting UI behavior here to give the user hints is what we should be fixing. And your comment about confirmation dialogs is well said.