Overview: If the location bar "page proxy" icon were dragged to the folder where it is to be filed with a right mouse button drag rather than a left, the "Bookmark Properties" dialog could pop up immediately - this would be useful in those cases where the page title does not exist (text/plain, binaries, PDF files, etc), meaningless (identical titles across an entire site) or dys-usable ("Welcome to Company XYZ - meaningful part of title"), to allow a useful title to be provided by the user *while filing* - the most natural time to do so. On the Mac this would require a keyboard modifier with the mouse drag, as there is no right mouse button - this shouldn't be a problem: there is nothing else a keyboard modifier would be used for at that time. This enhacement could be done in conjunction with that proposed in bug 19437, "Move and remove (or edit) bookmarks inline" or it could be done independantly.
re-assign it to german who is responsible for bookmark UI behavior design.
Inline editing of the name will be available once the Bookmarks button displays lists and accepts drag ins properly. It will even allow dragging around items. Inline editing of names will also be supported later in the Manage Bookmarks... window. Does this cover your needs?
This RFE is post-beta in priority for certain, but no, as cool as inline editing of the bookmark name will be, it does not address the main UE aspect of this proposal: not needing to go back to edit the name of a bookmark, but filing it with a user-specified reasonable name in the first place. Many people file bookmarks quickly on the fly as they find useful sites and pages and then go back later and organize them. With Nav 4.7, that means bringing up the "Bookmark Properties" menu for bookmarks one-by-one to look at the URL for clues, or viewing the page, to create an appropriate name for bookmarks with nonexistent or uninformative names. Often this is done when the user wants to *use* a bookmark, not find out which un-named bookmark is the correct one. Others try to file bookmarks into organized folders so they can be found the next day without having to periodically go back to organize them, but this is defeated if the <title> contents are nonexistent or uninformative. The proposal would let those who want to make bookmarks usable as soon as filed do so, even if the <title> is no help. I suspect that most people, most of the time, will not open "Manage Bookmarks" to fix up one bookmark immediatly after filing it.
I like the idea of context dragging (i.e. right-mouse drag on win32, ctrl-drag on mac) as way to force the BM properties dialog. Going further we could also bring up that properties dialog (even without context drag) with a 'untitled' pre-filled when the page to be bookmarked has no <title>. I also want to make sure you understand that we will have this inline editing ability when dragging bookmarks onto the bookmarks quick access item in the personal toolbar (currently it's just a folder that pops open), users do not have to go "manage bookmarks" for that. In fact the item should be selected and in view once it is dropped into the bookmarks list, so the name could be easily changed. Probably like you I want to avoid having to show that props dialog -every- time the user files a bookmark.
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
cc' ing rjc. rjc: based on what you just did for bug 20155 can any of that be used for this RFE?
*** Bug 35139 has been marked as a duplicate of this bug. ***
Move to M20 for after PR2 consideration.
I still like the idea! But we will likely need help on this. From what I have seen in terms of end users in the usability lab, most of the even intermediate users have a hard time finding bookmarks after they have been filed using "Add Bookmark", especially if their BM folder is already crowded from bringing all the 4.x and IE stuff. So here is a proposal for the UI: - when a bookmark is added using drag and drop use context dragging to force the bm properties dialog as spec'd by the reporter. Mac would use the control key while dragging. - when a bookmark is added via Add Current Page... we should show an extended bookmark propoerties page with the addition of a popup menu on top that shows the hierarchy of folders when popped open (much like the "File" button in mail.
I propose reassigning this bug to ben, the mozilla UI owner, so he can add this to his 'ongoing discussions bin' . I am still supportive of this idea as a bookmark filing/management UI is pretty bare bones right now and could use some beefing up.
>when a bookmark is added using drag and drop use context dragging to force >the bm properties dialog as spec'd by the reporter. Mac would use the control >key while dragging. Unless I'm missing something, this depends on bug 53707 ("rfe: dragging a link onto bookmarks button should open menu"), and also depends on bug 49844 ("context menus display on button up instead of down") *not* being fixed. It also doesn't sound like a very easy-to-find feature. >when a bookmark is added via Add Current Page... we should show an extended >bookmark propoerties page with the addition of a popup menu on top that shows >the hierarchy of folders when popped open (much like the "File" button in mail) I agree. This is also being discussed in bug 47599 ("bookmarks: make 'Add current page' more useful").
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
This is fixed now, I think.
With respect, this bug is in no way a DUP of bug 47599, "Bookmarks - make 'Add current page' more useful (radar: Add Bookmark window)". I like the fix for 47599, and it will serve some users well, but it does not cover the same territory. 1. That bug is about "Add current Page..." bookmark adding, while this bug is about drag-n-drop bookmark adding. 2. That bug is standalone, while this bug depends on bug 53730, as noted above. 3. That bug give the opportunity to change the title at the cost of always dealing with a dialog (unless it has been permanantly dismissed, in which case the only way to get it back is to go into the prefs), whereas this bug brings up an equivalent pref (except for the positioning part, which is accomplished by dropping in the right spot in the tree/tree-menu) *only* when the user chooses, by right- (or control-) dragging. Point one is a fundamental difference; point 2 is a downright incompatibility; The essential character of this RFE, as noted in point 3, is not supported by the fix for bug 47599 -- the user cannot, at bookmark-filing time, while browser.bookmarks.add_without_dialog is true, selectively invoke a dialog to edit the title. REOPENing; adding helpwanted keyword; changing QA contact to Bookmarks QA.
My bad; should have edited Summary as well, much earlier, and certainly in the last comment, to highlight the specific feature requested, as distinguished from other features ;-|. From: "RFE: a way to add/edit page title *while* filing bookmark (implementation suggestion)" To: "RFE: dialog to edit bookmark title after right-dragging (or control-dragging) page proxy to bookmark button or sidebar"
suggest wontfix. drag and drop is not supposed to let you do inline changes, it doesn't fit w/ the concept. * you could use the ... dialog and select a title * once you've dropped it you can right click and choose rename. * bookmarks might be f2 or single click or hover rename-able
> suggest wontfix Suggest otherwise, for all the reasons given below. If bug 53707, "RFE: dragging a link onto bookmarks button should open menu" is resolved wontfix, then this rfe will die on the vine, but otherwise, this rfe adds functionality otherwise unavailable to those whose habit is to file bookmarks in that manner. There's no hurry to resolve this bug so long as the fate of 53707 is up in the air. > drag and drop is not supposed to let you do inline changes, it > doesn't fit w/ the concept. On Win32, a right-dragged file dropped onto the desktop or an explorer window brings up the equivalent of a context menu to let you choose between copying to, moving to, or creating a shortcut (alias) at, the new location. In the parlance, we're talking about a context-drag; the context of a newly positioned bookmark has got to be roughly the same as the context of an existing bookmark, less options that make no sense at the time (Delete, Open in New Window, etc.). In fact, the only things that one might want to do to a brand new bookmark before turning attention elsewhere would be to edit/add the title, and possibly to add a comment. There's a reason this bug depends on bug 53707, "RFE: dragging a link onto bookmarks button should open menu": there hasn't been a better UI designed for quickly filing a bookmark to exactly the (pre-existing) folder than dragging the page proxy to that folder in the cascading view (*1) of the bookmarks available from the [Bookmarks] button on the Location toolbar or a folder on the Personal toolbar in NN 4.x. Get it done, get out of there, get on with it. (*2) Mozilla 1.0 shipping without that feature will be a crying shame. Neither the Bookmarks menu on the menubar nor the Bookmarks sidebar, let alone the Manage Bookmarks window, give that "get it done and over with" feeling on Windows (although the Bookmarks menu might for Mac users). Also, those, like me, who want to file bookmarks with the least possible distraction from the page at hand, just won't leave browser.bookmarks.add_without_dialog off. So: > * you could use the ... dialog and select a title Not if I don't want to see the dialog every time, I couldn't. (OK, the dialog could be extended with a section for exceptions, like so: +-- Except -----------------------------------------+ | [x] if the title is blank | | [x] if the title is the same as the previous page | | [x] if the title starts with "Welcome" | +---------------------------------------------------+ ... but then I'd expect the same dialog to appear, less the positioning section, upon dropping a page into the Bookmarks sidebar too. > * once you've dropped it you can right click and choose rename. Not if it isn't in sight, which is the case for every method of adding or filing a bookmark except the Bookmarks sidebar. Nobody who values their own time will want to re-navigate a folder tree in the sidebar or Manage Bookmarks menu to re-title a new bookmark immediately after navigating the tree to place it! > * bookmarks might be f2 or single click or hover rename-able Well yes, certainly, and they should, but that's no help if a fresh bookmark is out of view. Not everyone has the screen real-estate to keep the sidebar open, or open enough to get a good view of bookmark titles. (*1)The cascading view of the bookmarks is normally called a cascading menu, but that's an accident of available widgetry. The bookmarks are conceptually arranged in a tree; the Manage Bookmarks window ( & sidebar), the Cascading view, and bookmark.htm give three different (each limited) views on a tree- database. The cascading view may well be better implemented with the Outliner, so long as the twisties can be made to do their thing on a (very short) hover instead of a click. Context-dropping (and for that matter, context menus (see bug 50504, "Context menu for bookmarks menus")) would be far more natural on an outliner item than on a menu item. Auto-twisties would be great in the bookmarks pane in the sidebar, too -- time to file a couple of new RFEs. (*2) The only deficiency of the drag-n-drop of the page proxy to the cascading bookmarks view available from the toolbars is a corrolary of its great advantage, that it gets out of the way, immediately: once a bookmark is filed, it's out of sight, and there's no way to get back to it easily and quickly to make any adjustment to the title. Hence, this RFE: a way to signal the desire to make an adjustment *as* the bookmark is filed, rather than later.
Yes the w32 right drag context menu has 3 items + sep + cancel. copy move and shortcut. That is _NOTHING_ like what you want. ctrl-b already gives you the dialog you want. abusing right dragging is inappropriate. If you're complaining that the menu system doesn't let you sort by date added so that any item you add appears at the _top_ of the folder, then please file a bug for that instead. Please try using the add bookmark dialog before responding again w/ this foolishness.
I like IE's solution: leaving the menu open after you drag something into it. That way, you can be sure you put it in the right place, and you can right- click it to rename it. For that to work in Mozilla, we'd also have to add context menus in the bookmarks menu (bug 50504).
Going back to a feature-specific summary, from "RFE: dialog to edit bookmark title after right-dragging (or control-dragging) page proxy to bookmark button or sidebar" to "RFE: on-demand editing of title while d&d url to bookmarks (drag and drop)" ...the specific implementation does not really matter so long as the feature enables *that*. Adding dependency that should have been here from the start: bug 18052, "RFE: Ability to D&D the URL Icon into the bookmarks menu or submenu (drag and drop) (page proxy)". This RFE is specifically for an enhancement to that 4xp feature, so that those who prefer to place a new bookmark at an exact position within a specific folder, in a single drag-and-drop, can edit the title of a bookmark when desired without having to switch to one of the multi-step methods of filing a bookmark or go back and find it afterwards to do the edit. The exact implementation of the feature requested here does not matter so long as it fits within the framework of the feature described in bug 18052. Would having CTRL or SHIFT depressed at the time the drag is dropped be a suitable trigger for bringing up a title-editing dialog, or would that bring up the same objections? If the latter, please explain the objection in bug 25742. The only other implementation I've thought of would also be a bastard child of drag-and-drop and context menus: bring up the dialog immediately after the release if the user hovered in that final drop position for more than one second -- but that could get triggered accidentally. And yes, I have tried the Add Bookmark dialog. Aside from being slower, taking multiple steps, and not letting the user see the contents of one or more folders before filing a bookmark, it does not allow the new bookmark to be placed exactly where desired in the folder. For that reason, if none other, it cannot properly substitute for any drag-and-drop method of filing a bookmark. Here's the complementary question: Timeless, have you used the drag-and-drop bookmark-filing feature in 4.x that this RFE would enhance? I have better reasons that pigheadedness or inertia for preferring to work that way, but I suspect that someone who has never used that feature may not understand the degree of its superiority for some users, and how clunky any other method feels, when occasionally used, compared to it. Quoting from above: > ------- Additional Comments From firstname.lastname@example.org 2001-03-24 21:58 ------- > ... drag and drop is not supposed to let you do inline changes, it > doesn't fit w/ the concept. If I understand correctly, what you are saying is based on the atomicity of drag-and-drop: the same thing is dropped that was dragged, always. I agree with that much. In this case, I'd expect that if Mozilla crashed before the title was edited, the new bookmark would still get put in the chosen position with its original title. In other words, to the user this feature would feel like editing while filing, but in fact the dialog would only appear immediately after the bookmark was filed. Yes, this RFE does differ from the win32 Explorer context-drag: (a) Since there is only one action that would be on the context menu besides the default "Add bookmark Here", the context menu itself would be elided (b) The dragged object would always be put where it was dropped before the user was prompted ... and the choices would not include Cancel. (c) The user can always tell what the default action is, so the context-drag would only ever get used for the alternate action (yeah, cheap shot)
yes [imo] drag and drop is an atomic operation. Yes I have used nc4's drag and drop. Someone somewhere (i think it's the other bug) suggsted that when we finish a drag, we keep the destination open, doing that would allow the user to right click and select rename or properties. Would this be sufficient?
I agree with timeless. Marking as a dup of a later bug because this bug has many comments not related to the problem, which is that the bookmarks menu does not stay open after a drag. *** This bug has been marked as a duplicate of 159844 ***