"Delete" should not be next to "Reload Live Bookmark" in context menu

RESOLVED FIXED in Firefox 27

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Arnaud Bienner, Assigned: Arnaud Bienner)

Tracking

Trunk
Firefox 27
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 4 obsolete attachments)

(Assignee)

Description

5 years ago
I sometime want to reload my "Live bookmark", so I right click on it, and select "Reload Live Bookmark".
However, IMHO it would be better to reorder this menu a bit, to avoid someone to accidentally click on the "Delete" action just above "Reload Live Bookmark".
I believe users may click "Reload Live Bookmark" more often than other actions, and as so, it would be nice to not have it close to a destructive action like "Delete".

I suggest to move it above the "Cut" action, because it's also a "destructive" action (even if in this case it's not completely deleted).

Let me know if you think it would be worth to change this.
(Assignee)

Comment 1

5 years ago
Created attachment 800812 [details] [diff] [review]
reorder_menu.patch

Here is a patch to illustrate my idea.
(Assignee)

Updated

5 years ago
Summary: "Destructive" actions like "Delete" and "Cut" should be put together in context menu → "Delete" should not be next to "Reload Live Bookmark" in context menu

Comment 2

5 years ago
Comment on attachment 800812 [details] [diff] [review]
reorder_menu.patch

Thanks for the patch.  Marco, what do you think?
Attachment #800812 - Flags: review?(mak77)

Updated

5 years ago
Component: Untriaged → Bookmarks & History
Since this change requires super-review, it would be useful to get a high-level summary of what changes exactly (it can be hard to figure that out from the code change). A set of screenshots showing before/after would also be helpful.
(Assignee)

Comment 4

5 years ago
Well, I already tried to explain the purpose of my change in my first comment (I agree it might not be easy to figure out what it changes by looking at the code), and why I think it will be worth.
Which part isn't clear enough?

I will attach scrennshots anyway if it can help.
(Assignee)

Comment 5

5 years ago
Created attachment 805383 [details]
Current context menu
(Assignee)

Comment 6

5 years ago
Created attachment 805385 [details]
Context menu proposal
(Assignee)

Comment 7

5 years ago
I've attached screenshots from the bookmarks toolbar, but please note the same menu  is also displayed when browsing the library for example (the items shown aren't exactly the same though).
But I think the change is also worth if the menu is accessed this way.
for the sake of completeness I must point out that in your screenshots it's not visible the fact there are <hr>s before and after the delete command, they have been added exactly to limit the possibilities of misclicks. If you look at the contextual menu in Explorer, you will notice there's not even those <hr>s, are you misclicking Delete in Windows explorer as well?

That said, I'm not sure what you solved by moving delete, after your change it will just be easier to misclick on it instead of "new separator" or "cut", instead of misclicking on it instead of "Reload live bookmark" and "paste". If we really should consider this an issue, I think we need a better solution than just moving the problem elsewhere. I'm still not sure I consider this an issue, since we have undo functionality (at a maximum the issue may be undo is hard to discover)
Comment on attachment 800812 [details] [diff] [review]
reorder_menu.patch

well, the previous comment counts as a first pass review
Attachment #800812 - Flags: review?(mak77)
(Assignee)

Comment 10

