Closed Bug 89001 Opened 23 years ago Closed 14 years ago

File Bookmark Dialog should take keyword, comment, etc

Categories

(SeaMonkey :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 605788

People

(Reporter: izel, Assigned: vdvo)

References

Details

(Whiteboard: [patchlove: comment 37-38])

Attachments

(1 file, 1 obsolete file)

When a user chooses to "File a Bookmark", he is given the option to
specifiy/modify the URL, specify/modify the name for the bookmark, and
specify/modify under which directory it should be filed.

But when a user goes into the bookmark manager, right-clicks a bookmark, and
chooses Properties, he is offered Bookmark, Name, Keyword and Comments entry
fields under the Info tab.

It is inconvenient for a user to have to go into the bookmark manager every time
he wants to associate a keyword with, or add some comments about, a website. A
user should be allowed to enter all relevant information about a bookmark the
first time he files it.

Namely, the Add Bookmark dialog box (that comes up when a user chooses Bookmarks
/ File Bookmark) should have the Keyword and Comments entry fields in addition
to all the others.
This is not the same as bug 82721, which deals with an underlying API.  It is
presumably blocked by that, though.

Clarifying the summary, marking NEW.
Status: UNCONFIRMED → NEW
Depends on: 82721
Ever confirmed: true
Summary: The Add Bookmark Dialog Box Does not Allow User to Enter All Relevant Information → [RFE] File Bookmark Dialog should take keyword, comment, etc
arg. i'm still opposed to this.  The file bookmark dialog is for _filing_ a 
bookmark, not creating one.  if you want to create a bookmark then you should 
use the bookmarks window, pick where you want to put the bookmark, select new 
bookmark and use that dialog.  If you need a url, you can copy it or drag and 
drop it.
Um, not quite.  When you use the File Bookmark dialog, you're creating a 
bookmark.

Note that it was once called "Add Bookmark As...", but only the wording -- not 
the dialog -- changed.
*** Bug 93059 has been marked as a duplicate of this bug. ***
the suggestion from the dupe was to use a button (maybe just a triangle) to show/hide the extra
properties. I concur. This widget would then of course remember state and be unobtrusive for those who don't
use it and a godsend for those of us tired of having to fire up the manager to add in properties for a
bookmark they just _created_.

Also, this would be great eyeballs for custom keywords - my favorite underpublicized feature.
*** Bug 101288 has been marked as a duplicate of this bug. ***
Nah. You don't typically want to create these entries for all bookmarks, so 
adding fields to this dialog is just adding clutter. 
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Why shouldn't I "typically want to create the entries"? Especially comment or
keywords are important exactly when I _create_ the bookmark!!! Why should we
force all users, who don't want to classify their bookmarks 2 or 3 days later,
to first "file" the bookmark and then to go to the bookmark-manager and search
their new bookmark and then right click the bookmark and then - finally - allow
them to enter their comments and keywords??? From the users point of view this
behaviour is not really user-friendly - it's time-consuming!

Also the hint "if you want to add a bookmark then use the bookmark-window" is
not very useful because the proposed way needs 5 (five!) clicks to add a new
bookmark - and then the user still has not been allowed to add comments or
keywords to the bookmark...

Once again: we should provide two ways to add bookmarks

1) like before a one or two-click solution to simply append a bookmark to the
bookmark-list (perhaps one can allow in the preferences for a default-folder
where "Add Bookmark" appends the new url)

2) a solution where the user can specify the folder the new bookmark should be
added - including all relevant properties related to bookmarks which the user
might want to enter - and comments or keywords are such relevant properties - of
course _not_ for all users - but even if only 10% uses this feature we should
provide them with an "easy to use"-solution...


I'm reopening this bug. Ben, I really think you should reconsider this. Bookmark
keywords is one of the coolest features of Mozilla, but having to *first* file
the bookmark and *then* opening another dialog to add the keyword - that's terrible!
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I forgot to say that this has been requested in netscape.public.mozilla.wishlist
several times.
jonas thanks! This somehow got resolved as wontfix when I wasn't looking.

It is my professional opinion that Ben is just wrong :-). I want a disclosure
triangle. I want it defaulted open, and I want it to remember state.
OK. Fair enough. 
Assignee: ben → pchen
Status: REOPENED → NEW
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 121535 has been marked as a duplicate of this bug. ***
*** Bug 134299 has been marked as a duplicate of this bug. ***
Any activity here?  This bug hasn't been active in a long time and I think it is
really important.
*** Bug 136012 has been marked as a duplicate of this bug. ***
putting on radar for point release.
Target Milestone: Future → mozilla1.2alpha
His would be a nice advertizement for "keywords" - once people see it, they'll
want it (BAD). I miss having the option of adding a KW and comment *very* often.
*** Bug 159519 has been marked as a duplicate of this bug. ***
If you add URLs to dmoz.org, the spider grabs the description from the meta tag.
It would be very nice if mozilla also prefilled the description field from the
meta tags if one chooses "File Bookmark...".
Jens: If you're interested in that, file a new request for enhancement. Your
suggestion has nothing to do with this one.
Has there been any recent activity on this ?

The target milestone is showing as 1.2 alpha, but I'm using 1.2a (2002091014)
and the rfe has not been implemented.
Summary: [RFE] File Bookmark Dialog should take keyword, comment, etc → File Bookmark Dialog should take keyword, comment, etc
 The lack of this feature was just criticised in PC Pro (UK) magazine (sorry,
not available online yet). Bad publicity in a piece that was otherwise quite
positive about Mozilla's bookmark manager and search features. 

 Here is the quote: "Unfortunately, to make searching work properly, [Moz] still
