There are two possible models that we can use for the basic Flow search UI, and we have to figure out which one we're going to use.

Let's say we're looking at a board with 200 threads, currently sorted by most recently active. Topics #1-10 are loaded on the page. The keyword that we're looking for has matches in five topics -- #7, #59, #63, #108 and #130 (according to the current sort).

The two models:

Search is like Control-F. You click the Search button, and you're scrolled to topic #7 for the first keyword match. #1-10 are still loaded on the page. If you scroll down, you'll see topic #8, which doesn't have a keyword match. To get to the next keyword match, you click the > button, and you jump to #59. There's the usual gap handling, as if you'd jumped to #59 by using the ToC. Nothing has to reload; you're still on the same page where you started the search. When you open the ToC in this view, you see just the five keyword-matching topics.

Search is like Gmail. You click the Search button, and you see a view that's only got the five topics with keyword matches. (This could be a refresh of the board, or a modal on top of the board.) You see the first match, topic #7. When you scroll down, you'll see #59, then #63, and the rest of the topics with keyword matches. When you open the ToC in this view, you see just the five keyword-matching topics.

Pau's current plans are based on the Control-F model. I think the Gmail model makes more sense, for the following reasons.

• One of the core concepts behind Flow is that the board is just a container for topics. Topics can be resorted, filtered, moved from one board to another, or displayed on multiple boards and feeds. The specific list of 200 topics you're seeing on this board is just the view that you're currently seeing. I think the Control-F model is based on the idea that this is a "page" that needs to be preserved in its current form.

• Reading the first keyword-matching topic, there are three ways to get to the next one -- scroll down, use the ToC dropdown, or hit > in the header. The ToC dropdown and > would work the same with either model. But I think scrolling is the most natural way to get from one to the next -- you're probably already scrolling to browse through topic #7. In the Control-F model, you scroll down to #8, which is not relevant. In the Gmail model, you scroll to #59, the next keyword-matching topic.

• The in-search ToC described in T99786: Show matching topics when searching a Flow board uses the Gmail model, only showing the matching topics.

• Filtering and feeds are going to use the Gmail model. This basic search is just a filter for the keyword-matching topics. When we introduce filters in the Control-F model, would we still show people highlights on the full board?

• The Control-F model introduces gap handling, as we do with the ToC. Obviously, this isn't a deal-breaker, because we already accept gap handling with the ToC, but it's awkward and I think we're better off without it. If we just show the 5 keyword-matching topics, we don't have to worry about it.

So that's why we had the conversation that led to this ticket. What are the advantages of the Control-F model?

My main opposition when we discussed this was for the idea of having a modal that basically duplicates the information, affects the fluency of the search process and is not clear how it will play with further filtering, among other problems. I think the two main options that are presented above are not that distant and can be summarised as whether to (a) keep the results that do not match the search query or (b) hide them.

Keep the non-matching results (referred as the Control-F model) has the following advantages from my point of view:

• Preserving context. Reorientation has a cost for the user. Presenting the search results as an overly over the current view does not require the user to figure out why the current view has heavily changed. This facilitates the use of search as a supporting action for other tasks in a fluent way: search for "blue screen error" to make sure no other answer is there for the topic and reply to the present topic without even clearing the search (as opposed to going back from search result mode). If topics keep appearing and disappearing as the user adjust the search, chances for the user to get lost increase.
• Search as soon as you can. Searching as the user types is a common pattern to make the searching experience more fluent. Search engines and browsers have adopted this pattern for a reason: users want to find stuff as quickly as possible. Searching involves to write a partial query, modify it to make it more specific and correcting it. During all that process, with the "Control-F model", the highlight overly changes and some scrolling is produced that seems to work for users where this model is used. If we consider hiding content, the changes in the view are more heavy (I'm especially worried when approaches such as "reloading" or having an "modal" are mentioned which imply in some way that the full search query needs to be completed and explicitly launched before results are shown). Whichever is the model, I think it is important to be able to show results to the user the as soon as possible.
• Interaction with filtering. Applying filters result in a filtered view, search is presented as more lightweight way to check for information. A user can filter a given board to show topics created today. Then, search to check how many are about "moais". The filter (topics created today) still apply and the search highlighting will happen only for those items.
• Limitations can be solved. Not hiding the unmatched topics has the cost of having content not relevant to the matches in between. However, providing an overview of the matches and facilitating navigation seem to work well when this model is applied. According to research, users are already familiar with browser-based search which provides a similar experience. In addition, these mechanisms may be needed anyways even if non-maching topics are hidden since long posts may have multiple matches or a considerable amount of content between matches too. Collapsing non-matching topics can be also an intermediate approach worth evaluating.
• Avoid premature optimisation. As Donald Knuth said "premature optimization is the root of all evil". Even if we need to consider complex gap handling strategies in the long term, would it be possible to have some shortcut (e.g., preload the whole ToC when searching) to support the given model and check how it feels with real content? Are the existing Flow boards so big that we cannot even try both (hidding and not-hidding non-matching posts) in any of them? Using the models in some real scenarios can be very informative.

To illustrate the benefits of the approach in a specific example. In the board below, I'm looking for conversations about the "dashboard", as soon as I wrote "dashb" I saw that the matches are relevant and I can easily scroll to the posts where those 13 matches are, adjusting the search query a bit in the process (without the content suddenly changing) if needed. I'm automatically moved to the first match which tends to be the most relevant of the current view (the most recent match).

In short, I think that we should aim for a very fluent experience with search. I think that providing results as early as possible is a must for the Flow search experience. I think that for achieving the above with minimal reorientation efforts and user confusion it is better to present search as highliglts over the current view and not heavily affecting it. However, I'm open to try hiding (totally or partially) the non-matching items as long as we don't sacrifice the immediacy of search results and we evaluate it properly with users to identify the potential issues.

In T106551#1487820, @Pginer-WMF wrote:

• Interaction with filtering. Applying filters result in a filtered view, search is presented as more lightweight way to check for information. A user can filter a given board to show topics created today. Then, search to check how many are about "moais". The filter (topics created today) still apply and the search highlighting will happen only for those items.

However, it's fair to ask whether users will understand this distinction. Will they see filtering and search as separate steps (and you search within the filtered posts)? Or will they see search as a filter that acts differently from the other filters?

• Limitations can be solved. Not hiding the unmatched topics has the cost of having content not relevant to the matches in between. However, providing an overview of the matches and facilitating navigation seem to work well when this model is applied. According to research, users are already familiar with browser-based search which provides a similar experience. In addition, these mechanisms may be needed anyways even if non-maching topics are hidden since long posts may have multiple matches or a considerable amount of content between matches too. Collapsing non-matching topics can be also an intermediate approach worth evaluating.

Yes, collapsing non-matching topics is definitely worth considering if we go with the Control-F solution. Then again, it may not be necessary if we make it easy to use the > arrow (or a keyboard shortcut for that) in the header.

• Avoid premature optimisation. As Donald Knuth said "premature optimization is the root of all evil". Even if we need to consider complex gap handling strategies in the long term, would it be possible to have some shortcut (e.g., preload the whole ToC when searching) to support the given model and check how it feels with real content?

There are no known performance problems with the Control-F approach. It can be implemented quite simply (although we may want to go back to the version before 4f2588400675265da81417b957eacfdb0334643d (the prior output worked better for the Ctrl-F version, I think). Basically, we just do the search, then highlight the current page using the search results. Gap handling would use the view-topiclist API, not the search API, and is already implemented.

To illustrate the benefits of the approach in a specific example. In the board below, I'm looking for conversations about the "dashboard", as soon as I wrote "dashb" I saw that the matches are relevant and I can easily scroll to the posts where those 13 matches are, adjusting the search query a bit in the process (without the content suddenly changing) if needed. I'm automatically moved to the first match which tends to be the most relevant of the current view (the most recent match).

The current search API does not work like this. It's based on understanding words. So for example, if you search 'dashboards' or 'dashboard', it will find 'dashboard'. 'dashb' is not a word in use, though (and nor is dashbs, etc.), so it will not find a match.

I understand the utility of this aspect, but if we consider it a requirement it needs to be estimated separately.