GNOME Bugzilla – Bug 348023
Improved search interface
Last modified: 2008-02-26 20:52:07 UTC
Talbe of Content and Search Interface Integration: I was thinking that the search function could be integrated at the bottom of the table of contents like firefox/epiphany does their searches, except it'd always be visible. The window might have to be expanded to compensate for the "Back" and "Forward" buttons, but they can easily be made with icons and no text. When a search is executed, the listboy above would display the results or highlight them. This would eliminate the need for a search window. The two options in the search window might be problematic to integrate into the proposed interface, but maybe another button or an expansion of the index window could hold those options. Other information:
I forgot to add a rough sketch of my proposal (I don't know if it violates the HIG): <a href="http://pisapia.googlepages.com/tableofcontents.jpg">Proposed Table of Contents Interface</a> Sorry for the horrible drawing, I don't know how to use the gimp.
Created attachment 69186 [details] mockup I've been thinking about this for a while as well, but with a slighty different vision. I added a slighty rough mockup as an attachment. In addition to what you see in the mockup, there should be a column added between 'Note' and 'Last Changed', titled 'Matches'. This would display the number of matches found in each note to the search term, and allow the user to sort by number of matches. The search box should also contain a clear button to place a null string in teh search box, with the consequence of showing all the users notes in the TreeView (like the current ToC). May I also suggest Esc as a clear shortcut? (Deskbar does this.) Notice there are no Previous/Find Next buttons. Individual note-searching should be done from that note, with a search bar like Firefox, Epiphany, or Evince. (At the bottom, and appearing only when needed...) In addition, I removed the 'Search All Notes' checkbox. Of course, this is just my opinion :)
Scott, I think that mockup looks good, and this is definately the way I want to move towards with searching in Tomboy, including the Firefox-style search bar.
Created attachment 75477 [details] Additional mockup I've been tinkering with modifying RecentChanges.cs (Table of Contents) to work like this. When you initially bring it up, it doesn't include the "Relevance" column, but as soon as you search for something, it adds the "Relevance" column and filters the list down to only the notes that match the search string. Is this kind of what you're after as far as integrated table of contents/search?
Does the user really need to explicitly see the relevance of a note? Why not just sort by relevance without having to show the user the number of matches etc.?
Boyd, that's almost exactly what _I_ had in mind, at least. However, I dislike the way you have implemented relevance display -- the progress bar is somewhat ambiguous in the precise relevance and how that compares to other notes or a baseline (e.g. 0 matches). I favor an 'n matches' technique. Daniel, > Does the user really need to explicitly see the relevance of a note? Why not just sort by relevance without having to show the user the number of matches etc.? It's quite useful to be able to switch to sorting merely alphabetically or to relevance, or to date modified, as well as to see how it actually compares to other notes: two notes may have 10 matches and 2 matches, but be right next to each other; two other adjacent notes may have the same number of matches. Couple minor things: * window needs renaming; it's not a table of contents * rename Note column to Name * at the bottom of the window, where it says 'Total: n notes' is kind of vague (total of what? all notes? matching notes?). I think it could probably be used for some more valuable info as well... Boyd, care to submit a patch...?
Boyd, this looks freaking awesome. I disagree with Scott, in that I think it should stay "Table Of Contents" and Notes should stay Notes. At the bottom, maybe "Total: 100 notes, 12 matching". I'd love to see a patch for this =)
Actually, scratch that. This should be called "Search Notes", and "Table of Contents" should be removed. Or maybe making it subtly less explicit, like "Find Notes". Which could conceivably encompass both search and browsing.
Created attachment 75519 [details] mockup with numbered matches I will integrate the ideas from the previous few comments and submit a patch. Thanks for the feedback. I will say that I do like seeing the matches displayed in a column. It helps visualize how relevant the search is. As this current attachment shows, it does looke like showing the number of hits directly (instead of using a progress bar) is better.
Created attachment 75690 [details] [review] Patch that addresses everything except Firefox-like individual note search (next on TODO list) This patch has the following: 1) Removed the TOC & Search menu items from the TrayIcon popup menu and replaced it with one item, "_All Notes" 2) Replaced the progress bar "relevance" with a text string (i.e., "4 matches") 3) Renamed the "relevance" column to be "Matches" 4) The bottom status text now shows the number of current matches (i.e., "Total: 59 notes, 24 matches") 5) Columns are clickable/sortable 6) When sorting by # of matches, a secondary search sorts the notes alphabetically 7) Added a "clear" button to clear the search/filter string. I tried changing the Escape key to clear the filter string, but immediately noticed that I missed being able to close the window with Escape. Thoughts? 8) Added code to present the existing "All Notes" window if the user selects that again from the TrayIcon popup menu (instead of popping up another window) I will start looking at the Firefox-like individual note searches now. Any/all comments/suggestions gladly accepted!
Created attachment 75691 [details] Screenshot 1 of 2 for Comment #10 patch
Created attachment 75692 [details] Screenshot 2 of 2 for Comment #10 patch
Created attachment 75708 [details] [review] Complete patch for this bug/enhancement I'll have to give this patch another look-over in the morning, but I believe it is ready. Things it does: 1) Provides a "Firefox-like" find bar at the bottom of each note for finding text 2) Pre-populates and shows the find bar when you open a note from the new "All Notes" window 3) Highlights the next match when you press Enter in the find entry 4) Highlights the previous match when you press Shift+Enter in the find entry 5) Hides the find bar when you press Escape in the find entry 6) Resets the find search when you change a note by typing in it This should complete the work for this bug. Please let me know your thoughts and I can adjust the patch accordingly and commit it when it's ready. I'll attach a screenshot of the new interface.
Created attachment 75709 [details] New individual note "Find" capability
I fixed up the patch a little bit and just committed it to CVS Head. I'd change the status of this bug to reflect action, but I don't have rights to do so. The name of the new dialog/trayicon menu item ("All Notes") seemed to make sense to me, but if it should be changed from that, please let me know and I can take care of it.
Checked-in to CVS Head. Will be part of next release.
Does it need to say "12 matches", "3 matches", "1 match" when the column is labelled "Matches"? Can't it just say "12", "3" and "1" respectively?