Closed Bug 405795 Opened 17 years ago Closed 7 years ago

Can't access all bookmark properties from location bar yellow star ("Edit this bookmark" popup, cannot change Keyword, Description, Location)

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: tuukka.tolvanen, Unassigned)

References

Details

(Keywords: uiwanted, Whiteboard: has two UI proposals)

Attachments

(4 files, 1 obsolete file)

Better Screenshot of 3 incomplete "Edit bookmarks" dialogues
39.36 KB, image/gif
Details
Sample UI picturing the desired functionality (Mockup screenshot of expandable "Edit this bookmark" popup)
87.01 KB, image/jpeg
Details
Sample UI (2) with "Open Containing Folder" button, icon size (Mockup screenshot of expandable "Edit this bookmark" popup)
145.56 KB, image/jpeg
Details
Simple expand to window glyph
1.15 KB, image/png
Details
firefox trunk 2007-11-27-09Z linux I tried to create a keyword boorkmark for a search (fi.wikipedia, if you're curious), so as a first step I made a dummy search and clicked on the star in the location bar to create a bookmark. Then I clicked on the star again to get the popup that allows touching some properties of the bookmark. Unfortunately it doesn't give me any way to edit the url or the keyword, instead giving me a dead end from where I have to make note and remember the Folder where the bookmark ended up while I backtrack from my mistake and go through the Bookmarks menu to Show All Bookmarks and navigate to the folder to get to the properties of the bookmark. That was pretty frustrating (keywords: dead-end, remember, backtrack, mistake ;) The location bar star popup should have a way of accessing the properties of the bookmark that are not editable in the popup itself; a Properties button, Open Containing Folder button, something like that.
Component: Bookmarks → Places
QA Contact: bookmarks → places
I imagine the bug as summarized is a dupe. However the specific issue of creating a keyword for a search is easily done by right clicking in the search field of the actual search you want to keyword. In that context menu there will be a selection for "Add a Keyword for this Search..." which will open a dialog to create that special kind of bookmark.
Bug as described is a dupe, despite the issue of the specific case here.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
404507 would solve the specific case of the keyword, but this was meant as more generally allowing access to everything about the bookmark, not in particular by adding fields to the "Page Bookmarked" popup.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
a couple of options: 1. add the progressive disclosure bit to the contextual dialog to expose the other fields 2. add a button for "more" that opens the Library with the bookmark selected and the properties panel focused for editing
Keywords: uiwanted
OS: Linux → All
Hardware: x86 → All
Status: REOPENED → NEW
Also, 3. Don't clutter up our primary UI by adding more to it, and let people go to secondary UI or use an add-on if they want more advanced control.
Whiteboard: wontfix?
Depends on: 404507
right, this is mainly for providing a reasonable access point for the secondary ui (organize bookmarks with the object at hand selected, most likely) without having to go through the trouble of browsing around for what is trying to present itself as being right in front of you and then bait'n'switching into browseable hiding when you want to see twiddle the rest of the object props.
How about using the same dialog from the bookmarks Library? Whenever I bookmark something in Firefox, I have to get paste the crippled pop-up, then I go to Organize Bookmarks, search for my bookmark, and finally change the URL and add a comment. I'm sure the process can be simplified.
(In reply to comment #9) > I'm sure the process can be simplified. Yes, the process definitely needs to be simplified! Current Situation / behaviour: A) Right now, there's 3 different dialogues to edit a bookmark, and none of them lets you edit ALL of a bookmark's properties (see screenshot attached): 1) "Edit this Bookmark" dialogue from location bar's yellow star (or Ctrl+D): can't edit Location, Keyword, and Description (and "Load this bookmark in Sidebar") 2) "Properties of <bookmarkname>" dialogue from a bookmark's context menu in the sidebar or bookmarks menu: can't change the Folder. 3) [title-less] Properties dialogue of Bookmarks Library (Organize Bookmarks, Ctrl+Shift+B) can't change/see the Folder, either, which is worse because you'll have no way to know the Folder for bookmarks returned by a search. B) Furthermore, dialogues 1) and 2) that are accessed from FF main window aren't linked in any way to the Bookmark library (Organize Bookmarks), so you'll have to restart searching in the library to see your bookmark in context. Expected behaviour: ad A) No doubt duplicate bug 426674 comment #2 has it right: > We need a unified, consistent view of bookmark properties. Comment #9 proposes using the bookmark library properties panel as an expandable dialogue, which is same as option 1) from comment #2. I don't think the properties panel looks "cluttered" (against comment #7) just because of that tiny "More" button in the lower left corner. Option 2) from comment #2 (add a link to the library) should be seen as an addition, not an alternative for option 1). Forcing users to go to the library just to edit a single bookmark property isn't acceptable in the long run. Yet, the link is needed: ad B) In addition(!), every bookmark, no matter where I catch it, should offer some way of "view containing folder" or "view in Library". B.1) Most likely this command could go into the respective context menus, to avoid "cluttering" the primary UI. B.2) Alternatively, a small 16x16px icon-size button next to folder property text box could be implemented to view the folder in the library.
Better Screenshot without distracting paragraph marks ;) Replaces Screenshot attachment #391200 [details] of comment #9.
Attachment #391200 - Attachment is obsolete: true
The Seamonkey equivalent of this bug is bug 89001 (File/Add Bookmark Dialog should take keyword, comment, etc), which has 18 votes and 9 duplicates and it is was assigned as a valid request for enhancement. This bug has 6 votes and 1 duplicate. Duplicate Bug 426674 has 3 votes (Clicking the Star should give possibility to fill all bookmark properties) which due to another bug cannot be transferred. The main reason put forward by users to explain the need for enhancement is that while the yellow star "Edit this bookmark" dialogue is the first and most prominent place to edit a bookmark's properties and that having to re-search manually to find end edit a bookmark which is already right in front of you is frustrating and absurd. With respect to fears of cluttered primary UIs, this bug can be fixed by adding a single button to the current "Edit this dialogue" UI. What the action of that button should be (expanding the dialogue or linking to the library), is another question. Commment #7's advice to use the secondary UI doesn't help much because there is no bridge at all between the primary and secondary UI. Whether keywords and descriptions are really "advanced control" is very arguable, and so is advising users to install addons just to efficiently edit all properties of a bookmark. In view of the above, considering "wontfix?" for this bug just can't be right, whereas "uiwanted" seems the appropriate question to ask. The two labels don't go well together. "Wontfix?" consideration will just prevent people from coming up with ideas and patches to find a good solution to this very obvious UI problem.
Whiteboard: wontfix?
Please do not remove the wontfix nomination. You are not a module owner.
Whiteboard: wontfix?
I'm sorry, still learning. No offence meant. So only module owners can remove wontfix nomination? Is there a list of module owners? I posted RFE Bug 506925 (Implement context menu for location bar yellow star) which might alleviate the negative effect of this bug to some extent by providing a context-sensitive link to open the bookmark in the library without touching the primary UI of the dialogue in any way. It's not an alternative to addressing this bug, but I imagine it comes at a lower cost both in terms of UI decisions and resources needed to implement.
I just WONTFIXed bug 506925. It's the wrong solution. As for owners: http://www.mozilla.org/projects/firefox/review.html is probably best. Thomas, it's clear you're very passionate about this issue, however you are really not helping your cause by railing at people. When the SeaMonkey bug filed eight years ago hasn't been fixed, and only has 18 votes, it's a pretty clear sign it's not a very common use case. It may be best to fix this via an extension for those users who require finer-grained control over their bookmarking. As it stands, we've been working to streamline, not expand, the bookmark dialog for the general case, so this bug may not be something we're going to do in the core app. I think it deserves some further thought before we WONTFIX it, and a small/unobtrusive disclosure widget would be most interesting to explore, but it would certainly best to prototype such a concept as an extension before we consider including it in core. If you really want to see this happen, I would strongly recommend that you put some effort into implementing a sample UI that is unobtrusive by default, and yet presents a usable UI when expanded. Moving this to P5/Future, but if something comes along that is useful and minimally intrusive, I'm not opposed to taking something we're happy with.
Priority: -- → P5
Whiteboard: wontfix?
Target Milestone: --- → Future
(In reply to comment #15) > I just WONTFIXed bug 506925. It's the wrong solution. As for owners: > http://www.mozilla.org/projects/firefox/review.html is probably best. Thanks for the review link. I am glad we agree that a context menu for the star as per bug 506925 is not actually a good and conclusive solution for this bug 405795 (and I never said so). However, it might still be an improvement over the status-quo, at a supposedly lower cost, by adding a "Show This Bookmark in Library" link. I still don't see how a context menu on the star could do any harm, but I'm not going to discuss this any further against poor arguments like "undiscoverable" and "duplicating existing functionality". > Thomas, it's clear you're very passionate about this issue, however you are > really not helping your cause by railing at people. I'm glad I am still passionate about my favourite mail and browser apps by Mozilla in spite of many shortcomings and a rather high resistance often felt in bmo when trying to improve things. I don't think I've been railing s.o. in this bug; I don't usually rail at PEOPLE at all; I did get somewhat over-excited in bug 506925 comment #4, and unfortunately the attempt of explaining the reasons for such excitement ended up as a "page-long rant" that I can almost understand people are not inclined to read. > When the SeaMonkey bug filed eight years ago hasn't been fixed, > and only has 18 votes, > it's a pretty clear sign it's not a very common use case. It's that kind of unfounded logic that make's me despair. No railing intended, but let me put that into perspective: If I understand you correctly, your argument runs like this: - hasn't been fixed for a long time (8 yrs) - has only 18 votes (+ ca. 9 votes for FF) --> conclusion: not a frequent use case I don't think that's true at all. - real frequency of use cases is very hard to determine without doing large-scale user surveys on the ground; certainly bmo is not a reliable source for that, thought it might be an indication sometimes - many bugs haven't been fixed for years in spite of clear indications of a frequent use case (e. g. a very high number of votes, even more than 100 votes, see example bug 56418 below) - "has ONLY 18 votes"? Let alone the complexity of bmo and the validity shortcomings and unclear role/relevance of the voting system: Out of a total of 2681 active bugs filed against Firefox and Seamonkey that have 2 or more votes at all (including enhancements and unconfirmed, exluding resolved), only 170 such bugs have 18+ votes. Iow, ONLY the top 6.3 percent of all active bugs with 2+ votes have 18+ votes (and there's more votes for this e.g. in bug 404507). You can hardly use that as evidence for the non-frequency of that use case. Let's be serious: If the highest number of votes for any bug from the above query is 175, and the number of firefox users alone is about 160 Million according to spreadfirefox.com, then theoretically(!) every single vote represents roughly 1 million users. Which is not a sound claim at all, but just serves to show the problem of relating the number of bmo votes with the frequency of real-life use cases. Here's an example, very much related to this bug: Bug 56418 (the Seamonkey equivalent of FF Bug 469421) calls for adding a "Containing folder" column to library search results, because currently the user can't know nor open the containing folder of a found bookmark. So essentially people complain because the set of properties returned is incomplete and there's no link to the containing folder in the library. Almost same situation here in this bug. FYI: Bug 56418 has been filed 2000 (9 yrs ago), has 83 votes (+ 19 votes for FF)and isn't assigned yet. You draw your own conclusions. (I am not blaming anyone, but I am arguing against wontfix inclinations for the wrong reasons). > a small/unobtrusive disclosure widget would be most interesting to explore... ...as has been suggested in comment #5 (progressive disclosure). Likewise, comment #9 suggested to use the same properties panel as in the bookmarks library, which has a "more" button for disclosure of all properties except containing folder. So it all exists, the code is there, it's just in the wrong place as you can see from the screenshots of attachment 391221 [details]. > If you really want to see this happen... I do, and so I'll happily provide a sample UI as you requested, even though it'll be just the existing library properties panel with different colors (sigh)... I'll make up for another lengthy comment by providing a high-quality mockup UI screenshot :) See attachment below.
(In reply to comment #15) > If you really want to see this happen, I would strongly recommend that you > put some effort into implementing a sample UI that is unobtrusive by default, > and yet presents a usable UI when expanded. Here's the mockup UI as promised, very unobtrusive (just a tiny more button), very usable (making all sorts of users happy), just re-combining existing UI from yellow star's popup panel and library's properties panel. Easy! The thing I haven't included yet is the backlink from star's popup to the library ("View bookmark in library"). But I reckon that can be dealt with separately. Comments and further ideas welcome.
Summary: can't access all bookmark properties from location bar star → Can't access all bookmark properties from location bar yellow star ("Edit this bookmark popup", cannot change Keyword, Description, Location)
Summary: Can't access all bookmark properties from location bar yellow star ("Edit this bookmark popup", cannot change Keyword, Description, Location) → Can't access all bookmark properties from location bar yellow star ("Edit this bookmark" popup, cannot change Keyword, Description, Location)
Here's another sample UI screenshot which now includes an "Open containing Folder in Library" button (icon size, next to the Folder widget). As proposed by comment #5 (option 2), and comment #10 (expected behaviour A, B.2), clicking the button will open the containing folder in the Library with the bookmark selected. The benefit of combining comment #5 's option 1 and 2, as proposed in comment #10, is obvious: 1) optional/scalable (expandable) in-place editing of /all/ bookmark properties without switching to the library 2) AND unobtrusive (icon-size) link to view the bookmark in its folder environment (compare with other bookmarks of same folder etc.) Having the button next to the folder widget is very intuitive, as user can see immediately which bookmark folder he is about to open. Similarly, Bug 469441 requests adding an "Open Containing Folder" button for bookmark search results (and Bug 469416 requests to add "Folder" widget to the search results properties pane). Therefore, I have proposed the same design for the search results properties panel in bug 469441, attachment 392021 [details] (folder widget + "Open Containing Folder" button next to it). Comments welcome.
My thoughts on some of the issues raised above: ==Bookmarks property dialog is missing the folder control== -I only think we should add this in when the user is viewing search results, since otherwise it is redundant (you can see the selected folder in the left pane). However when viewing search results the control is indeed useful and currently missing. ==Bookmarks contextual dialog is different from Properties dialog== Things that bug me about the current UI: 1) I don't like that we have too different windows that do mostly the same thing, and they are accessed in two different ways, and there isn't really any way to transition between them 2) Some advanced bookmark users are upset that they can't tear off the contextual dialog (speech bubble) to turn it into a real window. 3) Adding one more progressive disclosure control to the current UI really feels too heavy and bloated. It detracts from the relative discoverability of everything else in the window, and brings us a little bit closer to Netscape 8's "19 arrows" crazy town: http://people.mozilla.com/~faaborg/files/daf/moreArrows.png or Windows DDR: http://people.mozilla.com/~faaborg/files/daf/windowsDDR.jpg So what if we considered this approach: -The bookmarks contextual dialog keeps its current set of items (or perhaps even drops the folders entry), but it picks up a small glyph in the upper right that when clicked tears the dialog off of the star (and turns it into a real window). We might want to even support an actual click and drag tear off. -When torn off into a real window, the full set of properties are available, and everything is expanded by default. -We rename keyword to "search keyword" so it doesn't collide so directly with "tags" I think this would address a lot of the issues we have with the current UI while keeping things reasonably sleek.
I was thinking something like this, but probably smaller and lighter
Also adding something like alt-accelerator-D, and accel-D-D that would bookmark the page and go straight to the torn off properties window would probably make our advanced bookmark users happy (since the path of click on star, click again, expand to full view) isn't exactly streamlined.
(In reply to comment #19 ff.) Thanks, Alex, for your valuable feedback in the respective bugs. Expanding the contextual dialogue into a full properties window is an interesting new approach, I think I'll let that sink in a little before commenting. First thought: what's the benefit of properties window over contextual dialogue? Apparently the only difference is that the window sticks even when FF loses focus. Otherwise, I don't see any benefits of having the bulkier properties window, as it doesn't add any functionality (yet). Maybe that could be changed (brainstorming ideas): - by making the properties window behave more like Winword's "Find" dialogue, where you can defocus the dialogue to copy stuff from the underlying document, but the dialogue always stays on top. - by making the properties window resizable (I can't believe that it ain't yet) (In reply to comment #21) > since the path of "click on star, click again -> expand to full view" isn't > exactly streamlined That's right, but the assumed behaviour for my Sample UI 2 (attachment #392075 [details]) is different: Whatever state the user has chosen (expanded vs. reduced dialogue), it will be remembered for the next time the dialogue pops up, in the same way the library remembers the state. So there would be no need for extra accelerators. > ==Bookmarks property dialog is missing the folder control== > -I only think we should add this in when the user is viewing search results, > since otherwise it is redundant (you can see the selected folder in the left > pane). Indeed, the "folder control" widget is especially missing for search results. I don't think it would be redundant for non-search bookmarks in the side bar: - you're right, bookmark path is visible in the side bar, but it can be very hard to discover depending on how many bookmarks and subfolders are sitting in each of the subfolders along the path to the current bookmark. You might never see all of the nested hierarchy of your bookmark without scrolling back and forth. - for the same reason, moving a bookmark using drag'n'drop within the sidebar tree might be very difficult, whereas - it's much easier and safer to move a bookmark using "folder control": clean and compact folder hierarchy without any other bookmarks impeding view and action 6 out of 7 bookmark properties are already visible, it really won't hurt to have that single line for the folder control included and thus ALL properties accessible. > 1) I don't like that we have too different windows that do mostly the same > thing, and they are accessed in two different ways, "two different" OR "too different" OR PERHAPS "too many different" windows? What I forgot to include in my original screenshot of all the different "Edit this bookmark" variants in attachment 391221 [details] was a fourth variant that you get when doing "Add a keyword for this search" from the context menu of form fields. Surprise!!! - another dialgoue where users can't access all of that bookmark's properties because developers prescribe what the user should or shouldn't modify about a bookmark in a given situation. Each time I use this, I miss "Location" property to check out if the predefined search is actually what I want. Bottom line: As per the above quote, if you really want "less" different ways of doing the same thing, then try to *unify* the different dialogues. That will also make them easier to use, as they look more alike. For a start, always include "folder control" widget on the sidebar bookmark properties dialogue instead of hiding valuable functionality for the very fuzzy sake of "streamlining".
Generally speaking: "Exposing valuable functionality" might be an alternative approach to consider (vs. "streamlining"). Bug 261175 comment #4 puts it this way: > The reason more people don't use keyword shortcuts is because all of the > bookmark properties are not being exposed when creating a bookmark. Solve that > problem and bookmarks would be used a lot more powerfully by a lot more users.
I should point that discussions of this kind and size should either be put in a mozilla newsgroup or in a mozilla wiki/talk page. A bug does not look like the right place to discuss, rather it's the place to put final considerations once the discussion has come to an end. That said, i like the possibility to "detach" the panel, Alex if you think that's valuable we could create a sprint for it.
>"two different" OR "too different" OR PERHAPS "too many different" windows? I was thinking more "two windows which are too different" and no easy way to transition between them. Benefits of the tear off approach: -feels more like one interface that expands (but without more progressive disclosure controls) -we don't have to worry about the extra controls overlaying the page -moveable and resizable -users who want to move and resize probably also want to write a full description, etc. so one interface will solve all their needs. >- by making the properties window behave more like Winword's "Find" dialogue, >where you can defocus the dialogue to copy stuff from the underlying document, >but the dialogue always stays on top. yeah, this sound good >if you really want "less" different ways >of doing the same thing, then try to *unify* the different dialogues. The problem with totally unifying everything is that it produces a rather complex default UI that has low relative discoverability for each control (discoverability is a zero sum game, you can water it down by adding more). So I'm more interested in trying to link the interfaces in a logical way, and giving advanced users a path to total control without building in the assumption that everyone takes advantage of all functionality. >I should point that discussions of this kind and size should either be put in a >mozilla newsgroup or in a mozilla wiki/talk page. Yep I agree (mostly just brainstorming), I'll get a thread up on dev.apps.firefox so we can make a final decision on the most logical way to refactor the UI.
Whiteboard: has two UI proposals
Related bug 518423 has another use case in support of this bug: "Cannot use primary UI to add new bookmark for web pages with friendly URLs that are redirected". Implementing Alex' UI proposal of a non-obtrusive "expand to window" icon on star panel (tear-off-properties) would provide a basic fix for bug 518423, too (see comment #20, explained in comment #25, and welcomed by Marco in comment #24): After bookmarking with the star, user could edit the URL property to change the complex URL back into the friendly URL.
Depends on: 518423
xref Bug 524071 - Places UI (3.7): Bookmark contextual dialog should be detachable into a persistent sidebar While implementing bug 524071 will probably go a long way in helping to overcome the frustration of this bug, unfortunately it might be a lot less convenient as we'll be editing the bookmarks properties in the sidebar on the far left, which will be quite far away from the star. This bug here proposes a very similar UI, but with the comfort of in-place-editing.
Depends on: 524071
(In reply to comment #28) > Bug 524071 might be a lot less convenient as we'll be editing the bookmarks > properties in the sidebar on the far left Forget comment #28, bug 524071 currently suggests the sidebar *on the right*, which might actually be pretty cool if done right (e.g. drag stuff from the page into tags field etc.)
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
The right aligned sidebar proposed in bug 524071 would address properties like keyword, and description, but I'm not entirely sold on the idea of including location. This would (at least initially) be redundant with the information displayed in the location bar. And there is the consideration of what to do if the user edits the location, do we reload the content area so that it remains linked to the properties of the bookmark associated with it? This could result in potentially data loss since it is unexpected. Providing a location field for bookmarks being created by scratch is required (otherwise there would be no bookmark), and for bookmarks not currently be displayed (like on the bookmarks toolbar or in the library) it works fine. But for bookmarks that the user is currently viewing (star icon, right sidebar) allowing the user to edit the location it creates a lot of potential problems.
Alex, thanks for working on bug 524071 which looks great and promising so far! I realize it isn't easy to get the UI/behaviour right, as you explain in comment 31. I still hope we can find a way for this while minimizing the problems. Benefits of including "Location" in the (expanded) new properties side bar 1) provide an easy way of bookmarking friendly URLs like http://www.getfirefox.com (fix bug 518423: currently, there's no way to bookmark these from the primary UI) 2) provide an easy way of bookmarking main pages from sub pages (say you have navigated your way to http://www.mozilla.org/about/manifesto.en.html, realize "Mozilla rocks", click star to bookmark, but you really want to bookmark www.mozilla.org only); also: get rid of anchors after the fact 3) consistency with all other bookmark properties dialogues (see Alex's comment 31) 4) (optionally) avoid extra code and UI bloat of "more..." toggle (I know, perceptions of bloat tend to differ... ;) 5) don't reproduce the problem of this bug by leaving some properties out (again), thus making them inaccessible from star (or very hard to access) To evaluate the weight of such benefits, please try to perform the above actions _without_ having location property included in star panel (and without space-eating bookmarks sidebar). It's kinda hard and clumsy. PROPOSED UI (with regard to the potential problems mentioned by comment 31): Alternative 1 (always visible): -> Add Location to the main properties on the side bar (always visible) 1.1 benefits: - consistency of field order with other properties dialogues (memorability effect) - immediate easy access to all of the above benefits Alternative 2 (tucked away): -> If you implement the "more..." button anyway, you could easily tuck "location" away together with "keyword" and "always show in sidebar" (see the wicked keyword-hostile plan in Bug 524071, comment 13) 2.1 benefits: - only show location property for users who really want it, thus avoiding any potential problems for other users (and those who want it will definitely know how to handle it) - avoid URL duplication by default Addressing potential problems (both Alternative 1 and 2) P1) duplication of URL (location bar and property) - as such is only a cosmetic problem -> if it's bothering you, tuck it away under progressive disclosure P2) UI coherence problems after user has manually changed the location/URL property of a bookmark he is currently viewing. What do we do? -> I propose the following UI/behaviour: a) don't change location bar URL, don't change content area (would be unexpected, dataloss, agree with Alex's comment 31) b) toggle the star from yellow to white: - by deliberately changing the location of a bookmark, the user is actually removing the bookmark for the original location (original URL is no longer bookmarked) - This also visually indicates that the current properties panel does no longer belong to this URL! c) optionally (recommended), implement a small "go" button (green arrow) inside the Location property textbox, with same behaviour as in location bar: - initially, the go button will be hidden (avoid any clutter): Location: [http://www.mozilla.org/somepath ] - when user edits the Location, we show the small go button: Location: [http://www.mozilla.org/ ->] Enter after the new location will load it into content area -> benefits: - user has an intuitive and non-obtrusive contextual way of loading the edited URL into the content area (if he so chooses) - more indication that this URL is not currently shown in content area Actually, I don't see much of a problem with editing the Bookmark location URL while still showing the originally bookmarked page. Btw, *we already have exactly the same behaviour proposed here*: - load bookmark from bookmark's sidebar - open properties dialogue from that bookmark's context menu - edit Location/URL, confirm changes -> location bar URL and content area still show the original location -> yellow star turns white (as original location is no longer bookmarked) We can safely assume user knows what he is doing when deliberately editing the URL, and user will also see that the page in content area doesn't immediately change. No surprises here. Actually, we'd be even better as we'd turn off the star as soon as user edits URL, thus providing immediate visual feedback for this action. Ideally, implement c) so that user has easy way of loading the edited URL if he wants to.
Can we hope for any improvements on this problem and related bugs (e.g. bug 524071, bug 469441) for FF 3.7? FTR: Easy solutions like adding a contextual menu on the star (bug 506925) and/or a tiny "more" button to expand-on-demand the star's edit panel have been thrown out by developers for dubious reasons. Allegedly better (and much more complex) solutions like bookmark properties sidebar (bug 524071) have been started, but now pronounced "sleeping" (bug 529610, comment 1). Another 6 months later, and users are still suffering from these ridiculous problems that could be fixed with a couple of lines without doing any harm whatsoever. Another sad example where the perfect is the enemy of the good. Isn't it a bit strange that we're planning for big UI changes like "tabs on top" and everything, while basic functionality is missing? I do understand that there are other things to prioritize, but then why be so dogmatic about the smaller changes that would eliminate these problems at a low cost? Especially, bug 506925 should be reopened, as it simply defies all logic how NOT having a no-cost workaround provided by the proposed contextual menu on the star could ever be better than HAVING a reasonable, non-intrusive workaround. The star is THE bookmark object, and any kind of objects have contextual menus (even the back-button). Often, contextual menus provide a shortcut to functionality that's not otherwise available *in-place* from the primary UI. Which is exactly the case of this bug. I really fail to understand in what respect the bookmark star object could be so different from the rest of the UI that it is deliberately being denied a contextual menu.
Depends on: 506925
See Also: → 469441
Depends on: 262640
Priority: P5 → --
keywords and description have different plans for the future, and there's no plan to allow editing the url from the star panel. So this is now a wontfix. Further plans will happen when UX has a new design.
Status: NEW → RESOLVED
Closed: 17 years ago → 7 years ago
Resolution: --- → WONTFIX

I've converted to Firefox for much of my workflow, and I've really enjoyed some of the features surrounding bookmarks, tags, keywords, etc. However, the fact that this UI / UX issue has been brought up long ago and still hasn't been addressed, even with an extremely simple "view full edit dialogue" button in the star menu is ridiculous. It's a very sore UX point that I constantly keep running into and literally any of a hundred options would do a lot to at least partially alleviate the problem.

I'd like to know if this can be reconsidered and reopened, because 3 years later there's still no changes and no UX redesign.

Flags: needinfo?(mak)

(In reply to mail from comment #36)

However, the fact that this UI / UX issue has been brought up long ago and still hasn't been addressed, even with an extremely simple "view full edit dialogue" button in the star menu is ridiculous. It's a very sore UX point that I constantly keep running into and literally any of a hundred options would do a lot to at least partially alleviate the problem.

I'd like to know if this can be reconsidered and reopened, because 3 years later there's still no changes and no UX redesign.

At this stage, the description field has been removed, and we are actively working at the moment to change how keywords are handled.

The only thing a full edit dialogue would give over the current one would be the ability to edit the URL. However, I think we believe that editing the URL is a rare case, and is also a case that we definitely haven't had many requests for in the last few years. I don't think it would be worth adding an extra field or a way to get the full edit dialog.

Flags: needinfo?(mak)

(In reply to Mark Banner (:standard8) from comment #37)

(In reply to mail from comment #36)

However, the fact that this UI / UX issue has been brought up long ago and still hasn't been addressed, even with an extremely simple "view full edit dialogue" button in the star menu is ridiculous. It's a very sore UX point that I constantly keep running into and literally any of a hundred options would do a lot to at least partially alleviate the problem.

I'd like to know if this can be reconsidered and reopened, because 3 years later there's still no changes and no UX redesign.

At this stage, the description field has been removed, and we are actively working at the moment to change how keywords are handled.

The only thing a full edit dialogue would give over the current one would be the ability to edit the URL. However, I think we believe that editing the URL is a rare case, and is also a case that we definitely haven't had many requests for in the last few years. I don't think it would be worth adding an extra field or a way to get the full edit dialog.

I find that editing the URL of a new bookmark tends to be a very common case for myself. Usually when you add a URL that contains some garbage query parameters at the end and I want to clean it up before I save it. As for editing keywords, I find myself constantly aching for a quicker way to check or modify the keyword for a bookmark.

Typically, the situation goes like this: I want to go to X page, which I know I have bookmarked. I start typing it in, it maybe pops up, I arrow key down the the correct result, and press enter. Once I am on the page, I realize this is a bookmark I look for often, and I have an idea for a keyword I'd like to use next time. I click the star so I can quickly add the keyword for myself to use next time, then get back to my original task, but oh wait! I can't edit it there. If I want to add my keyword, I have to go to Bookmarks -> Show All Bookmarks -> find the bookmark in question -> edit the keyword field -> close dialogue -> and then now I can get back on task.

It just seems like such an overly complex UX flow to use a very useful feature, and it totally derails my current task when I have to remember how to navigate to the keyword field in order to utilize it. It almost feels like the browser is actively discouraging me from using keywords by making it a hassle to navigate to.

What do you expect users to do? Open up bookmarks, and then go through and all the keywords they can think of to a bunch of their bookmarks at once? I feel like the major power in keywords is that I can recognize "I wanted to go to X page, and I started typing 'abcde' before I found it. I am going to try making that the keyword and see if it is useful for the next time I want to go there, so that I can quickly type 'abcde' and then press enter without thinking twice. Much faster. Much more efficient. And if it ends up not working out or being memorable or getting in the way of typing something else, I can easily change the keyword to something else." But that's not the story I'm able to tell. Instead, it's a hassle to get in and get out.

(In reply to Mark Banner (:standard8) from comment #37)

The only thing a full edit dialogue would give over the current one would be the ability to edit the URL. However, I think we believe that editing the URL is a rare case, and is also a case that we definitely haven't had many requests for in the last few years. I don't think it would be worth adding an extra field or a way to get the full edit dialog.

I'm here due to two recent SUMO threads:

In both cases, contributors suggested using userChrome.css rules to override the rules for [collapsed="true"] on #editBMPanel_locationRow -- it is present in the dialog but not displayed.

(The keyword field also is there as #editBMPanel_keywordRow and it can be used to save a new keyword, but it doesn't populate with the current keyword in the editing scenario, so it gives misleading results (blank or unrelated keyword) in that case.)

If editing location and keywords is truly an advanced scenario, then this might be considered a tolerable workaround for the time being, but there's always a risk these hidden fields will get removed if no one knows they are being used.

Perhaps brooksvb should open a new RFE bug? I know that development resources are in short supply and UI needs to weigh in, so it's not likely to change swiftly. (I would favor a design where advanced fields are toggled on demand by a checkbox/More button that flips the collapsed attribute and runs any code needed to populate correct data. It doesn't seem there needs to be a preference to default this, although it could be tedious having an extra click for some use cases.)

I note the request was declined in the past -- https://bugzilla.mozilla.org/show_bug.cgi?id=262640#c25 -- but there is a parity-chrome argument as to the location field at least.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: