506925 - Implement context menu for location bar yellow star (bookmark this page/edit bookmark, show bookmark in Library, remove bookmark) [make all bookmarks properties accessible]

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, enhancement)

Description

[Thomas D. (:thomas8)]

For the yellow star in location bar, implement a context menu that provides intuitive and fast access to (additional) functions involving the bookmark.
Have a look and try it out yourself in the mock-up context menu which I have attached to this comment.

For an existing bookmark, the context meny of the yellow star should at least have the following options:
- Edit this bookmark (default)
- Organize Bookmarks (will open the bookmark in the Library)
- Remove this bookmark 
Having "Organize Bookmarks" on the context menu (which will select the bookmark in the library) might be a low-cost workaround fix for the justified complaint of bug 405795 where users are frustrated that they can't access all properties of a bookmark from the yellow star (in fact, there's NO place in FF where you can edit ALL properties of a bookmark directly, but that's another story).

For a URL which hasn't been bookmarked yet, the grey star's context menu should at least have the following commands
- Bookmark this page

The current context menu of the star shows toolbar customization options, which doesn't feel right on such an outstanding object like the bookmarking star.
Comments on the proposed UI are welcome.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Interactive Mockup of proposed context menu for yellow star

Comment 2

[Marco Bonardo [:mak]]

Comment on attachment 391081 [details]
Interactive Mockup of proposed context menu for yellow star

Alex can probably evaluate this, btw i'm not sure undiscoverable context menus are so useful for quick bookmark access.

Comment 3

[Shawn Wilsher :sdwilsh]

Agreeing with comment 2.  We'll let the module owner decide though.

Comment 4

[Thomas D. (:thomas8)]

Marco, have a look at bug 405795 and its duplicates, or bug 404507 and its
duplicates to see how frustrated people are that there is no direct way
whatsoever to edit all of a bookmark's properties (esp. Keyword) after you have
created the bookmark using ctrl+D or star button. People see the bookmark (i.
e. the star) right in front of them, but they can't do anything with it apart
from the crippled options of "Edit this bookmark" popup. What they then have to
do is open bookmarks manager ("Library") from the menu and do a manual search
for the bookmark, and even then (from search results) they still won't be able
to see what folder the bookmark is in, let alone change that folder. We have at
least 3(!) different "Edit bookmark" dialogues/UIs and NONE of them lets you
change all the properties. To tell you the truth (against nettiquette, I'm
sorry), it sucks. So I think anything which creates some sort of link between
the bookmark star and its actual properties will be a step ahead. Adding a
context menu to the star is ONE way (surely not the best) of creating the link,
and it comes at a far lower cost than changing the primary UI for the star's
"Edit this bookmark" dialogue (for which to be fixed we'll probably have to
wait for more duplicates, more votes, more discussions, and more years). And
yes, I can't code yet and I don't have the time to, so please don't advice me
to come up with a patch.

I don't think there can be anything "undiscoverable" about context menus for primary UI elements, which the star clearly is. I think it's obvious from bug 405795, bug 404507 and their dupes that people have come to think of the star as "the bookmark's object". What do you do when you're looking for (more) commands on a specific object? Personally, first thing I do on any object I'd like to manipulate is check out the context menu (which is what I did before posting this bug). Come on, context menus are *everywhere*, you can even right-click on FF's back button (how discoverable is that?), on the quicksearch box, or on Windows Start button. Call me sensitive, but I don't like the subtle irony of your comment #2 which somehow seems to sound like "the enhancement you
propose will be useless, but anyway, let's have a look before we discard it". Maybe it's because we've had that too often: too many sensible, valid and intelligent user requests and complaints have just been turned down by the people in charge in a very nonchalant manner, just to languish unaddressed for years until the number of duplicates, votes and frustrated comments finally made someone feel that maybe the original idea wasn't so bad after all. I believe the only way for a software to evolve is listening to any serious user feedback with utmost appreciation and try to be as creative, imaginative and flexible as possible when it comes to improvements and innovation.

But maybe you are right - instead of suggesting a fairly easy workaround that
may later be misused as another excuse for the incomplete design of the "Edit
this bookmark" dialogue, I should have spent my valuable time trying to let
people know that "wontfix?" for bugs like bug 405795 or bug 404507 with
duplicates already coming in may seem both arrogant and short-sighted and is
likely to drive users nuts. That is, those users who are still so interested in
improving their favourite Mozilla products that they bother filing bugs and
defending their ideas in a bug system that still submits your personal email
address to the spamming public and doesn't even have a "back to your bug X"
link after you have voted for a bug, that's if you still believe in votes. That
said (am I being negative?), I appreciate Marco's instantaneous reaction and
I'll be interested in the outcome of any care-ful and thought-ful ui-review.

