We have some user experience issues with the new search that is going to eventually land in bug 474701. When beginning a search from the main mail window we are opening a tab by default to preserve the persons state (keeping the account/folder/message opened or closed as they are). However when in a search results tab a person is likely a person wishes to refine the current search results with additional search terms. At the same time someone may also, though less likely, want to open a new search, leaving the current search results as is. The disconnect between when we open a new tab and when we reuse the existing results view is not obvious to a person and so we need to make it that way. I think we can use a simple auto-complete display to explain the behaviour choices and correctly set a persons expectations. This auto-complete should be the default selection, much like a drop down selection is done on the mac, as a person types the first element is selected displaying text regarding the action that will be taken. In the default 'Mail' view where a new tab is always opened our default auto-complete widget will show the text 'Search in a new tab for "%s"' ex: [ Bryan ] | Search in a new tab for "Bryan" | '----------------------------------------' In a search results tab where the default is to change the search results instead of opening the search in a new tab our default auto-completer looks like this. [ Bryan Clark ] | Search for "Bryan Clark" | '----------------------------------------' In a search results tab where a person press and holds accel key (or presses accel-enter to start the search) we alter the default auto-completer to show the search results will be opening in a new tab. [ Bryan Clark ] | Search in a new tab for "Bryan Clark" | '----------------------------------------'

Given that the core tab stuff hasn't landed yet, I doubt this will be before m6.

I doubt this really blocks b3, pushing to b4, in case i don't get to it.

David, could you please give me an estimate on whether this bug would have an l10n impact or not?

Yes, this would be adding new strings for the auto-complete like "Search for %s"

Currently battling this one, cursing at JS components, but happy that glautocomp.js is still in the tree.

The current plan: 1) rework the quicksearch widget to have an additional "mode", which would be the gloda-backed faceted search. This will allow us to save vertical space (as opposed to the other options considered thus far), introduce the faceted mode in a common user path, but with a simple way for people to get back to the search model they are used to if they don't like it or if they're really trying to do filtering rather than searching) 2) provide autocomplete in that field when in gloda-backed mode This will likely be a two-stage landing.

This is now going on in the same pbranch described in bug 474711, and will land when that lands. Not sure what to do with this bug now, but I suppose it doesn't matter hugely.

Bryan, can you update this bug with your thoughts about what changes are needed for the search field now that we have the new merged quicksearch field? Having used it for a bit, I'm not feeling like the tab-creation is that problematic, but I may be too close to it to see. If it's not, maybe we should close this bug as FIXED? I do wonder whether we would want to auto-complete quick-search filtering operations from the "search everywhere" mode, to allow people to do a quick-search without having to toggle a mode, and easily w/ the keyboard. Not sure if that idea is good, and if good, TB3 blocking (I suspect it would require strings).

fyi, right now the autocomplete creates a new tab if 1) it's coming from a regular mail view, or 2) an autocomplete entry is selected. If we're in a faceted tab, and just type in new full-text searches, then we "reuse" the tab (actually destroy the existing one and create a new one, as a not-great shortcut)

Unfortunately this hasn't made the string freeze so we'll get it in the set of string changes post b4.

Bryan, we should make a call about this bug soon.

I'm not too concerned about this as I think the current behavior makes sense. From the recent user feedback I've received there was a greater issue that it wasn't obvious that tabs existed at all. I'd rather focus on that area than this for 3

Hmmm. I think I'd favour wontfix for this bug. There's better things you can do with autocomplete than to clutter with explanations for behaviour that should be obvious in itself. Tab behaviour should be organized in a way that it's predictable and transparent. E.g. Ctrl+Search should always open in a new tab. I'm not sure how good we are with the current behaviour. My feeling is we are creating too many search (result) tabs on the way. One thing I don't understand is why in non-mail-view tabs, global searching from autocomplete entries (results in new tab) behaves different from global searching with new words (results in same tab). IMO, both should open in same tab, unless user employs Ctrl modifier. What ye think?

blake, after reading comment 0, 12,13 I'm in tune with wontfix. I don't think we've seen support requests expressing confusion. unless someone (roland?) knows otherwise.

I (still) agree with Wayne that this is should be wontfix. I still see the problems mentioned in comment 13 (on a gloda results tab, refining search words by typing opens in same tab, while refining with autocomplete opens in a new tab, which I think is inconsistent), but this bug won't do anything to fix that. Moreover, explaining everyday application behaviour in autocomplete entries is a distraction from the actual purpose (searching) that is certainly violating UX-minimalism, while not adding much in terms of UX-discovery: After the first two uses of global search from main 3-pane I'll certainly remember that this type of search opens in a new tab, where refinements usually open in the same tab. FTR: We have tried the same explanation approach for Quick Search (with options showing "Filter for ..."), and it has been discarded for a reason. We wouldn't want Google to show "Search for <your search words>" each time we search, would we?

(In reply to Thomas D. from comment #13) > [A] I'm not sure how good we are with the current behaviour. My feeling is we > are creating too many search (result) tabs on the way. > [B] One thing I don't understand is why in non-mail-view tabs, global searching > from autocomplete entries (results in new tab) behaves different from global > searching with new words (results in same tab). IMO, both should open in > same tab, unless user employs Ctrl modifier. What ye think? Are there bugs for A and B.?

I think [A] (In reply to Wayne Mery (:wsmwk) from comment #16) > (In reply to Thomas D. from comment #13) > > [A] My feeling is we are creating too many search (result) tabs on the way. > > [B] One thing I don't understand is why... > Are there bugs for A and B? [A] I think this might be something along the lines of Bug 518336 - [faceted search]: Move "Open as list" button to the top-left of search results to toggle showing listview + oldstyle msg preview on the right of same tab -, or Bug 580252 - [Faceted Search]: Option to make "Open as List" view the default view [B] Bug 716058 Submitted - [Faceted search] Refining search terms *with autocomplete* from global search box above faceted search results should not open a new tab (re-use same / existing tab, as for typed modifications) File a bug, find some more for free... :( (In reply to Bryan Clark [:clarkbw] from comment #0) > In a search results tab where a person press and holds accel key (or presses > accel-enter to start the search) ... > the search results will be opening in a new tab. [C] Ctrl+global search should open results in a new tab Looking at Bryan's comment, I thought we already have this, but it doesn't work in TB9. Is it a regression? Anyway, I already filed that more than 2 years ago: Bug 516519 - [faceted search] Ctrl+Global Search ("Search all messages") should show search results in new tab (Ctrl+Enter, Ctrl+Autocomplete)

(In reply to Thomas D. from comment #17) The short version of comment 17: Everything covered, let's close this "wontfix".