5 years ago
(In reply to Marco Bonardo [:mak] from comment #8)
> fact there are <hr>s before and after the delete command,

That's right, and that's a good thing. But IMHO it's not enough.

> If you look at the contextual menu in Explorer, you will notice there's not even
> those <hr>s, are you misclicking Delete in Windows explorer as well?

Having other softwares behaving in a "bad" way doesn't mean we are doing the right thing.
But at least explorer asks for confirmation before actually deleting the file.
This makes a misclick less serious.
As you said, there is "Undo" functionality, but it's not obvious at all: I just discovered it.
Unless I missed something, if I remove a "Live Bookmark" from the menu bar, the only way to undo this action is to open another window (the library) to perform the undo action from there. Am I right?

> That said, I'm not sure what you solved by moving delete, after your change
> it will just be easier to misclick on it instead of "new separator" or
> "cut", instead of misclicking on it instead of "Reload live bookmark" and
> "paste".

My point (and the initial reason for opening the issue) is that user will probably, IMHO, click often on "Reload live bookmark" than "New separator" or "Cut".
Maybe I'm wrong (and if so, this bug can be closed).
But if I'm right, moving the "Delete" will reduce the number of misclick.
(In reply to Arnaud Bienner from comment #10)
> Unless I missed something, if I remove a "Live Bookmark" from the menu bar,
> the only way to undo this action is to open another window (the library) to
> perform the undo action from there. Am I right?

Unfortunately yes, the undo/redo feature is part of the Library. But it manages any bookmark operation.

> My point (and the initial reason for opening the issue) is that user will
> probably, IMHO, click often on "Reload live bookmark" than "New separator"
> or "Cut".

The position is is not just for livemarks it's for all bookmarks. Very few people today use livemarks (in percentage out of our users), but the change would hit anyone using bookmarks. So, the Reload live bookmark operation is something used by very few persons, and not that often since they are updated every hour regardless.

My point about the operating system was not much about "what's best", rather more about platform consistency, delete usually comes after cut/copy/paste (that's why it's there originally). That's where the average user looks for it.

So, I don't think we can change this since:
1. it just moves the problem elsewhere
2. it moves delete to a non-native position
3. it changes all bookmarks handling for the benefit of a less used feature

Figuring out a solution that satisfies these points may be hard.
(Assignee)

Comment 12

5 years ago
Thanks for your answer.
I don't have any knowledge about what the majority of users use: I was just mentioning my own "feeling"/experience about this.
Indeed moving the "Delete" might not be consistent.
So maybe the "Reload Live Bookmarks" should be moved elsewhere instead? As this would not impact other bookmarks (which don't have this action) this should can be feasible I guess?
Between "Open all tabs" and "New bookmark" would be the best place IMO (surrounded by <hr>s maybe). What do you think?

That being said, now I'm aware there is a way to "Undo" a deletion of a bookmark, I think can also consider the "make the 'undo' more obvious in the menu bar" issue, as you said in comment 8.
(In reply to Arnaud Bienner from comment #12)
> So maybe the "Reload Live Bookmarks" should be moved elsewhere instead? As
> this would not impact other bookmarks (which don't have this action) this
> should can be feasible I guess?
> Between "Open all tabs" and "New bookmark" would be the best place IMO
> (surrounded by <hr>s maybe). What do you think?

we could probably move it below Sort By Name... that area of the context menu is thought for this kind of options.
If you want to provide such a patch I may evaluate it.
(Assignee)

Comment 14

5 years ago
Created attachment 807247 [details] [diff] [review]
reorder_menu.patch: 2nd

Here is a new patch.
I moved "reload live bookmark" after "sort by name", so it's not close to "Delete" action now.
Let me know what you think about this.
Attachment #800812 - Attachment is obsolete: true
Attachment #805383 - Attachment is obsolete: true
Attachment #805385 - Attachment is obsolete: true
Attachment #807247 - Flags: review?(mak77)

Updated

5 years ago
Assignee: nobody → arnaud.bienner
Status: NEW → ASSIGNED
Comment on attachment 807247 [details] [diff] [review]
reorder_menu.patch: 2nd

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

usually I'd not take patches changing order of options, since they break muscle memory of users, though in this case it's affecting a very minor percentage of users, only livemarks, and likely in a positive way (the reason this bug has been filed). It's also fixing the movement of Sort By name compared to other containers. So, I think it's fine regardless the negatives.

Before setting checkin-needed keywords, please remember to properly fix the patch commit message to include the bug number a description and the review token
Attachment #807247 - Flags: review?(mak77) → review+
(Assignee)

Comment 16

5 years ago
Created attachment 814207 [details] [diff] [review]
reorder menu patch: 3rd

New patch with a proper commit message.
Setting r+ as it was given by mak77 on the previous patch (attachment 807247 [details] [diff] [review]).
Attachment #807247 - Attachment is obsolete: true
Attachment #814207 - Flags: review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/16ede6b5df84
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/16ede6b5df84
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 27
You need to log in before you can comment on or make changes to this bug.