236340 - Change position of Delete and Properties items in the context menu of Address Book and contacts sidebar

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[mdimitrio]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

"Change location of Delete and Properties in the context menu of Address Book"

This has happened more than one time to me, when you want to see a item's
properties, you right click that item and go straight to the last item in the
context menu, which usually is labeled Properties. This is true for every
application that I know, even Mozilla (a few context menus work like that too),
but in the Address Book, right clicking an address will pop a menu that has
Delete as the last item, and Properties as the first, so you end up deleting the
item.

Selected "Severity: Critical", since the description for it is "The software
crashes, hangs, or causes you to lose data". Made me loose entries on the
address book.

Marcos.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Rene Pronk]

This is definitly not critical. Marking trivial since it is purely cosmetic:
Trivial	cosmetic problem like misspelled words or misaligned text

Though I can't think of one right now I know for sure that there are more
Windows applicaties out there that have properties as the first item, usually in
bold.

And what if we'd swap Delete and Properties? Having Delete as the first option
isn't very attractive. Perhaps the best thing would be

New card
New list
--------
Delete
--------
Properties

or something like that.

Comment 2

[Stefan Borggraefe]

While "Properties" is the last menu item in most of Mozilla's context menus, the
menu item that triggers the default action (double-click action) should be the
first item in the context menu. I think this bug is probably WONTFIX because of
this.

Perhaps such menu items should be bold. Currently this is only the case in the
Bookmarks Manager.

Comment 3

[[e-mail]]

Although having Delete as the first item is probably a bad idea... perhaps it
(and its separator) should be moved down to just above Properties?

Comment 4

[mdimitrio]

I like the way Rene has proposed, in post #1. It's much more natural do have 
these items organized like that:

New card
New list
--------
Delete
--------
Properties

Marcos.

Comment 5

[Daniel Hyde]

This also applies to the main email/newsgroup display area -- the context menus
in both the list-of-emails window and the message display window contain Delete
at the very bottom of the list.

The context menus also allow you to select an item in the list with *any*
button, including the one (right click, generally) you used to open the menu in
the first place (Mozilla 1.7, X11R6, FreeBSD) -- although I don't count this as
a bug since nearly every context menu I've seen behaves like this.

But it does get inconvenient when you keep your email window down the bottom of
the screen, where the context menu always pops up *above* the mouse.  If you
inadvertently double-right click on either of these windows in such a situation,
you delete the message.  Maybe I'm the only person in the world who
inadvertently double-right clicks.

I would suggest having less-critical functions on the extreme ends of context
menus and save delete and friends for the middle, where it takes much more
conscious effort to activate it.

Comment 6

[Mark Banner (:standard8)]

I would be very cautious about changing the position of delete & properties at
the moment - users will have got used to the way they are now, and as we don't
have an undo feature changing this could be a bad idea. Suggest we implement the
undo feature first and then revisit this one to decide if we want to do it or not.

Comment 7

[Mark Banner (:standard8)]

*** Bug 275948 has been marked as a duplicate of this bug. ***

Comment 8

[Thomas D. (:thomas8)]

This bug is currently not actionable, but it definitely needs action, for the reasons mentioned above. 5 years later, the biggest problem seems to be this:

VC: Contacts sidebar context menu (current)

Delete
Properties
-----------
Add to To
Add to CC
Add to Bcc

- Main problem: Missing separator after Delete. People who click on Properties might easily miss their target, which will permanently delete selected contact(s) without warning, due to bug 650789 and bug 94407.
- Secondary problem: Delete should not be the first action. First action should be default action (Properties, cf. Bug 650745)


V1: Contacts sidebar context menu (Variant 1, expected)

Properties (1)
--------------
Add to To
Add to CC
Add to Bcc
--------------
Delete

This looks like the best alternative to me.
1.1 Have Properties as first action (default action, cf. Bug 650745)
- ux-consistency: the main address books context menu for contacts also has Properties as the first action
1.2 Have Delete as the last action (with added separator for extra safety!), because
- it's probably least frequently used
- have actions in intuitive order (deletion is always the last action on an item)
- the main address books context menu for contacts also has Delete as the last action (and properties first).
- message context menu also has delete as last action


