User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 Using the global search "search all messages" may turn up with multitudes of msgs, but none identify where a particular msg is located. In fact most msgs carrying the identifier of the search are not listed in the drop down. If click on a msg in the search field drop down it opens a new tab, but there the location is not provided either, but one can see the other msgs that were not included in the search drop down. Reproducible: Always Steps to Reproduce: 1. Highlight "search all messages." 2. Enter a word or phrase, then hit enter. 3. The drop down opens listing some of the msgs pertaining to what is in the search field. 4. None of the msgs in the drop down provide the folder where the msg is located. 5. Click on a msg and open the search in a new tab where the msg (and numerous others are seen). Actual Results: Could see the msg in question. Expected Results: It should have located the msg in order that it could be found and moved or replied to, etc.

Miles, thanks for the suggestion and questions below. however, please do not abbreviate words, especially in summaries, and especially references to names of buttons, functions, etc. it makes it difficult to search and understand bugs. #3 is faceted search results page, not a drop down #5 is, for lack of a better term, search results message list ... the same tab you get with "Open as list" It sounds like you are trying to describe two different issues above. So please clarify what you want in context of the following a) location/folder for #5 - there may already be a bug filed for this b) location/folder for #3 regarding a) - I thought there was a bug filed for this but I'm not finding one. (Thomas?) i think it would make great sense to have location displayed by default, just like for cross folder saved searches. Or at the very least persisted if I select location from the column picker. (eg Bug 374551 - Location column visibility is not persisted in saved searches) regarding b) - facet results isn't designed to provide lots of detail on the message, to much makes the pane messy and busy. but a tooltip with more detail about a message on mouseover might be nice. also, if you want to know what messages are in folder X, you click on a folder name in the facet section on the left and the list of messages will be filtered on a folder name. please describe what is needed and why.

1) OK, in the future I won't abbreviate "message" with "msg," and "et cetera" with "etc," et cetera. 2) It would be best if the locations/folders were listed in the faceted results page (It certainly looks like a drop down list to me, whatever you may call it!) -- this would alleviate having to take a 2nd step going into the "search results message list." 3) Regarding b) Personally I find it difficult to decipher (actuate) the contents of that tab or pane; mousing over the list of related messages (participants as well as the actual msg?) with identification of each entry might simplify a search for a message in a particular folder. 4) Why is it that all relative messages are not listed in the faceted search page, forcing one to open a new tab and then open areas within that tab to view additional information?

abbreviation is OK for non-key words like etc :) "search all messages" is by design, a 2-3 step process: * search * list message snippets, and refine via facets on the left * click to list the desired messages in a "standard" message list pane

Thanks for your speedy reply, Wayne. Curious a to why a search must be a 2 to/or 3 step process? If the location folder(s) were in the first search drop down, I believe that would satisfy most searches posthaste.

