Closed Bug 19922 Opened 25 years ago Closed 22 years ago

RFE: on-demand editing of title while d&d url to bookmarks (drag and drop)

Categories

(SeaMonkey :: General, enhancement, P3)

Product:
SeaMonkey
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 159844

People

(Reporter: sidr, Assigned: mpt)

References

Details

(Keywords: helpwanted) 

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.
Assignee: shuang → german
re-assign it to german who is responsible for bookmark UI behavior design.
Status: NEW → ASSIGNED
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?
Target Milestone: M16
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.
Component: UE/UI → User Interface: Design Feedback
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.
Target Milestone: M16 → M20
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.
Assignee: german → ben
Status: ASSIGNED → NEW
>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...
QA Contact: claudius → zach
This is fixed now, I think.
I'd say this was fixed in bug 47599.

*** This bug has been marked as a duplicate of 47599 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Depends on: 53707
Keywords: helpwanted
QA Contact: zach → claudius
Resolution: DUPLICATE → ---
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"
Summary: RFE: a way to add/edit page title *while* filing bookmark (implementation suggestion) → RFE: dialog to edit bookmark title after right-dragging (or control-dragging) page proxy to bookmark button or sideba
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
Assignee: ben → mpt
Status: REOPENED → NEW
QA Contact: claudius → zach
> 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).
Depends on: 25742
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 timeless@mac.com 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)
Depends on: 18052
Summary: RFE: dialog to edit bookmark title after right-dragging (or control-dragging) page proxy to bookmark button or sideba → RFE: on-demand editing of title while d&d url to bookmarks (drag and drop)
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → DUPLICATE
No longer depends on: 25742
Component: User Interface Design → Browser-General
verified duplicate
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.