Spin off from bug 259914, for ideas on how to improve the UI and functionality of the quicksearch bar. Some of the ideas so far: A. Add more search modes to the menu : - Sender/Recipient combo, for people who have combined in/sent boxes and want to find all to/from messages by the one author - An ALL header fields option - Any others? B. Perhaps a way to have a "custom" search, by switching the menuitems from type=radio to checkbox (or providing a submenu that has checkbox options?). That way, a user could add or subtract options at whim, and it would save over sessions if they always use it. This would, of course, be off by default. It would also require an overhaul of the way searches are handled, since a lot of code currently assumes that the search mode number refers to one search type, rather than many. C. Provide a link in the quicksearch bar to the advanced search window. Currently it's only linked from Edit->Find->Search Messages, which isn't as intuitive. Any thoughts on these, or other ideas?

Idea C is my preference and would be even better if it is provided with over-sessions memory. This will allow users to create custom behavior tailored to their configuration. Maybe more than one entry: Custom1, Custom2, Custom3... all linked to advanced search window and each with its own memory. Advanced search done from Edit->Find->Search can remain without an over-session memory.

First: I think the proper term is "tool" or "widget" -- "bar" implies toolbar, plus there is a Search Bar in Seamonkey that contains both QuickSearch and MailView. After fixxing 259914, the only thing I'd like to see different is to remove Entire Body from Quicksearch, because: searching Entire Body is *not* Quick. (A) is an OK idea, but the 'right' way to do it -- following in the vein of what's been fixed for 259914 -- is to use that mode instead of Sender or Recipient when the selected folder is not a special folder, and use Sender only when viewing Inbox or Junk. Which would break for that set of people who insist on copying their Sent messages into the Inbox. Further: rather than searching both criteria, the proper way to search this way is to check whether the message's sender (From) is one of my identities: if it is, search the recipients, otherwise, search the sender. I'd like to be able to look in a folder that contains messages from people in my family and enter "cowp" in the field and only see messages to/from them, not all messages from me. (B): I don't want to see this; it would add too much weight, doesn't really add much functionality, and I don't want to be triaging bugs about it. Have you considered making an extension for this capability? (C) I don't really know what you mean by "link in the quicksearch bar", but besides the menu item you mention (which I agree is in a sucky place) there is also a Search in the context menu of each item in the Folder pane (except Saved Search folders). Comment 1 seems to be going beyond what this bug is about; also, searches *can* be saved already, and I don't see the point of creating a bunch of additional UI on the Search Messages UI to duplicate what's already available with Saved Search Folders.

I use Entire Body more than any other search, besides the default. So I wouldn't remove it, personally.

