469416 - Add "Folder" to the properties pane of bookmarks when viewing search results

Status: RESOLVED DUPLICATE of bug 469421

(Firefox :: Bookmarks & History, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Currently when you are searching for bookmarks in the library window it is difficult to know what folder the bookmark currently resides in.  We should add the "Folder:" information currently shown in the star contextual dialog to the properties pane of the Library window, when the user has selected a bookmark in search results.  Currently we don't show the "Folder:" information for bookmarks in this properties pane because the source view on the left usually makes it obvious what folder you are looking at.  This is of course isn't the case for bookmarks in search results.  In addition to helping the user understand what folder their bookmark is in, this will also allow them to move it to a different folder.

Comment 1

[Jean-Philippe Fleury]

The bug 292104 talks also about that. Which one should be marked as a duplicate?

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to comment #0)
> In addition to helping the user
> understand what folder their bookmark is in, this will also allow them to move
> it to a different folder.

drag & drop to the left pane works for this use case

i guess if having a "path" column would help more, notice that's not feasible with current table schema but could be implementing the nested preordered tree.

Comment 4

[Georg Dembowski]

Bug 470117 has a different focus. 
Summary: Open bookmark sidebar, search, right click a search result, choose properties => no folder information shown. 
Suggestion: Show full folder path, each segment clickable, click opens folder in Library. Makes it easy to find/create siblings.

Comment 5

[Thomas D. (:thomas8)]

(In reply to comment #1)
> The bug 292104 talks also about that. Which one should be marked as a
> duplicate?

Bug 292104 covered several aspects and has been marked as a duplicate of bug 406105.

(In reply to comment #3)
> Bug 470117 has a different focus. Summary: Open bookmark sidebar, search,
> right click a search result, choose properties => no folder information
> shown. 

I think the expandable folder widget (which is currently only in the yellow star "Edit this bookmark" popup) is what comment #0 wants for this bug, and it will be a good approach for bug 470117, too (when expanded, nested folder hierarchy can be seen). Properties panels of library and sidebar should be unified, anyway. However, after implementing the widget we still won't have clickable folder path sequence to open any one of the nested parent folders in library as requested by comment #4 (and it's really not clear from bug 470117). Georg, please post a new bug for that feature if you want it, as advised by Marco.

Comment 6

[Thomas D. (:thomas8)]

Attachment: Sample UI (Mockup screenshot of Library's properties pane for bookmark search results)

(In reply to comment #0)
> We should add the "Folder:" information currently shown in the star
> contextual dialog to the properties pane of the Library window, when the user
> has selected a bookmark in search results. ... In addition to helping the user
> understand what folder their bookmark is in, this will also allow them to move
> it to a different folder.

I prepared a mockup screenshot which includes a sample UI of library's properties pane for bookmark search results with the folder wigdet added as suggested by comment #0. Also, I have included:
- "View containing folder" button (bug 469441)
- "Folder column" for results table (bug 469421; SM bug 56418)
I'd appreciate ui-review from someone in charge.

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

>I prepared a mockup screenshot which includes a sample UI

I think for the contents of the folder collumn we will probably want to go for a format with slashes, similar to a URL:

folder/subfolder/subsubfolder

the reason being that we are thinking about exposing these bookmark paths in the location bar, and allowing users to actually navigate on them, so it makes sense to follow a syntax similar to URLs.

Comment 8

[Shawn Wilsher :sdwilsh]

(In reply to comment #7)
> I think for the contents of the folder collumn we will probably want to go for
> a format with slashes, similar to a URL:
> folder/subfolder/subsubfolder
How would we handle this for RTL languages?

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

having bookmarks paths will perform badly, unless we implement bug 408991.

Comment 10

[Gervase Markham [:gerv]]

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

Comment 11

[Georg Dembowski]

(In reply to comment #5)

> I think the expandable folder widget 
> is what comment #0 wants for this bug, and it
> will be a good approach for bug 470117, too (when expanded, nested folder
> hierarchy can be seen). 

I agree

> Properties panels of library and sidebar should be unified, anyway. 

So that CTRL+B (bookmark sidebar) and menu item "Organize Bookmarks" (or however it is called in current version which I don't use due to lost folder functionallity) offer the same properties dialog for bookmarks? Fine, I'm happy with that.

> However, after implementing the widget we still won't have
> clickable folder path sequence to open any one of the nested parent folders in
> library 

IMHO nice to have, nothing more

Comment 12

[Georg Dembowski]

(In reply to comment #6)
> Sample UI (Mockup screenshot of Library's properties pane for bookmark search
> results)

I like it, think it's well usable and I would prefer to have this version implemented quickly as it makes folders usable again in FF3.x. Whether and how to make folder paths seems to need a lot of discussion and can be implemented later as extension of this version, so no effort is useless.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

It's better to keep view containing folder on the context menu of the search result, since this keeps the properties pane simpler and is internally consistent with the behavior of the download manager, and externally consistent with a few other file search interfaces.

Comment 15

[Dick]

This is the main reason I stay with Opera, because when searching for a bookmark and I now only for example the word "forum" I get a list which gives little information.

Comment 16

[k73qq55wftttt2chb424]

There are at least 4 outstanding bug or enhancement requests on this topic covering 150+ votes to solve a simple problem which should have been solved a long LONG time ago.

The very simple problem is that when you search for and find one or more bookmarks in ANY part of firefox (v10.0.2 Windows in my case) there is absolutely ZERO way of telling **WHERE** that bookmark came from in your extensive, thousands upon thousands of bookmarks.

You "find" it but you can't really figure out where it CAME from.
There is no way to determine what folder inside of a folder inside of whatever folder that bookmark is located.  You can't go to that folder.

The information is useful and needed because sometimes you are retrieving a bookmark and know it is from a larger batch of bookmarks dealing with the same topic or issue.  You know enough to find one of the bookmarks (via search) but you are dead-in-the-water cause there is no way to find the rest of them or go to the folder holding it.

(Yes, I suppose you could export your entire bookmark list in HTML format, load it up and then search that way, but that isn't really a solution is it?)

There is simple solution/request.

For any bookmark which is retrieved from:
1) the 'anything bar' (or whatever we call the URL searching process);
2) the bookmarks sidebar search, or
3) the "Library Organizer" bookmark search...

All bookmarks from these retrieval/search mechanisms should be able to be right-clicked->properties and show the Folder location (in the bookmarks tree) of the bookmark, *OR* (in the case of the Libaray which has columns) the location should appear, if selected, as one of the column values such as Tags, Last Accessed, etc.

Again...the simple act of finding out where a bookmark came from is impossible using normal means.  These bugs have been here for years and all other browsers I'm aware of do this normally.  What is the problem?

Bookmarks can already be right-clicked and choose properties.  Can't we just add an extra field to show the bookmark location??  Library organize already has columns for all the other bookmark attributes, can't one be added to show location?

(PS: the use of the word "Location" on bookmark attributes to denote "URL" is just extra confusing if/when the actual bookmark TREE location is included.  I don't know what you call the new attribute if "Location" is already used for "URL", but I digress.)

FYI: I found the following bug tickets addressing the same basic issue (I'm sure there are more.  I only waded through about 150 before giving up.)  Could someone consolidate them (and the votes!) as well?

BUG: 469421
BUG: 56418  (From year 2000!!!)
BUG: 527225

Comment 17

[quastickopl]

I had started feeling guilty about placing my bookmarks in directories. 
But then I saw that chrome has a 'Show in folder' feature, for weird people like us, who keep their bookmarks organized.

Comment 18

[Warwick]

This feature is needed by <<everyone>> who has hundreds of bookmarks organized into folders. All we need is for the right-click 'Properties' to also include the parent folder.

I just cannot understand why this bug has been floating around for so long without being actioned.

(There are several existing workarounds/add-ins, but these are all quite cumbersome and unfriendly. For such a basic feature it should be part of Firefox functionality).

Comment 19

[Thomas D. (:thomas8)]

(In reply to k73qq55wftttt2chb424 from comment #16)
> There are at least 4 outstanding bug or enhancement requests on this topic
> covering 150+ votes to solve a simple problem which should have been solved
> a long LONG time ago.

+1

> The very simple problem is that when you search for and find one or more
> bookmarks in ANY part of firefox (v10.0.2 Windows in my case) there is
> absolutely ZERO way of telling **WHERE** that bookmark came from in your
> extensive, thousands upon thousands of bookmarks.

+1. Given that all the problems in this corner have been clearly identified long ago and presumably aren't very hard to solve for anyone who knows the code, one might easily get the impression that whoever is responsible for the current incomplete design featuring ux-interruption, ux-inefficiency and ux-inconsistency has just stopped to care about the real and continuous problems experienced by bookmark users.

> You "find" it but you can't really figure out where it CAME from.
> There is no way to determine what folder inside of a folder inside of
> whatever folder that bookmark is located.  You can't go to that folder.

+1

[snip]
> FYI: I found the following bug tickets addressing the same basic issue (I'm
> sure there are more.  I only waded through about 150 before giving up.) 
> Could someone consolidate them (and the votes!) as well?
> 
> BUG: 469421
> BUG: 56418  (From year 2000!!!)
> BUG: 527225

For auto-linkification of bug numbers, pls use this syntax:
BUG 469421
BUG 56418  (From year 2000!!!)
BUG 527225

Comment 20

[webmaster]

In short: It's easier to organize your bookmarks when you can see where they are.

Having recently worked another dozen hours to {clean,organize,merge,share,publish} i.e. make my bookmark libraries usable, I came to the conclusion that folders are no usable if one has over a (couple of) dozen of them, without the 'view folder' feature. Which makes the whole Bookmarks Library barely usable as a Management information system.

As part of my effort to make my bookmarked ressources usable again, I tagged hundred of them. 
- Having the 'view parent folder' would have helped considerably
- Tags help but 
    a) requires a hell of a work --unless you start with an empty library uh uh;
    b) becomes hardly usable without the help of folders as soon as you're dealing with hundreds or more bookmarks. Especialy since you can't search for tags _only_ (you can search for a string that is tagged but the results include all tagged items that have this string it their {titre,urls,tags} which can be quite distracting, see BUG 479903.)

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #0)
> In addition to
> helping the user understand what folder their bookmark is in, this will also
> allow them to move it to a different folder.

+1

(In reply to Thomas D. (away till 31st January) from comment #19)
> (In reply to k73qq55wftttt2chb424 from comment #16)
> > The very simple problem is that when you search for and find one or more
> > bookmarks in ANY part of firefox (v10.0.2 Windows in my case) there is
> > absolutely ZERO way of telling **WHERE** that bookmark came from in your
> > extensive, thousands upon thousands of bookmarks.
> 
+1
> 
> > You "find" it but you can't really figure out where it CAME from.
> > There is no way to determine what folder inside of a folder inside of
> > whatever folder that bookmark is located.  You can't go to that folder.
> 
+1
> 
> [snip]
> > FYI: I found the following bug tickets addressing the same basic issue (I'm
> > sure there are more. 
> > BUG 469421
> > BUG 56418  (From year 2000!!!)
> > BUG 527225
> 
Also BUG 792440
Which I answered before I found this one.

(In reply to Thomas D. (away till 31st January) from comment #6)
> Created attachment 392021 [details]
> 
> [snip]
> I prepared a mockup screenshot which includes a sample UI of library's
> properties pane for bookmark search results with the folder wigdet added as
> suggested by comment #0. Also, I have included:
> - "View containing folder" button (bug 469441)
> - "Folder column" for results table (bug 469421; SM bug 56418)
> I'd appreciate ui-review from someone in charge.

This is the way to go IMHO.

Platform:

Firefox 26.0 on Arch Linux x86_64

Comment 21

[webmaster]

As for « telling *WHERE that bookmark came from in your bookmarks library », there's that 9kb extension (thanks to jscher2000 https://support.mozilla.org/en-US/questions/966257#answer-461279 ): 'Show Parent Folder' by White Alice0775
Thought 'Search' is the only place whre it shows the 'parent folder' (i.e. not in the properties), it helps answer part of the need.

Another extension by White Alice0775, 'SavedSearchButton':
- [snip]
- enables you to search in [snip] currently selected folder.

Comment 23

[Thomas]

When searching for bookmarks within the Library window, the left folder hierarchy could update each time you click on a search result, to indicate the containing folder.  The background highlighting of the containing folder could change as appropriate.  That would be a simple way of solving the problem.

Comment 24

[Georg Dembowski]

(In reply to Thomas from comment #23)
> When searching for bookmarks within the Library window, the left folder
> hierarchy could update each time you click on a search result, to indicate
> the containing folder.  The background highlighting of the containing folder
> could change as appropriate.  

+1 because that proposal seems very sleek and helpful and easy to understand/use, as several other softwares show similar behaviour, e.g. file explorers, image viewers etc. In case it's to be implemented, we shall make sure it's easy to distinguish between the folder where search is executed (e.g. solid border and fully saturated background) and the folder(s) containing the clicked/hovered/selected... search result (e.g. dashed border and background with 50% transparency).