viafier/viafier4
1
Fork 0
Code Issues 7 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Improve catalogue search semantics and result transparency #10

New issue
Open
opened 2026-06-13 00:23:18 +02:00 by André Keller · 0 comments
André Keller commented 2026-06-13 00:23:18 +02:00
Owner
Copy link

Goal:
Make catalogue search more predictable and explainable. Current broad search can return useful results, but it is not clear to the user why an entry matched. For example, a query might match a prototype number, article number, product name or arbitrary text in a description.

Design notes:

  • Define an explicit list of searchable public fields.
  • Avoid searching long description fields by default.
  • Treat numeric searches carefully, so numbers do not accidentally match years, dimensions, prices or unrelated text.
  • Keep tags separate from free-text search.
  • Search should narrow the result list only.
  • Search should not affect available category/class/variant choices in the first iteration.
  • Search should not affect available tag suggestions.
  • Each search result should be able to explain why it matched.

Possible searchable fields:

  • prototype number / Betriebsnummer
  • vehicle or unit class name
  • vehicle or unit name
  • operator name
  • manufacturer name
  • product article number
  • product name

Possible UI improvement:
Show a small match reason on result cards when a search is active, for example:

  • Treffer: Betriebsnummer
  • Treffer: Artikelnummer
  • Treffer: Produktname
  • Treffer: Klasse

Implementation idea:
Instead of one broad Q(...) | Q(...) | ... search expression, model search as named clauses. Each clause has a public label and a query condition. The result list can then use the matching clause labels to render a short explanation.

Goal: Make catalogue search more predictable and explainable. Current broad search can return useful results, but it is not clear to the user why an entry matched. For example, a query might match a prototype number, article number, product name or arbitrary text in a description. Design notes: * Define an explicit list of searchable public fields. * Avoid searching long description fields by default. * Treat numeric searches carefully, so numbers do not accidentally match years, dimensions, prices or unrelated text. * Keep tags separate from free-text search. * Search should narrow the result list only. * Search should not affect available category/class/variant choices in the first iteration. * Search should not affect available tag suggestions. * Each search result should be able to explain why it matched. Possible searchable fields: * prototype number / Betriebsnummer * vehicle or unit class name * vehicle or unit name * operator name * manufacturer name * product article number * product name Possible UI improvement: Show a small match reason on result cards when a search is active, for example: * Treffer: Betriebsnummer * Treffer: Artikelnummer * Treffer: Produktname * Treffer: Klasse Implementation idea: Instead of one broad Q(...) | Q(...) | ... search expression, model search as named clauses. Each clause has a public label and a query condition. The result list can then use the matching clause labels to render a short explanation.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
devel
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
viafier/viafier4#10
No description provided.