This is my proposal: The current search window displays both results and criteria in the same window, and this makes it very hard to use -- both for new users and more experienced ones. * When I am searching, I always have to scroll a lot and I'm not satisfied with this. It's easier for me if I can see more results, however the splitter in the middle of the window doesn't cut it because I can't make the window large enough to view both results and criteria. * When I search with History or Bookmarks, I get a new window. We all want consistency among the many search functions of our app don't we? * Sometimes when I am searching, I want to have a results list hanging around for a while - maybe I want to use it later without redoing the whole search (think about doing a NNTP search on a slow connection for example...). With a separate window, we could open a results window dynamically with the results so you could have different result windows opened at once. * I think we've all done a terrific job at simplifying the FilterEditor window, it's much easier to use now! The next time is to make this window easy to use, because currently there are so many widgets that you may even scare away (!) the user. This would also get solved by a separate results window. The new window could be results window with a stretched tree/outliner and a little toolbar with the "Go to", "Delete" (etc.) buttons at the left. I imagine the title would be "Search results for 'cats and dogs'" so you could easily find the windows in the windowsbar/window menu. What do you all think? As always, I'm anxious to see this and think it would be a big usability win! :)
for my sanity summary +message If we do this i'd like a modify this query button or something akin to the link in the bugzilla query results page. sometimes queries don't have any really useful information in them to make good query titles, iirc BeOS Tracker will name queries by date/time-stamp which is actually sort of useful. Supposing i run 3 or 4 wacky queries on my mailbox (this is really quite likely given that i use it as a bugzilla cache and am often looking for multiple things) the odds are that none of my queries can get good titles, but just having timestamps would probably let me figure out which is which (or we could let people name their queries, iirc beos lets you do that too). So, Query name, defaults to join of logical string fields if first field is a string. fallback: current date+time. We can talk about which other fields can be converted into human readable titles... Save Search button :) the other thing to consider is making searches appear in the normal folder tree. (this could solve saving searches) this has been discussed before, and i should probably dig for a bug, but since we are talking here... v Searches * Cats and Dogs * 7/12 Midnight the benefit of this is you could have as many views as you like and the normal drag and drop features... Context menu would include Delete Search and Modify Search and perhaps Duplicate Search... We could even set it up so that the search form appears in the message pane when no results are selected (or when "Searches" is selected).
Summary: Have search results in a new window → Have message search results in a new window
enhancement, future. we should be focusing on getting the basic functionality (which would be in any search implementation) working first. taking from naving, this would be FE. if any plans or specs to improve search develop, I'll link to them here.
Assignee: naving → sspitzer
Severity: normal → enhancement
Target Milestone: --- → Future
Status: NEW → RESOLVED
Last Resolved: 13 years ago
QA Contact: laurel → search
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.