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.
Overall search interface
It's likely best to display the
TextInputbox 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
TextInputbox 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.
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_sdkdoes offer thesearch_events::v3module for performing a general text search.One should be able to create a new
search_events::v3::Requestusing the search terms to populate theCategoriesandCriteriastructs' fields, and then fire off that request using theClient::send()function.