(In reply to comment #1) > a) location/folder for #5 - there may already be a bug filed for this > b) location/folder for #3 > > regarding a) - I thought there was a bug filed for this but I'm not finding > one. (Thomas?) I'm not aware of a bug to show Location column in the grid-style search results list by default. bmo search for "column picker" has some remotely related bugs, like bug 522861 and bug 527916. > i think it would make great sense to have location displayed by > default, just like for cross folder saved searches. Or at the very least > persisted if I select location from the column picker. (eg Bug 374551 - > Location column visibility is not persisted in saved searches) Absolutely agree with Wayne (and reporter). Furthermore, we need another bug to add a "location path" field that shows the full folder path including account (instead of just folder name like "Inbox" where you don't know which account it belongs to). > regarding b) - facet results isn't designed to provide lots of detail on the > message, to much makes the pane messy and busy. but a tooltip with more detail > about a message on mouseover might be nice. also, if you want to know what > messages are in folder X, you click on a folder name in the facet section on > the left and the list of messages will be filtered on a folder name. I agree with reporter that having some immediate indication of containing folder on faceted search results short previews would be nice. I also agree with Wayne we need to guard against stuffing the results pane with too much information. Don't know how to reconcile the two; maybe show the respective folder icon below the date? Hovering over icon could then show full path to msg, like "user@mail.com/Inbox"or "Inbox [user@mail.com]" Advantage of icon: minimally intrusive, intuitive spot to see the path, immediate visual distinction of containing base folders (inbox icon, archive icon etc.)

(In reply to comment #4) > Thanks for your speedy reply, Wayne. > Curious a to why a search must be a 2 to/or 3 step process? Yes, that's not very comfortable. We have some bug where it was suggested to make "Show all as list" a toggle button on the left pane of global search results page, and remember that setting for the next search. Thus users who don't like the complexity of the first result page could simply skip it. > If the location folder(s) were in the first search drop down, I believe that > would satisfy most searches posthaste. Miles, please respect the corrected terminology as explained in comment 1: "Dropdown" is a fixed term for a specific UI element where you can click on the dropdown arrow and a menu will pop up. It looks like this: [You can enter text here |v] cf. http://en.wikipedia.org/wiki/Dropdown The "faceted search results page", also called "global search results page" or "gloda search results page" (with multiple mini-previews of some result messages) has nothing in common with the UI definition of a dropdown box. It's a list, yes, and it's scrollable, and it has a small search dropdown box somewhere at the distant top, but altogether that doesn't make the whole page a dropdown. Maybe it's a language misunderstanding. We are sympathetic with your proposals, but we will be unable to understand you if you insist on using inadequate terms against better advice.

(In reply to Wayne Mery (:wsmwk) from comment #1) > comment 1, #3 is faceted search results page, not a drop down > comment 1, #5 is, for lack of a better term, search results message list ... > the same tab you get with "Open as list" > > It sounds like you are trying to describe two different issues above. So > please clarify what you want in context of the following > a) location/folder for comment 1, #5 ["Open as list" results] - there may > already be a bug filed for this ...but I'm not finding one. (Thomas?) We have: Bug 570787 - Global Search: "Open as list" Results should show location column by default [containing folder, faceted search, Search all messages] Bug 528044 - Global search: "Show/Open as list" results view does not remember columns (should persist column visiblity, e.g. for "location") [faceted search; search all messages] (These two cover Wayne's interpretation of comment 1, #5) > b) location/folder for comment 1, #3 and #4 [faceted search results] It's the same story for all types of search results in both FF and TB, and I don't know why Mozilla is so resilient against making them more useful in spite of age-old, ever-repeated user requests: For *any* type of search result, we need direct access to its containing location. For which in TB, let me think... I'd think that somebody recently filed a centralized bug...(surprise - that was ME!): Bug 686851 - Implement "Open containing folder" contextual action for messages in search results (faceted search, open as list, search messages dialogue, saved searches) [Show found message in folder location] (that covers comment 1, #3 and #4) Re-reading comment 1, #5 in combination with actual and respected results, I think we have partly misunderstood #5 so far: It's not "Open as list" [open *all* results in conversation], it's "Open in conversation" [Open *single* result in conversation], by single-clicking on a facet search result item. Which is covered in b) below. Technically, these might use the same template, but from a user's POV, they might not be the same thing. There's two interesting aspects about this: 1) Of course, Bug 686851 should also apply to "Open in conversation" type of search results. I'll add that to the summary. Thank you for the hint! 2) Coming from comment 1, Actual results, reporter is looking at *a single message* in the message viewer below "Open in conversation" type of search results list. And on that *single msg view*, it would make a lot more sense to have some indication or some way of accessing the containing folder of that msg. 2a) In fact, why not have an optional "Open folder" button available through customization of the (conversation's) message reader toolbar? (Needs a new bug) 2b) And, by extension of the context menu approach of Bug 686851, adding an "Open containing folder" menu to the dropdown menu of "Other actions" button (for conversation views only, not for 3-pane, of course)? I've added those 2 ideas for tracking purposes in bug 686851, comment 5. So this new interpretation of comment 1, #5 is also covered. > regarding b) - facet results isn't designed to provide lots of detail on the > message, to much makes the pane messy and busy. Agreed. Miles, I don't think we'll want anything like a permanent display or a big button for folder location for each message on faceted search results. Even a small button on each result item is probably not wanted, because the necessary reduplication for each result item will be too cluttered (hence wontfix for that aspect). However, in theory, some other possible solutions might be a) display such information or buttons as a floating menu on hover of a result item (but that's dreams in the current world of TB, and also not too consistent with the rest of our UI; would need a new bug) b) allow selection of result items and provide centralized buttons on top or bottom (would need a new bug; unlikely, requires redesigning faceted search which has never seen much design care since it's inception, so it has remained a visual and functional alien in the otherwise clean UI of TB ever since) c) display such information in tooltips somewhere (more likely, see below, needs new bug) > but a tooltip with more > detail about a message on mouseover might be nice. also, if you want to know > what messages are in folder X, you click on a folder name in the facet > section on the left and the list of messages will be filtered on a folder > name. That's useful ideas, but not sufficient to solve reporter's problem, which is the other way round: Reporter looks at message X and wants to know in what folder it is located (for which filtering against each folder of all search results is not a very efficient solution...) Wayne, I like the idea of providing more information about the message from faceted search results (or, in analogy, on the single msg header pane in conversation views), can you be more specific e.g. about the tooltip so that we might evolve that into a followup bug? To conclude, imo everything from comment 0 has been covered by existing bugs. So let's see if there anything uncovered in comment 2: (In reply to Miles from comment #2) > 2) It would be best if the locations/folders were listed in the faceted > results page (It certainly looks like a drop down list to me, whatever you > may call it!) -- this would alleviate having to take a 2nd step going into > the "search results message list." That's covered in my explanations of this comment, above (depending on the details, wontfix or covered by other bugs listed above). > 3) Regarding b) Personally I find it difficult to decipher (actuate) the > contents of that tab or pane; mousing over the list of related messages > (participants as well as the actual msg?) with identification of each entry > might simplify a search for a message in a particular folder. This is about faceted search results, and yes, it's one of the worse parts of TB's UI. However, that needs new bugs with specific suggestions for improvement. OT: I like the idea of making facet results more useful by adding tooltips to some of the information presented. To begin with, we really need a tooltip revealing the sender's email address, when hovering sender's display name taken from address book, on the right of result items. We also need a meta bug aka fsUXtracker for UI/UX improvements of that strange animal (faceted search results), in structural analogy to attachuxtracker (Bug 579473). I might do that when I find the time. > 4) Why is it that all relative messages are not listed in the faceted > search page, forcing one to open a new tab and then open areas within that > tab to view additional information? Again, that's beyond this bug. Pls remember to adhere to "one issue per bug" whenever possible. I'll break that rule right now to answer your questions anyway... OT: There might be a number of reasons for 4): - By default, facet search results limits number of results to 400 (just saw a bug for that), and then only shows a handful of those with a "More..." button to reveal more. - By default, facet search results are ordered by relevance iirc. So depending on search words, e.g. found in body text, more relevant msg will be on top, while other msgs of same thread might be hidden behind "more..." button. - More so if sorted by Date, old messages might be hidden. - There's a number of bugs about global/faceted search not finding things as it should (see meta Bug 541349 aka glodafailtracker). Proposed resolution for this bug (phew, a hard one...) So afaics, all the original/core problems of this bug are covered. So I'd like to close it as a duplicate of centralized Bug 686851, which will go a long way in addressing the problems mentioned in this bug. Miles (reporter), thank you for your contribution, which was helpful and inspiring after all, in spite of some shortcomings. Is it OK for you if we close this as a dupe of Bug 686851? Finally, apologies for the length. Unusual bugs require unusual measures... ;)

http://gsfn.us/t/btpd is about bug 686851 some people (like me) really do only want to SEE the folder location. I've linked this bug to http://getsatisfaction.com/mozilla_messaging/topics/global_search_results_in_which_folder So I think we keep this bug open?

(In reply to Wayne Mery (:wsmwk) from comment #8) > http://gsfn.us/t/btpd is about bug 686851 > > some people (like me) really do only want to SEE the folder location. That's a legitimate desire. > So I think we keep this bug open? I don't think that's a good idea, because description isn't good enough, at all. Wrong terminology, and talking about too many different things at a time, as explained in my previous comments. Wayne, please file a new bug with specific suggestions where exactly you'd want to see the folder location in faceted search results (first results tab), and/or a call for ideas. Pls ensure to make it distinctly about *seeing* the folder name (to contrast with existing bugs).