requires a convoluted process of entering the necessary information when adding
a bookmark in the first place. The process involves dragging the URL to a
location or using a Ctrl-D shortcut, which adds the URL only and doesn't tag it
properly with the kind of metadata needed to make searching effective. To do
that you need to right-click the entry and enter its Properties dialog. Okay,
it's not the end of the world, but it does add an unnecessary set of steps to
the bookmarking process, all too often leading to an unsorted jumble." (PC Pro
magazine no 101, cover date March 2003).

 So he hasn't noticed "File bookmark", but the same two-step process would apply
even if he had. Please fix this.
The target milestone was missed long ago. Nominating for nsbeta1. Bug 99860 is
scheduled for 1.4alpha, would be nice if this one could go with it.
Keywords: nsbeta1
OS: other → All
Hardware: PC → All
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
After the checkin of the big patch of bug 196756, the File Bookmark dialog now
has a Keyword field. The Description field is still missing, but since the
blocking bug is fixed, adding this should be next to trivial. (I'm not implying
anything by that statement - this is just a status report.)
*** Bug 209034 has been marked as a duplicate of this bug. ***
Attached patch patch to add description field (obsolete) — Splinter Review
Here's a patch that adds the Description field into the File Bookmark dialog. I
did attempt to make the Keywords and Description show by clicking on a
disclosure triangle as comment 11 requests, but I just couldn't find out how to
do it. I also didn't find any place in Mozilla that uses such a thing, so I had
nowhere to copy from.
Comment on attachment 136137 [details] [diff] [review]
patch to add description field

Requesting r&sr.
BTW, this also fixes bug 226002.
Attachment #136137 - Flags: superreview?(jag)
Attachment #136137 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 136137 [details] [diff] [review]
patch to add description field

>+<!ENTITY description.label          "Description:">
>+<!ENTITY description.accesskey      "E">
> <!ENTITY newFolder.label            "New Folder...">
>-<!ENTITY newFolder.accesskey        "w">
>+<!ENTITY newFolder.accesskey        "W">

Better use the case of the letter the accesskey should match. Otherwise the
respective string is scanned for the desired letter two times. See

http://www.mozilla.org/projects/ui/accessibility/accesskey.html

The first point of the section "How do I pick an accesskey letter?".
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Status: ASSIGNED → NEW
(In reply to comment #30)
> (From update of attachment 136137 [details] [diff] [review])
> Requesting r&sr.
> BTW, this also fixes bug 226002.

Please look bug #226002 has been marked as duplicate of the bug #228762 which
was fixed. So patch in attachment 136137 [details] [diff] [review] is obsolete now, you should create new
(just remove one fix in xpfe/components/bookmarks/resources/addBookmark.xul

-          <label value="&shortcutURL.label;"
accesskey="&shortcutURL.accesskey;" control="shortcutURL"/>
+          <label value="&shortcutURL.label;"
accesskey="&shortcutURL.accesskey;" control="shortcutUrl"/>
)
Attached patch updated patchSplinter Review
Assignee: ben_seamonkey → vdvo
Attachment #136137 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #143926 - Flags: superreview?(jag)
Attachment #143926 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #136137 - Flags: superreview?(jag)
Attachment #136137 - Flags: review?(neil.parkwaycc.co.uk)
*** Bug 242834 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
(In reply to comment #34)
> Created an attachment (id=143926) [edit]
> updated patch

patch waiting for review
QA Contact: claudius → bookmarks
Comment on attachment 143926 [details] [diff] [review]
updated patch

>+  gFld_Description.disabled = gCB_AddGroup.checked;
This line prevents you from actually entering a description for the bookmark group. r=me with it removed.

>+<!ENTITY description.label          "Description:">
>+<!ENTITY description.accesskey      "e">
> <!ENTITY destination.label          "Destination:">
> <!ENTITY destination.accesskey      "D">
Odd that we don't actually use that D access key... maybe we should use it for description as nobody will be expecting it to access the destination anyway.
Attachment #143926 - Flags: review?(neil.parkwaycc.co.uk) → review+
I'm afraid that I won't be able to spend any time in the foreseeable future updating the patch, un-bitrotting it and chasing someone to actually check it in. If anyone's interested, please feel free to take over.
*** Bug 326438 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → ---
The lack of this is very obvious in FF 3.0b1.  The fact that the main bookmark dialog doesn't include all the necessary fields means that bookmarks in the "All Bookmarks" folder aren't useful, since they can't easily be maintained any other way.
Jag, ping ?
Attachment #143926 - Flags: superreview?(jag)
Whiteboard: [patchlove: comment 37-38]
Fixed in:
Bug 586947 - Places File Bookmark (Ctrl+D) needs improvement badly
Status: ASSIGNED → RESOLVED
Closed: 23 years ago14 years ago
Resolution: --- → WORKSFORME
(In reply to comment #42)
> Fixed in:
> Bug 586947 - Places File Bookmark (Ctrl+D) needs improvement badly

No it's not fied. Latest comment on that in bug 586947:

(In reply to bug 586947, comment 44)
> > Description and keyword fields are missing.
> Lets get this bug landed and decide on those fields in a followup bug. Neil has
> enough problems reviewing the current patches.

Please REOPEN
Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: