[AlexAndBear]

Description

Experimental, meant for trying it out. The search term entered in the global search is also matched against tags, so typing a tag into the search bar finds the resources that have it. Each result shows why it was found: the found content and the matching tags.

• Tag search: the search term also matches tags (tag:"*term*"), only if the server supports it (search.property.tag) and not in "Title only" mode.
• Shared query: the search bar preview and the results page build the query the same way (buildSearchTerm).
• Why found: each result shows the found content and the matching tags, also for tags picked in the "Tags" filter.
• Match stays visible: in the one-line found content, the text before the match is cut off instead of the match.
• OcTag: new xsmall size.
• Tests: unit tests and a new e2e scenario in fullTextSearch.feature.

Tags match as substrings and case-insensitively (alpha finds the tag Project Alpha), like names.

Search for apollo: Protokoll-Teamsitzung.txt matches by tag, Apollo-Roadmap.md by name, Angebot-Nordwind.txt by content.

Search bar preview	Results (tiles)

Known limitations (to evaluate before a production release)

• Open design questions on how the found content and matching tags are shown: feat: search for tags in the global search and enhance the visually reasoning for matching results #3558 (comment) (question 2, the cut off match, is solved: feat: search for tags in the global search and enhance the visually reasoning for matching results #3558 (comment))
• More results / ranking. Because tags match as substrings, short terms also hit longer tags (test → testing). There is no weighting of name vs. content vs. tag in the query, the ranking comes from the search service.

Related Issue

• Refs Improve tag discoverability: add a Tags view and tag filtering #3284 (comment)

How Has This Been Tested?

• test environment: local dev server (pnpm vite) against the docker-compose backend, Chromium at 1440px and 412px
• test case 1: a file whose name and content don't contain "test" but that has the tag testing is found when searching for "test", in the search bar preview and on the results page
• test case 2: KQL checked against the server: tag:"*test*" finds testing, tag:"*alpha*" finds Project Alpha, matching is case-insensitive, tag:"test" (without wildcards) only finds exact tags
• test case 3: found content and matching tags in the search bar preview, the results list and tiles; selecting a tag in the "Tags" filter shows it as matching tag
• test case 4: exploratory Playwright run for the cut off snippet: tiles in every grid size (also via the "Grid size" slider) at 900/1400/1920px, list view while resizing, open sidebar, search bar preview on desktop and mobile, dark mode; match at the start, middle and end, multiple matches, short content, special characters. The first match was fully visible in every result
• test case 5: unit tests (pnpm test:unit --run, all passing), vue-tsc --noEmit
• test case 6: e2e search shows why a resource was found passes in Chromium (as in CI) and fails with the previous snippet truncation

Types of changes

• Bugfix
• Enhancement (a change that doesn't break existing code or deployments)
• Breaking change (a modification that affects current functionality)
• Technical debt (addressing code that needs refactoring or improvements)
• Tests (adding or improving tests)
• Documentation (updates or additions to documentation)
• Maintenance (like dependency updates or tooling adjustments)

[AlexAndBear]

@tbsbdr fyi

[AlexAndBear]

Screenshots for a product decision: the search now shows why a file matched — the found content (as on the search page) and the matching tags. Example search term: apollo.

• Apollo-Roadmap.md → matches by name
• Protokoll-Teamsitzung.txt → matches by tag ("Apollo")
• Angebot-Nordwind.txt → matches by content

Search preview (global search bar)

Search results – list view

Search results – tiles view

Open questions

1. List view: the matching tag is shown twice — in the tags column and below the match. Keep it, or show the match line only in the preview and tiles?
2. Tiles view: the found content is truncated to one line, so the highlighted term may be cut off (see Angebot-Nordwind.txt). Should we center the snippet around the match or allow two lines?
3. Highlighting style: content matches use the yellow marker, tag matches use the bold style of the file name. Is that fine?

[LHBL2003]

Open questions

1. Display in the list view: In my view, it is sufficient for the search result to be displayed once, for example in the ‘Tags’ column, provided that this column cannot be hidden.
2. Tile view: If the item found can be centred automatically, it would be helpful to see straight away exactly what has been found.
3. I particularly like the idea of highlighting the result in yellow. This helps the human eye to quickly focus on the exact location found. As far as I know, this also corresponds to the standard way of displaying search results in PDF files, which I find very helpful there too.

Especially on the iPhone, it’s often difficult to actually spot the matched section within a page when working with PDF files. I therefore generally find visual highlighting of search results very helpful. I find that many other products lack this kind of support for quickly locating search results. That’s why I think it’s very good from a user’s perspective.

[AlexAndBear]

Open questions

1. Display in the list view: In my view, it is sufficient for the search result to be displayed once, for example in the ‘Tags’ column, provided that this column cannot be hidden.
2. Tile view: If the item found can be centred automatically, it would be helpful to see straight away exactly what has been found.
3. I particularly like the idea of highlighting the result in yellow. This helps the human eye to quickly focus on the exact location found. As far as I know, this also corresponds to the standard way of displaying search results in PDF files, which I find very helpful there too.

Especially on the iPhone, it’s often difficult to actually spot the matched section within a page when working with PDF files. I therefore generally find visual highlighting of search results very helpful. I find that many other products lack this kind of support for quickly locating search results. That’s why I think it’s very good from a user’s perspective.

Display in the list view: In my view, it is sufficient for the search result to be displayed once, for example in the ‘Tags’ column, provided that this column cannot be hidden.

It will be hidden on small screens and we only show 2 tags at a time, everything else is hidden under a + button, expanding the right sidebar. In general, I like the idea of having the "reasoning" or "why has this item been found" in the same place (Name, Content, Tags)

I particularly like the idea of highlighting the result in yellow. This helps the human eye to quickly focus on the exact location found. As far as I know, this also corresponds to the standard way of displaying search results in PDF files, which I find very helpful there too.

@tbsbdr @kulmann What do you think, we could change the appearance for search results across the whole ui, wouldn't cause any harm but make it even more visible on smaller screens (we have a lot of those search inputs, nowaydays). That's being said, its not that visually appealing IHMO. (out of scope for this pr)

[AlexAndBear]

Regarding open question 2 from #3558 (comment):

Tiles view: the found content is truncated to one line, so the highlighted term may be cut off (see Angebot-Nordwind.txt). Should we center the snippet around the match or allow two lines?

Implemented centering in 535507d: the found content is split at the first match. The text before the match is cut off at its start (…), and the match plus the following text is cut off at its end. The text before the match only takes the remaining space, so the match itself is always fully visible. The snippet stays on one line, so tiles keep their height.

Angebot-Nordwind.txt (tiles)

Tiles, grid size 2: match at start, middle, end, multiple matches, short content

Tiles, smallest grid size (1920 px wide)

List view

Search preview (mobile)

Tested (Playwright, Chromium)

For every result, the first match was checked to be fully visible and not covered by the ellipsis, the snippet to stay on one line, and nothing to overflow the tile or row.

• Tiles at every grid size (URL parameter and the "Grid size" slider in the view options), at 900, 1400 and 1920 px width
• List view at 1400 and 900 px, and while resizing the window from 1400 to 600 px
• Tiles with the sidebar open
• Search preview in the global search bar, desktop and mobile
• Mobile (Pixel 7): tiles and list view
• Dark mode
• Content: match at the start, in the middle and at the end, multiple matches, very short content, special characters and punctuation
• Regressions: name-only matches (no snippet), tag filter only, tag filter combined with a search term

[LHBL2003]

In general, I like the idea of having the "reasoning" or "why has this item been found" in the same place (Name, Content, Tags)

If the consider the area below the filename in the “Name” column as the place that explains why a search result was found, then listing the matching tags there makes perfect sense as well.

I would just suggest a minor visual adjustment: in my opinion, it would look clearer if the search results below the file name were indented at least as far as the file name itself. Ideally, the search result information could also be marked with a small search result icon – such as a magnifying glass with a text symbol – similar to the folder label.

[AlexAndBear]

In general, I like the idea of having the "reasoning" or "why has this item been found" in the same place (Name, Content, Tags)

If the consider the area below the filename in the “Name” column as the place that explains why a search result was found, then listing the matching tags there makes perfect sense as well.

I would just suggest a minor visual adjustment: in my opinion, it would look clearer if the search results below the file name were indented at least as far as the file name itself. Ideally, the search result information could also be marked with a small search result icon – such as a magnifying glass with a text symbol – similar to the folder label.

Good point, it looks more clean that way

Edit Discussed with the team, that we won't show the icon but keep the indention, as it would create too much visual clutter

[JammingBen]

I found one related issue we already have on main, but maybe you could fix it here while you're at it? When filtering via a tag on the search result page and then reloading the page, the filter still applies, but the filter-chip for "Tags" lost its active state.

[LHBL2003]

Edit Discussed with the team, that we won't show the icon but keep the indention, as it would create too much visual clutter

I can’t give it a thumbs-up. It looks very good. I was also wondering whether the TAG symbol might be a bit too much. I think it’s great that the magnifying glass has gone down well in the text excerpt. And that there’s a good solution for the TAG layout.