110313 - proposal for elegant selecting/searching bookmark folders for storing/selecting bookmarks

Status: RESOLVED EXPIRED

(SeaMonkey :: Bookmarks & History, enhancement)

Description

[André Langhorst]

build: n/a
os: n/a
repro: yes

the "add bookmark" dialogue is uncomfortable dealing with many folders.

I have many folders and I always add bookmarks to the new bookmarks folder and
have to sort them all 2 to 3 month and that's a pain in the ass. It would be
nice to sort them immediately, but mozilla does not support a nice kind of
interface.

A folder hashtable is needed and a search form for the user. The user starts to
enter the folder name and mozilla displays a number (only the number) of
matching folders having that substring ang in their name. As the user is
comfortable with a comfortable low number of folders (eg. 6) he clicks somewhere
(eg. "display matches") and the matching 6 ones are displayed, the user selects
one and should be able to
a) show the tree somehow: there may be several equally named folders, eg. as a
tool-tip on mouse over (eg. Personal Toolbar/Hardware/MP3 Players/)
b) jump to the tree (decollapsed to that degree of course ) to consider storing
it immediately, in another related folder or to create a new one to store it there

rough guess what needs to be done:
- hash table (may be already there for other searching purposes)
- calculation for substring matches
- small gui additions (maybe below "Default folder" there would be enough space
estimating that folder names usually are not bigger than 10 to 14 chars and even
if they are there is the tool-tip full tree path feature :) )
- display the search results in the box (code may be stolen from the search
component) as long as the "search match" isn't changed
- display the full path in a tooltip

that finally would make using bookmarks more comfortable, this dialogue would
not only be practical for adding bookmarks, searching folders and/or bookmarks
in general this way is pretty straightforward (compare to the PIM/information
manager "Info select", it's pretty cool and uses a graphical sort of display)

*sending-hopes*

Comment 1

[André Langhorst]

adding mail3
adding polish (guys I am not sure about this one, but it *seems* to be not the
risky/complicated)

Comment 2

[André Langhorst]

removing mail3 (sorry I mixed it up with another bug I am going to file in a few
seconds)

Comment 3

[Paul Chen]

reassigning to marlon for UE comments on this proposal

Comment 4

[marlon bishop]

this is a great idea. it is my personal vendetta to make bookmarking more
usable, and we've been talking about a top down reassessment of bookmarking as a
feature.  i think this idea is going to be something we will want to work into
an upcoming bookmarking redesign.  and i'm pushing to have a redesign project
sometime in the mach V timeframe.

Comment 5

[marlon bishop]

pushing to 1.0.1

Comment 6

[Hunter Peress]

ok,I have another addition. 

If you've ever used galeon, u'll notice that when browsing the bookmarks (either
directly from the menu, or in the toolbar (obvsiouly im not talking about in the
bookmark manager itself) you can add bookmark to any folder.

EG: just dropdown the bookmark menu, navigate, and if you release the mouse on a
folder, it lets you add the current page to that folder.

note, you should have the same functionality with the folders/sub-folders that
exist in the personal toolbar.

THIS IS ESSENTIAL !!! it saves so much time and effort.

Whoever is watching this bug, reply below, and since im on the cc list, i'll be
 notified that you have indeed recognized my request. 

Comment 7

[Hunter Peress]

just updating as it was not met for 1.0.1

Comment 8

[imran.geriskovan]

"Bookmark search" should also return matching folders.

Comment 9

[Pascal THIVENT]

It would be really nice to be able to Open the Folder That Contains a bookmark
after a search. 

This feature is *very* usefull for easy bookmarks management.

Comment 10

[j]

I still maintain, and have complained several times in the newsgroups, that moz
bookmark function has multiple problems that go *backward* from NS 4.8.  In one
of these messages [news://news.mozilla.org:119/c1dfup$[e-mail]],
I indicated the following bookmark-specific items:  "Other items that went
backward from NS 4.x include removal of 'insert separator' from the right-click
context menu in bookmarks manager, the scrolling format of bookmarks in a large
file, vs. the multi-column wide view [*much* superior, IMO],".  In a later post,
someone else wrote:  "I also have accumulated a large bookmarks file, and really
miss Netscape 4's ability to search (find) withIN the bookmarks window -- IOW
just advance to and select the (next) matching bookmark within the (context of
all the) other bookmarks. "  I also agree with this assessment.  Finally, in a
yet later article [news://news.mozilla.org:119/c2au3h$[e-mail]]
I indicated some additional problems: "1.    Even for  the toolbar folders into
which I can drag/drop links, the list will not scroll, so I am limited to only
the range that comes up by default.  Also, what I consider the backward movement
to the scrolling bookmarks [vs. multi-column format] also impacts this negatively.

2.    I cannot drag/drop links into the pulldown-menu bookmarks list at all. " 
These last 2 issue, though, seemingly are sporadic; occasionally [but not
usually] they seem to work.  FWIW, moz 1.6/win2k[fully patched].  

Sorry if these issues duplicate, but my initial search did not show them on
here.  I resisted going bugzilla, but finally got fed up and had to provide
$.02.  Thanks.

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420