Search messages in a room, both local and remote

[kevinaboos]

Overall search interface

It's likely best to display the TextInput box for search terms at the top of whichever view the search results will be shown in. That is, if the search results will be shown in a separate pane on the right side of the room's timeline view, then the search box should be at the top of that pane on the right. But if the search results will be shown in the same view as the room's timeline, then the search box should be at the top of that main room timeline view.

My personal opinion is that we should adopt the first design of having both the search input box and the search results in a separate pane on the right side of the room timeline. This allows the user to view the room timeline content while perusing the search results separately, which is sometimes necessary in order to have the context of both current messages and search results visible simultaneously.

Element shows the search box in a pane on the right, but confusingly it violates the guideline mentioned above by showing the search results in the same window as the existing room timeline, which hides the room timeline while the results are being shown. There's nothing technically wrong with this, but I feel it makes things harder to use.

Displaying search results

Element also shows the results in chronological order, with older messages towards the top and more recent messages at the bottom. I find this confusing, and in Robrix we should show the results in reverse chronological order, in which the most recent messages matching the search terms are displayed towards the top.

Each search result should be shown as a snippet of the message containing the matching terms, with the matching term(s) highlighted or otherwise identified in a clear manner. The snippet shouldn't be more than a few lines long, e.g., 3-4 lines at the most.

Clicking on the message should jump the room's timeline view with that message focused in the middle of the timeline viewport, and highlighted with a distinct background color. The highlight should be shown for either a fixed time duration (e.g., 10 seconds), or for as long as the message remains on the screen, but not permanently.

Activating the search interface

There should be a search/find icon at the top of the Room Screen (in the header), ideally using the typical magnifying glass 🔎 as the icon.
Search should be activated by clicking this icon button, which will display the search pane and place captured focus on the search TextInput box such that the user can begin typing the search terms with ease.

In addition, search should be activated when the room screen view "has focus" (has captured keyboard focus) or by pressing the keyboard shortcut Ctrl+F on Windows/Linux and Cmd+F (⌘+F) on macOS.

Note that if the main Rooms List screen is shown, pressing Ctrl+F should not display the room message search pane. Instead, it should shift focus to the room search TextInput box at the top of the Rooms List to allow the user to being typing room name search terms.

Implementation

There isn't yet high-level SDK support for searching messages, as far as I can tell (but perhaps I've just overlooked it).

However, the ruma crate re-exported by matrix_sdk does offer the search_events::v3 module for performing a general text search.

One should be able to create a new search_events::v3::Request using the search terms to populate the Categories and Criteria structs' fields, and then fire off that request using the Client::send() function.

[smarizvi110]

I couldn't find some high level support for searching through messages either. As for the layout, I assume then you'd prefer the sort of layout Discord has for searching? In fact, it allows for sorting through oldest and newest. From what I could gather, it fetches the list from the server every time you click on newest or oldest, at least based on latency for getting that list of messages. It also seems to have a "relevance" options, but I'm not sure about what that actually means.

[kevinaboos]

I couldn't find some high level support for searching through messages either.

yes, as I mentioned in the Implementation block in the original issue post, we'll need to use the search_events::v3 module to perform a general text search. Once you create a new search_events::v3::Request using the search terms to populate the Categories and Criteria structs' fields, you can send off that request using the Client::send() function and obtain the response.

As for the layout, I assume then you'd prefer the sort of layout Discord has for searching? In fact, it allows for sorting through oldest and newest. From what I could gather, it fetches the list from the server every time you click on newest or oldest, at least based on latency for getting that list of messages. It also seems to have a "relevance" options, but I'm not sure about what that actually means.

I also mentioned this in the original issue posting, but yes, the Discord-style search interface and UI is what we'd like to imitate.

[smarizvi110]

I couldn't find some high level support for searching through messages either.

yes, as I mentioned in the Implementation block in the original issue post, we'll need to use the search_events::v3 module to perform a general text search. Once you create a new search_events::v3::Request using the search terms to populate the Categories and Criteria structs' fields, you can send off that request using the Client::send() function and obtain the response.

As for the layout, I assume then you'd prefer the sort of layout Discord has for searching? In fact, it allows for sorting through oldest and newest. From what I could gather, it fetches the list from the server every time you click on newest or oldest, at least based on latency for getting that list of messages. It also seems to have a "relevance" options, but I'm not sure about what that actually means.

I also mentioned this in the original issue posting, but yes, the Discord-style search interface and UI is what we'd like to imitate.

Thanks for the feedback! I'd like to try my hand on this issue!

[smarizvi110]

@kevinaboos Just dropping an update. I've been independently playing around with makepad and Rust to better understand this, as well as a little with the matrix SDK. I understand this is quite a time consuming way to fix an issue, so I'm perfectly fine with anyone else working on this alone or with me if you'd like to expedite it despite the later deadline of the respective milestone. As always, I'm happy to get feedback and help to better learn. Thanks!