(In reply to comment #3) > I use Entire Body more than any other search, besides the default. So I > wouldn't remove it, personally. I agree. I use it a lot and wouldn't remove it, either. I always assumed "quick" referred to ease of access to the function and not that the search algorithm was any faster. One thing I did notice, though, is that it seems to search only message body, not headers, making the term "Entire Message" misleading. So one extra improvement I'd suggest is renaming it to what it is.... "Message Body". (In reply to comment #2) > Further: rather than searching both criteria, the proper way to search this way > is to check whether the message's sender (From) is one of my identities: if it > is, search the recipients, otherwise, search the sender. I'd like to be able > to look in a folder that contains messages from people in my family and enter > "cowp" in the field and only see messages to/from them, not all messages from > me. Interesting idea. But wouldn't it add a greater burden to every single search, most of which wouldn't need it? I stress I'm not a professional coder (if that isn't already obvious ;) ), but even bloating the menu with more menu options sounds preferable to me than that. > (B): I don't want to see this; it would add too much weight, doesn't really add > much functionality, and I don't want to be triaging bugs about it. Have you > considered making an extension for this capability? Heh, nah, I won't be joining the "update hell" of extensions :) But it was just an idea. If people don't like it, then I don't have to code it :) I suspect it wouldn't add that much weight, though, since it would use most of the existing code and would be almost invisible to anyone who didn't want to use it. And it would prevent people wanting to bloat of the menu with other search combinations. > (C) I don't really know what you mean by "link in the quicksearch bar", but Sorry, bad terminology on my part. Basically, add a menu item for the advanced search at the bottom of the menu of the quicksearch tool..widget thingy. With separators around it, so it doesn't clutter the search modes. That menu is the place where most average users would expect to find anything to do with search. I didn't even know it existed till recently.

David in comment #3 > I use Entire Body more than any other search, besides the default. So I > wouldn't remove it, personally. same here. I understand the concern about "slow", but slow is is relative to the specific use case, one's server/mail store, the folder(s), etc. Woods in comment #4 > entire message search only message body, not headers, making the term "Entire Message" > misleading. So one extra improvement I'd suggest is renaming it to what it > is.... "Message Body". debated in bug 271222 > (In reply to comment #2) > > Further: rather than searching both criteria, the proper way to search this way > > is to check whether the message's sender (From) is one of my identities: if it > > is, search the recipients, otherwise, search the sender. I'd like to be able > > to look in a folder that contains messages from people in my family and enter > > "cowp" in the field and only see messages to/from them, not all messages from > > me. > > Interesting idea. But wouldn't it add a greater burden to every single search, > most of which wouldn't need it? I stress I'm not a professional coder (if that > isn't already obvious ;) ), but even bloating the menu with more menu options > sounds preferable to me than that. > > > (B): I don't want to see this; it would add too much weight, doesn't really add > > much functionality, and I don't want to be triaging bugs about it. Have you > > considered making an extension for this capability? > > Heh, nah, I won't be joining the "update hell" of extensions :) But it was just > an idea. If people don't like it, then I don't have to code it :) I suspect it > wouldn't add that much weight, though, since it would use most of the existing > code and would be almost invisible to anyone who didn't want to use it. And it > would prevent people wanting to bloat of the menu with other search > combinations. > > > (C) I don't really know what you mean by "link in the quicksearch bar", but > > Sorry, bad terminology on my part. Basically, add a menu item for the advanced > search at the bottom of the menu of the quicksearch tool..widget thingy. With > separators around it, so it doesn't clutter the search modes. That menu is the > place where most average users would expect to find anything to do with search. > I didn't even know it existed till recently. [skipping much other material] > Comment 1 seems to be going beyond what this bug is about; also, searches *can* > be saved already, and I don't see the point of creating a bunch of additional > UI on the Search Messages UI to duplicate what's already available with Saved > Search Folders. Woods, is your intent is to improve both the power of search and the toolbar? yes, additional items on the search bar should be avoided. But if the issue here is better productivity and to get beyond what we have, then some change may be advisable. Clever thinking has yielded good improvements in the past - so I don't see a problem with blue skying with ideas. As for saved search, it has its flaws: * each one takes a line in the folder pane * search terms are static Back to creative thinking - I propose we take attempt to developed a few ideas then pick the best. If we improve an idea rather than discount it early on we are more likely to get a better result. A starting point might be for each of us to state the two or three use cases that are repetitive/tedious/bothersome.

(In reply to comment #5) > debated in bug 271222 Thanks. Found bug 353347 as a result. :) > [skipping much other material] > > Comment 1 seems to be going beyond what this bug is about; also, searches *can* > > be saved already, and I don't see the point of creating a bunch of additional > > UI on the Search Messages UI to duplicate what's already available with Saved > > Search Folders. > > Woods, is your intent is to improve both the power of search and the toolbar? I may have read that wrong, but it looks like that's Mike Cowperthwaite's comment you're addressing, not mine :) But yes, I'm happy to make it both easier to use and more useful. Whatever "seems worth it" for the code addition. > yes, additional items on the search bar should be avoided. But if the issue > here is better productivity and to get beyond what we have, then some change > may be advisable. Clever thinking has yielded good improvements in the past - > so I don't see a problem with blue skying with ideas. Agreed, especially since it's probably now too late for most ideas on this bug to make Tb 2.0, so there's less risk in trying out new ideas. > Back to creative thinking - I propose we take attempt to developed a few ideas > then pick the best. If we improve an idea rather than discount it early on we > are more likely to get a better result. I know Mike hated my idea on paper for allowing multiple search modes to be selected in the menu, but let me still post the proof-of-concept patch I worked up. It's only a rough draft, but it'll give you a good idea of how it works. And it doesn't look as scary or heavy as it originally sounded. I think it's actually pretty simple to use, and addresses a lot of issues surrounding new combination or custom search modes. If people still hate it, I'm fine with that, but I think it's worth putting it on here in case it leads to something :)

OK, this is isn't a polished patch, so I already know the code could be more efficient in places, and possibly styled better. It's just something I knocked up to illustrate the "multiple search modes" idea. The patch also includes the last patch from bug 259914, which bulks it up a bit. By default, the quicksearch menu works as normal. But check the "Multiple - Custom" option at the top and now it works like a checkbox menu, allowing you to choose any combination of search terms that you might want (well, that are currently supported, anyway). Also when the multi option is switched on, "combination" search mode menuitems are logically hidden, but if one was selected at the time of the switch then its component "primary" search modes are automatically checked, e.g. "Sender or Subject" is hidden, but "Sender" and "Subject" become checked instead. The primary search modes are treated as binary powers, which seems both more useful and efficient to employ than the current method. The current patch doesn't allow the multi search mode to save over sessions, though that would be a necessary addition. If people hate it, that's OK. The fun was in the attempt :)

OK, I'll concede the point the body search. Wayne, could you provide a few screenshots? I'm having difficulty envisioning what you're describing, and I'd as soon not spend time merging the patch. If we're blue-skying here: What would be cool would be to link a MailView with the QS field. You could save a view for Content-Type, contains (this is something I often need) but have the text part of that criterion rely on the contents of QS. That kind of redirection would require some deep changes, but it would allow the kind of custom and saved behaviors discussed earlier to be put into the "expert-mode" MailView rather than in QuickSearch, which is geared to newbie users.

What I'd really like to see is a real "Search Entire Message". That means, it should really search every entire message in the current folder, including header and body. My previous email program had a search where you just enter the search term, and it doesn't care where it appears. That's what I used 90% of the time. In TBird, I have to do the same search at least twice (my home-brewn "Header" option and the "Body" option). I don't want to select where the search term appears. It takes time, and ruins productivity. Btw, "Search entire message" is totally counter-intuitive. Every other option in the quicksearch bar searches in all messages in the folder, only this one does something different, and besides, it doesn't even search the entire message, but only its body! So while there's motion about the quicksearch feature, we might as well try to get it right! Oh, and the "Search Messages" menu item is unusable for me. It's slow, requires too many user interactions to get the search going, but worst of all, it requires you to double click and close again each message to see its content. And I don't want to save each search as a folder in order to be able to navigate the search results in any useful way. I'm sorry if this sounds ranty - I love TBird for many things, and I'm frustrated by some of its quirks which just don't seem to improve...

(In reply to comment #9) > Btw, "Search entire message" is totally counter-intuitive. Every other option > in the quicksearch bar searches in all messages in the folder, only this one > does something different, What? Which messages are searched, if not all the messages in the folder? If you're really seeing some different behavior there, that's a bug and should be filed as such.

I'm sorry, that must have been in a previous version where there was a "Find in message" option or something like that. Entire Message does search the body, but not the header, which I still find impractical... Thanks for pointing that out...

(In reply to comment #8) > Wayne, could you provide a few screenshots? I'm having difficulty envisioning > what you're describing, and I'd as soon not spend time merging the patch. OK. With the patch enabled, here's a screenshot of a small mail folder. In this shot, multiple search mode is unchecked, and there's no text in the search field. So this is more of a comparison with the screenshot that will follow.

Checking the "multiple - custom" item allows you to search both "sender" and "to or cc" at once. For simplicity, this is obviously a pretty trivial example, but it shows you how it works.

The most important change for me would be to allow a tag search. It's a real pain to have to open the advanced search dialog to do this. Also an easy way to specify this folder or all folders, again w/out having to go to the advanced search dialog.

FWIW, this kind of multiple criteria quick search, though with a different Ui, is very interesting implemented in an extension called Seek. Currently under improvement ..

other improvements to quick search in bug 431104 and bug 319540

Another simple but useful improvement: Change the search "Recipient (To: or CC:)" to "Recipient (To: or CC: or BCC:)". This is very helpful for people sending BCC-mails.

another idea/rfe in bug 290620

There is also bug 462578 on another search option. Should all of those (mostly unconfirmed) bugs remain separate or consolidated in this one here?

I don't think consolidation is wise here for a few reasons: 1. we don't yet know how the yet to be fully unveiled new search toolbar will change how people use quick search 2. for the sake of bug authors, each of the bugs deserves attention 3. while discussion of a bigger view/multiple options is useful, which is how this bug started, if changes happen they are most likely to happen in smaller pieces Wayne, can you make the summary more explicit about what you want to see happen based on what's been discussed so far. Or, should this become a meta bug? And, FWIW this and other quick search bugs are no going to happen for version 3 unless a serious effort is made in the next 2-3 weeks to drive in patches which don't yet exist. Personally I'd like to see bug 462578 happen. Is it a dupe of some other bug?

Didn't find any duplicate, I've just confirmed it.

(In reply to comment #14) > The most important change for me would be to allow a tag search. It's a real > pain to have to open the advanced search dialog to do this. Also an easy way > to specify this folder or all folders, again w/out having to go to the advanced > search dialog. Have you tried adding the "View" combo-box thing to your toolbar? Under the 'tags' option is a list of all the tags. Alternatively available from "View"... "Messages"... "Tags". The setting is sticky if the "View" thing is in your toolbar, but is not sticky if it's not.

WFM with the new gloda search.