V2: Contacts sidebar context menu (Variant 2, alternative)

Properties
--------------
Delete
--------------
Add to To
Add to CC
Add to Bcc

Some have argued that if user wrongly double-right-clicks, and context menu pops up above the contact, they might hit Delete accidentally if it's the last item. I think that scenario is very unlikely, and we need confirmation and undo to avoid it. Personally, I would not consider that for the menu sequence, and give priority to ux-consistency (have Delete as last item, as elsewhere).

Comment 9

[Thomas D. (:thomas8)]

Next steps (to be done): ask for UI-review of comment 8, V1

Comment 10

[Thomas D. (:thomas8)]

Attachment: request UI-review for reordering contacts sidebar context menu (per comment 8, V1)

Read comment 8 for full details.

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 527368 [details]
request UI-review for reordering contacts sidebar context menu (per comment 8, V1)

I'd agree with Mark in comment 6 that this is a dangerous place to play.  Most people are probably used to the current layout so changes like these can often create some unwanted/undesired consequences.  I usually only reserve rearranging the deck chairs when we're making greater changes (like a better menu) so there's an more obvious reason the user can assume.

Again, Blake's call here.

Comment 12

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 527368 [details]
request UI-review for reordering contacts sidebar context menu (per comment 8, V1)

I really think that in the context of writing email, the "Add to {To,Cc,Bcc}" entries should be first.  I would ui-r+ the following:

Add to To
Add to CC
Add to Bcc
--------------
Delete
--------------  // Either with or without this line.
Properties

But, as Bryan and Standard8 mentioned, we shouldn't just re-arrange items in this menu, but should really add something new, so even this new layout would be contingent on adding, say, an Undo option.

Thanks,
Blake.

Comment 13

[Thomas D. (:thomas8)]