Sorry for flaming. Marco, it's not your fault, your comment was just the
trigger. I'm a complete newbie to XUL, so coding the mockup took me some
considerable time, but knowing how critical folks at mozilla can be, I wanted
to provide a clear illustration of the proposed look and feel. And then the
first comment you get, well, you know...

Hey yea, and then the second comment you get, after "Mid-Air-Collision", is a suggestive "wontfix?" inquiry at the top of your bug. Better don't spend a second thought on unexpected ideas, it might improve your software. BTW, this bug is not primarily about "quick bookmark access", it's about providing access AT ALL to a more complete set of properties. Thanks anyway!

Comment 5

[Mike Connor [:mconnor]]

Writing a page-long rant isn't a productive way to handle this.  I'll be honest, I didn't read it, so I'm replying to comment 0 only.

* Remove Bookmark is in the left click UI, so we're duplicating functionality here.  Not useful.
* the Organize Bookmarks use-case seems very power user-ish.  Really, what you want is "Show This Bookmark in Library" as the string.  I don't think the use-case is that compelling, and seems a little tacked on.
* The "can't edit all properties of the bookmark" piece is probably not best solved by a context menu option on an unfocusable element.  It's not accessible, so we'd need another solution anyway.  I'm going to comment on bug 405795 shortly.

I really get the sense that this is being proposed to get the third point worked around, but that's not really a great way of solving the problem.  We can and should do better.  Marking this WONTFIX.

Comment 6

[Thomas D. (:thomas8)]

[Short summary]

IMHO the wontfix resolution for this bug should be reconsidered, and it should be reopened. My understanding of "wontfix" is that even if someone would want to implement this, they shouldn't. However, this seems to be a valid and useful enhancement at no cost / without any real disadvantages. Details below.

[Details / Reasons]

1) Bug 424044 calls for implementing contextual menus for ALL UI elements of the location bar, including the star (other elements: favicon, rss icon, history dropdown etc.).

2) The discussion in related Bug 428304 (right-click on star should remove
bookmark) is also interesting for this bug because it has many comments from
respected persons that all suggest/accept the idea of having a context menu on
the star (as suggested by this bug and bug 424044). E.g. Jesse Rudermann, bug 428304, comment #2 (to cite just one):
> users would right-click the Star, hoping to get a context menu
(Bug 428304 was rightly rejected because it wanted a delete action triggered by right-click, which was clearly a problematic approach, and people said context menu would be the right approach.)

(In reply to comment #5)

> * Remove Bookmark is in the left click UI, so we're duplicating functionality
> here.  Not useful.

3) !? *Every* contextual menu duplicates existing functionality, so as to provide an easy and unified in-place access to element-related commands. I have no reason to assume this couldn't be useful (it is for me), plus it doesn't hurt to have it.

> * the Organize Bookmarks use-case seems very power user-ish.
> Really, what you want is "Show This Bookmark in Library" as the string.

4) You are right, "Show this bookmark in library" would be the better string.

> I don't think the use-case is that compelling, and seems a little tacked on.

5) "Show in library" is basically the same as "Open containing bookmark folder". That use case is so compelling that it has several bugs filed for it (all of these bugs want a way to know and/or "open the containing folder" of a single bookmark object at hand, and the star is just another representation of a bookmark object):
- Bug 469441, currently 12 votes (Add "Open Enclosing Folder" to search results of bookmarks...)
-  Bug 469421, currently 21 votes (Add folder column to search results for bookmarks...)
- Bug 56418 (Seamonkey equivalent), currently 84 votes (Add folder column...)
Surely all these people don't just want to /know/ the containing folder...
 "Open containing folder/Show this in library" 
OK, you may call this "tacked on". What I see is that a lot of users have a strong need to view a bookmark's containing folder. Having a context menu entry for that action on the star bookmark object will be appreciated by such users, regardless whether such functionality might be available elsewhere (which it isn't, currently!).

> * The "can't edit all properties of the bookmark" piece [bug 405795]
> is probably not best solved by a context menu option on an unfocusable
> element. It's not accessible, so we'd need another solution anyway.

6) The fact that the context menu suggested by this bug isn't the best solution for another bug (as I agree with you) doesn't mean that this proposed enhancement couldn't add value. Many context menus in FF are on unfocusable elements, e.g. on the back button, all toolbars, and tabs. Should we abolish the context menu on tabs because it's an unfocusable element? Since we are deliberately duplicating /existing/ functionality (or such that will exist after the respective bugs have been fixed), I don't think accessibility is an issue here. This is about workflow, UI intuitions and usability. And I /am/ a user, and not the only one with the same intuitions (see related bugs above, especially bug 424044). Besides (please prove me wrong!), I bet my ... that we'll wait long until bug 405795 will get adressed, whereas this little context menu would be far easier and thus faster to implement, without hurting anyone. Some workaround may be better than no workaround...

