This is a tracking bug for mockups of the advanced search UI in the places organizer. Due to to the attachment size limit images will be hosted on people.mozilla.com. Check the most recent comment or URL for the latest iteration.
Status: NEW → ASSIGNED
Assignee: nobody → faaborg
Status: ASSIGNED → NEW
Iteration 5: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_OrganizerAdvancedSearch_i5.png Text from the mockup: --- Users enter the advanced search UI as soon as they begin typing a search query into the search bar, or by hitting the advanced search button in the bookmarks toolbar. The search scope is automatically set to "all bookmarks", but their previous location in the Places Organizer (shown below as "folder name"), is also an option. --- The Scope Bar allows for multiple selection, or for no items to be selected (in which case there will be no results). "Bookmark is in folder" is also one of the possible filters. --- This is the user's task flow through the interface: --- Advanced searching is commonly accomplished using a 5 step task flow: 1. Enter search text 2. Define scope 3. Apply specific filters 4. View search results 5. Save search as smart folder Here is how this 5 step task flow is designed in the advanced search in Vista, and OS X's Spotlight --- Vista's advanced search does not automatically update on specific filters --- Apple refers to this control as the "Scope Bar" and it appears in the Finder, Mail.app, Address Book, and Safari --- Each filter takes the form of subject -> predicate -> object
Note for i6: there should be a close button in the search field to clear the search, similar to OS X and Vista.
possible idea for i6: should we add a column for displaying the path of what folder the bookmark is in?
Reply to comment #3 I would also like the option to display a column that displays the bookmark folder location. Even in this era of ubiquitous search a manually created bookmark folder hierarchy can still be quick and useful without having to resort to the keyboard to type in search parameters. If there is a way of displaying custom columns/fields in the search results you can ensure bookmarks are in your favoured location. Particularly if there are duplicate bookmarks and you want to delete the one in the 'incorrect' location. The bookmark folder location would not necessarily have to be displayed by default but it would be a nice to have as a optional display column.
I think it's better to show the folder path of the bookmark in the detail info dialog which the user can bring up in a right click or double click on one search result. I don't think the folder path is useful in most cases, so it should be hide from the main UI to keep it simple. However, providing some means to show the folder path is critical, for occasionally user will want to see the folder path. And user tends to see the folder path when he wants to move the bookmark into another folder, show I think in the detail info dialog, there should be a "Move" button besides the folder path.
Alex, I think adding negative filter options would neatly increase the robustness of Advanced Search queries. ie, create a query that can give me all bookmarks with Tag is "Places" and Tag is not "bug".
Yeah, I agree. I need to take a look at the current state of the advanced search UI, unfortunately I've got a ton of stuff on my plate right now.
I hope this is one of those bugs that are up-to-date and comments are welcome; otherwise sorry for butting in on something that you guys are probably putting together behind the scenes nicely. This is just feedback from a user, so take that as you will. 1) Negative search is good, as mentioned above 2) "Folder Name" is ambiguous and seems to not fit grammatically with the prefix "Search:". If it were 'By Containing Folder' (i.e. 'find bookmarks inside folder with text x' or 'Folders' (i.e. 'find folders with text x') it might be clearer. Unless "Folder Name" is the name of your test folder, which I guess would make things better. 3) Actually replacing "Search:" by Vista's "Show only:" would make things much clearer. 4) UI polish: those button-dropdown things are too tall and probably should just be dropdowns (i.e. on Windows, combo boxes with the correct styling applied---not sure what the UI terminology is on Mozilla projects). Also I think that dropdowns that replace textboxes should be longer, maybe? Or visually distinct? I.e. "last week" is a different thing from "accessed" or "contains," so it seems like it should look different. 5) Highlighting (following the whatever the platform does for styles) the results is nice. I.e. if I search for "foo," then whatever things triggered a match (there could be multiple, e.g. Name and Location assuming this meshes with the currently selected filters). This should happen both in the results column and in the details view that shows when you select a specific item. 6) Using the "minus" button to both collapse the 'advanced search' functionality and to remove search filters is icky. I'd suggest following Vista's UI here for the collapse/uncollapse. (Actually these + and - buttons are pretty icky anyway, but you probably knew that... minus I'd replace with some kind of 'x', but then I'm not sure what kind of plus-replacement would fit with that kind of style.) 7) Looking at the UI in place in the public Firefox 3.0.0 release that I'm using, a few small things besides the above: (a) the Vista styles for "Search:" scope buttons are wrong; (b) I like the current "Save" button, but given that we're going to need collapse/uncollapse 'Advanced Search' right there, maybe follow Vista and place it on the toolbar. But hmm, the toolbar currently in place is about half for things in the main pane (organize, view), and half for bookmarks in general (back/forward, import and backup), so this is kind of ambiguous, especially given that you've placed the toolbar at the top of the window instead of at the top of the main pane. Not sure what to do. (c) Searches aren't included in 'history'! I.e. the back/forward buttons in this window do not take me to and from search results. Very bad! (d) Why do we not have the little search-mangifying-glass glyph anymore? This should be consistent with the search toolbar in the main browser. (But since it's search-as-you-type, I guess it goes away after you type things, a la Vista.) Hope that's helpful and not of the "yay lots of work from some random user who found the right bug" variety :P.
OH DAMN I forgot a really important one. 8) Adding these filters should in some way "build a query," perhaps in the search box or perhaps somewhere else (like above the results view, i.e. 'searching for "3.0 tag:places -tag:bug"'). That way people who want to avoid this whole UI and just filter their results fast in the future can do so.
This was a tracking bug for Firefox 3 development. I'm resolving as invalid since I am not sure the time to implement this feature is worth the value that it provides to users.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Summary: Mockup: Places Organizer - Advanced Search → Mockup: Places Organizer - Advanced Search for Firefox 3
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.