(In reply to comment #12)
> But, as Bryan and Standard8 mentioned, we shouldn't just re-arrange items in
> this menu, but should really add something new, so even this new layout
> would be contingent on adding, say, an Undo option.

...or, say, doing Bug 665267 - Contacts Sidebar: Please add a "confirm on delete" option for address book entries

Comment 14

[Thomas D. (:thomas8)]

Attachment: request UI-review for reordering contacts sidebar context menu (per Blake's comment 12)

(In reply to comment #12)
> Comment on attachment 527368 [details]
> I really think that in the context of writing email, the "Add to
> {To,Cc,Bcc}" entries should be first.  I would ui-r+ the following:
> 
> Add to To
> Add to CC
> Add to Bcc
> --------------
> Delete
> --------------  // Either with or without this line.
> Properties

pulling ui-review+ forward from Blake's comment 12.

Blake, thanks for quick UI-review. Blake's proposal is better than my comment 8, V1:
- Currently, "Add to To" is the default action, albeit incompletely implemented (double-click works, Enter does not). So "Add to To" and friends need to go to the top.
- Having "Delete" in the middle (and surrounded by separators on both sides) makes it safer against accidental use
- Having "Properties" at the end is common practice in many places, including Windows Explorer.

Comment 15

[Thomas D. (:thomas8)]

I just realized that I slightly hijacked this bug for changing the order off the *contacts sidebar*, while comment 1 (without STR) is about the main address book. Anyway, I guess it's good to handle them together.

I can see two different context menu's in the main AB:

CM1.VC (current context of main address books)

Properties
-------------
New list
New contact
-------------
Delete


Delete is disabled, anyone knows why or when it gets enabled?

CM2.VC (current context menu of normal contacts)

Properties
----------------
Write
Instant Message
----------------
Delete

For those two context menus, this bug is still seeking an alternative order (after undo and/or confirmation on delete have been implemented).
Any other address book context menus that we forgot?

Comment 16

[Wayne Mery (:wsmwk)]

(the dataloss bit is really handled in other bugs)

Comment 17

[:aceman]

I like the order in comment 12 and it should be easy to do. Now that bug 665267 is fixed, users should not shoot themselves in the foot when they click by muscle memory.
Can we move this forward? At least for the Contacts sidebar.

In the addressbook, the context menu of a contact has Delete as the last item and Properties (the default action) as the first one. Is there anything to do?

Comment 18

[Blake Winton (:bwinton) (:☕️)]

I think my previous comment stands.  Just re-arranging without making any other changes will break people's muscle memory, and while we don't shoot them in the foot anymore, it's still not something we want to do to them willy-nilly.

Comment 19

[Thomas D. (:thomas8)]

(In reply to Blake Winton (:bwinton) from comment #18)
> I think my previous comment stands. 

That's good! :) Iirc, your previous comment was comment 12, where you said you would be happy with changing the context menu sequence to be more efficient, more usage-oriented, arguably more ux-consistent, and safer against accidentally clicking DELETE, per your UI proposal (which I filed as attachment 540218 [details]):

(In reply to Blake Winton (:bwinton) from comment #12)
> Comment on attachment 527368 [details]
> request UI-review for reordering contacts sidebar context menu (per comment
> 8, V1)
> 
> I really think that in the context of writing email, the "Add to
> {To,Cc,Bcc}" entries should be first.  I would ui-r+ the following:
> 
> Add to To
> Add to CC
> Add to Bcc
> --------------
> Delete
> --------------  // Either with or without this line.
> Properties
> 
> But, as Bryan and Standard8 mentioned, we shouldn't just re-arrange items in
> this menu, but should really add something new, so even this new layout
> would be contingent on adding, say, an Undo option.
(:bwinton from comment 18)
> Just re-arranging without making any
> other changes will break people's muscle memory, and while we don't shoot
> them in the foot anymore, it's still not something we want to do to them
> willy-nilly.

Fair enough! The good news is, the situation has improved since you filed that comment 12, as the following bug was fixed:

Bug 665267 - confirmation for deleting contacts from sidebar context menu

I think that was the main pain point against changing the sequence, that users who use cursor by muscle memory to navigate the menus might face dataloss. So that has been addressed, and Undo would be just a bonus, but no longer required to play safe. So I'm not sure if there's anything else we could do, as in "any other changes" that you mention?

I suspect that suspected muscle memory for a small group of users (cursor users only, access keys will remain!) can't be a reason to block better and safer order of context menu commands (as you proposed in your comment 12) for good?

What if we support those users to get rid of that unfortunate and clumsy muscle memory (context menu key, cursor down, Enter) by doing Bug 343973 first which already has your ui-review+:

Bug 343973 - Contacts sidebar: Implement [DEL] keyboard shortcut to delete selected and focused contact(s)

Think about it, whatever little muscle memory there might be, it's really just a workaround because we failed to offer immediate intuitive deletion with [DEL] on selected contacts (Bug 343973), which in turn was blocked by Bug 665267 which is now fixed... Which makes me think we're probably ready for rolling on...

So if we do Bug 343973 first as a sustainable alternative to obsolete muscle memories, so it's no longer willy-nilly, is there anything else we should/could do before proceeding with your UI proposal of comment 12?

Comment 20

[Blake Winton (:bwinton) (:☕️)]

(In reply to Thomas D. from comment #19)
> (In reply to Blake Winton (:bwinton) from comment #18)
> > I think my previous comment stands. 
> That's good! :) Iirc, your previous comment was comment 12, where you said
> you would be happy with changing the context menu sequence to be more
> efficient, more usage-oriented, arguably more ux-consistent, and safer
> against accidentally clicking DELETE, per your UI proposal (which I filed as
> attachment 540218 [details]):

Sadly, you forgot the most important part of my comment in your summary…
Fortunately, you include it below.

> (In reply to Blake Winton (:bwinton) from comment #12)
> > But, as Bryan and Standard8 mentioned, we shouldn't just re-arrange items in
> > this menu, but should really add something new, so even this new layout
> > would be contingent on adding, say, an Undo option.
> (:bwinton from comment 18)
> > Just re-arranging without making any
> > other changes will break people's muscle memory, and while we don't shoot
> > them in the foot anymore, it's still not something we want to do to them
> > willy-nilly.
> 
> Fair enough! The good news is, the situation has improved since you filed
> that comment 12, as the following bug was fixed:
> 
> Bug 665267 - confirmation for deleting contacts from sidebar context menu
> 
> I think that was the main pain point against changing the sequence, that
> users who use cursor by muscle memory to navigate the menus might face
> dataloss.

I'm sorry to tell you this, but you're wrong.  The main pain point against changing the sequence is that millions of users will have to re-train themselves to do something different than they've been doing for a long time, with no added benefit to them.

> I suspect that suspected muscle memory for a small group of users (cursor
> users only, access keys will remain!) can't be a reason to block better and
> safer order of context menu commands (as you proposed in your comment 12)
> for good?

And yet it is.

> So if we do Bug 343973 first as a sustainable alternative to obsolete muscle
> memories, so it's no longer willy-nilly, is there anything else we
> should/could do before proceeding with your UI proposal of comment 12?

That might be enough.  Are there any other changes we would like to make to that menu, while we're mucking around in it?  Perhaps add some IM-related entries?

Comment 21

[Richard Marti (:Paenglab)]

Attachment: Bug236340.patch

I think it's save enough with bug 650789 landed to change the order.

The two sidebar menus are simple and I don't think adding more entries (except a Undo) are here useful.

All AB menus are now consistent with individual actions on top, then Delete and then Properties on bottom.

Comment 22

[:aceman]

Is it correct that the Properties item isn't on top, when that is the action on double-click?
The only menu where Properties is on bottom is in the folder pane.

Comment 23

[Richard Marti (:Paenglab)]

Not every top menuitem is the default action on double click. Like in the folder pane on on folders the "Open in New Tab" or in newsgroups the "Get Messages".

I think it's more important to have menus where the same items are at the same place.

But if you like it more I can leave the abResultsTreeContext popup untouched.

Comment 24

[:aceman]

(In reply to Richard Marti (:Paenglab) from comment #23)
> Not every top menuitem is the default action on double click. Like in the
> folder pane on on folders the "Open in New Tab" or in newsgroups the "Get
> Messages".

There is no action on doubleclick, so that is not a good example. In all context menus I have tried now (TB and FF) where there is also a doubleclick action, the first item in the menu is this action.

> I think it's more important to have menus where the same items are at the
> same place.

Yes, I like the consistency. But if there are any conventions we should keep them.
I don't know where the idea that Properties is the last item came from. E.g. in Firefox I can't see any context menu where that is the case. Even the bookmark editor has Delete as the last item (what this bug fights against).

> But if you like it more I can leave the abResultsTreeContext popup untouched.
The problem is also in addressbook list.

You implemented comment 12 and that also makes the first item be the double-click action. So why does that not hold in the 2 AB context menus?

I simply see no support for the claim that Delete can't be the last item, because Properties should be there. That is the case in a single menu in TB. In FF it is the case only in bookmark list (Delete is second to last, Properties is last). And as written, when you enter Bookmark library, the Properties item is lost so Delete is last now.

I would not be against such a convention, but I do not see it being there yet. The first item is the doubleclick action is kept more often.

Let's discuss this a bit before changing the patch.

Comment 25

[:aceman]

Of course, the potential conventions are only clashing in the AB because Properties is the doubleclick action here so we need to decide which of the conventions to keep here.

Comment 26

[Richard Marti (:Paenglab)]

I can only implement comment 12 and leave the two others. They are short menus and so it's not so hard to find the items. Then the double click convention is still valid.

Comment 27

[:aceman]

I would support that part.

Comment 28

[Richard Marti (:Paenglab)]

Attachment: Bug236340.patch v2

Now only comment 12 implemented.

Comment 29

[:aceman]

Comment on attachment 8762575 [details] [diff] [review]
Bug236340.patch v2

Review of attachment 8762575 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks.

Comment 30

[Richard Marti (:Paenglab)]

https://hg.mozilla.org/comm-central/rev/17d2260dacf2