7) Another personal reason why I am coming back to this:
Each time I want to delete an active bookmark, I automatically want to click the right mouse button to get the context menu on the star. It just doesn't feel right to go to the properties panel and delete the bookmark "from within". I don't think there are many programs that let you delete anything "from the inside" of the object that will be deleted (files etc.). Which might be a natural intuition, because you don't usually go inside things before blowing or throwing them away.

8) Context menus on primary UI elements can never be undiscoverable (against comment #2), on the contrary. For details, see comment #4.

9) I haven't heard any reasons so far that point out an actual *disadvantage* of having a context menu on the star, or a violation of UI princinples. I'm not expecting that FF developers implement this, but maybe someone else wants to. They should be allowed (please remove wontfix!).

> Writing a page-long rant isn't a productive way to handle this.  I'll be
> honest, I didn't read it, so I'm replying to comment 0 only.

10) I admit that the length and the mood of my comment #4 are unfortunate, and so is the fact that you are not reading relevant comments before wontfixing new ideas. Personally, when it comes to discussing UI issues, I don't see any alternatives for using multiple arguments and make them as precise as possible. Generally speaking, "I feel this is bad / I don't like this" by developers is not much different in class from "This bug sucks" by users. Both are not helpful, as they are not based on detailed arguments. I'm aware I'm not good at cutting my points short, but the points I make are usually carefully considered and I do believe they are worth reading. Maybe even the flame ones. Had you read my comment #4, you'd also know why (something about sensible user input being ignored and turned down for years until it finally turns out they were right). Above all, it's that I care for my favourite browser. :)

Comment 7

[Marco Bonardo [:mak]]

you're in the wrong place for this kind of design comments, you should bring the discussion to a newsgroup, and then just report final considerations to a bug, since a comment of this size on a bug would discourage anyone willingto read it.

the point about context menu is that it should reduce the path user has to take to execute the action, actually edit the bookmark is 1 click (click on the start) with context menu would be 2 clicks. Remove bookmarks is 2 clicks (click on the start, click on remove), context menu is 2 clicks (no win). Organize bookmarks is 2 clicks (Bookmarks/Organize bookmarks), with context menu is 2 clicks (no win).

but please, bring proposals to a moz newsgroup and post just final considerations to bugs.

Comment 8

[Thomas D. (:thomas8)]

(In reply to comment #7)

> you're in the wrong place for this kind of design comments, you should bring
> the discussion to a newsgroup, and then just report final considerations to a
> bug

I'm suprised (at least), as I've never ever seen a bug which is limited to "final considerations"; especially with enhancement bugs this seems very much impossible. But I see you are taking offence in the length of my postings (regardless of the content), and apparently (sadly) it does seem to discourage even competent people from reading it.

Personally, I feel that digging into moz newsgroups is another burden I am currently not willing to take, and I don't have the time to. But perhaps you could let me know the name/URL of the right newsgroup where enhancement requests like this one should be discussed.

btw, merely based on your method of "counting clicks", a lot of context menus should never exist in the first place. IN-PLACE editing is the keyword here.

> Organize bookmarks is 2 clicks (Bookmarks/Organize bookmarks), with context
> menu is 2 clicks (no win).

Well, NO... But it's my fault that you are getting one of the key points of the suggested enhancement wrong, because I chose the wrong label in the mockup of attachment 391081 [details]. This isn't about "Organize bookmarks" in the sense of just "Open the library" (which would be 2 clicks, indeed). As per my comment #1 (still short!) and Mike's comment #5 (that's a short one, too ;)), it's "Open/Show *this bookmark* in the library". You show me how to do that in 2 clicks, and we could as well close down all of those bugs I mentioned in comment #6, number 5), and make more than 100 users who voted for those bugs very happy. But then, you don't like reading my comments. Fair enough. eom.

Comment 9

[Marco Bonardo [:mak]]

just FYI, i read comments before replying, or would not even reply. I'm just pointing out that long posts on bugzilla tend to be ignored, is not a personal thing, just what tends to happen. So directing energy better would gain better results.
You have a good point about exposing the containing folder, but that can have better impementations than a context menu here.
mozilla.dev.apps.firefox can be a good choice for large discussions.

Comment 10

[Thomas D. (:thomas8)]

Attachment: Interactive Mockup (V2) of proposed context menu for yellow star

(In reply to comment #5)
> Really, what you want is "Show This Bookmark in Library" as the string.

Revised interactive mockup of the proposed star context menu as per Mike's comment #5. Improved layout and mockup code cleanup.

Comment 11

[[:Aleksej]]

See also bug 582907.