logaritmisk/biggus-dickus
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases Wiki Activity

Frontend UX: search result rows lack type/date meta; single thin facet; "estimated" count not flagged #61

New Issue
Closed
opened 2026-06-06 18:53:14 +00:00 by logaritmisk · 1 comment
logaritmisk commented 2026-06-06 18:53:14 +00:00
Owner
Copy Link
Copy Source

Severity: Low–Medium. From a frontend UX audit. (The search screen is otherwise solid — URL-synced debounced query, visibility in the URL, infinite scroll, XSS-safe highlight.)

Problems

  • SearchResultRow (web/src/search/search-result-row.tsx:18-27) shows name + object_number + visibility badge + a 2-line snippet, but no object type/category or date — power users often disambiguate hits by type/period, not just name+number.
  • The only facet is the visibility filter (search-panel.tsx:64-80) — thin faceting for a collection.
  • The result total comes from Meilisearch's estimated_total but the copy is just "{{count}} results" (search-panel.tsx:108) — presented as exact when it's an estimate.

Suggested fix

  • Add object type (and a relevant date if available) to the result row's meta line; consider a type facet.
  • Soften the count copy to reflect estimation (e.g. "~{{count}} results") so users don't treat it as exact.

Source: frontend UX/design audit, 2026-06-06.

**Severity: Low–Medium.** _From a frontend UX audit. (The search screen is otherwise solid — URL-synced debounced query, visibility in the URL, infinite scroll, XSS-safe highlight.)_ ## Problems - `SearchResultRow` (`web/src/search/search-result-row.tsx:18-27`) shows name + object_number + visibility badge + a 2-line snippet, but no **object type/category** or **date** — power users often disambiguate hits by type/period, not just name+number. - The only facet is the visibility filter (`search-panel.tsx:64-80`) — thin faceting for a collection. - The result total comes from Meilisearch's `estimated_total` but the copy is just "{{count}} results" (`search-panel.tsx:108`) — presented as exact when it's an estimate. ## Suggested fix - Add object type (and a relevant date if available) to the result row's meta line; consider a type facet. - Soften the count copy to reflect estimation (e.g. "~{{count}} results") so users don't treat it as exact. _Source: frontend UX/design audit, 2026-06-06._
logaritmisk commented 2026-06-08 11:49:44 +00:00
Author
Owner
Copy Link
Copy Source

Done — merged to main (c68bbb9).

Date on result rows (the disambiguator the data actually supports): threaded recording_date (YYYY-MM-DD) through the whole search pipeline — SearchDocument (projected in build_document from object.recording_date) → SearchHit → SearchHitView (Rust) → the regenerated schema.d.ts. SearchResultRow now shows it on the meta line (Name · № · 1962-04-03) when present. Option end-to-end, so objects without a date — and already-indexed docs that haven't been re-indexed yet — simply omit it (new/edited objects index it automatically via the on-write sync_object; reindex_all backfills the rest).

Estimated count flagged: the count copy is now ~{{count}} results (en) / ~{{count}} träffar (sv), since it's Meilisearch's estimated_total — no longer presented as exact.

Declined (no data to support it): object type/category meta + a type facet — there is no type/classification field anywhere in the domain (objects have number/name/count/description/location/owner/recorder/recording_date/visibility + flexible fields). That would be a new domain concept — filed as a follow-up.

61 Rust (search+api) tests + 226 frontend tests green; clippy/fmt clean; typecheck/lint/build/check:size (215.5 KB gz)/check:colors clean; en/sv parity (guarded by the #60 test); no codename; no new dependency.

Follow-ups (out of scope): an object type/classification concept + type facet; a reindex CLI command to backfill recording_date onto already-indexed objects; making recording_date filterable/sortable in search; richer faceting.

Done — merged to `main` (`c68bbb9`). **Date on result rows** (the disambiguator the data actually supports): threaded `recording_date` (`YYYY-MM-DD`) through the whole search pipeline — `SearchDocument` (projected in `build_document` from `object.recording_date`) → `SearchHit` → `SearchHitView` (Rust) → the regenerated `schema.d.ts`. `SearchResultRow` now shows it on the meta line (`Name · № · 1962-04-03`) when present. `Option` end-to-end, so objects without a date — and already-indexed docs that haven't been re-indexed yet — simply omit it (new/edited objects index it automatically via the on-write `sync_object`; `reindex_all` backfills the rest). **Estimated count flagged**: the count copy is now `~{{count}} results` (en) / `~{{count}} träffar` (sv), since it's Meilisearch's `estimated_total` — no longer presented as exact. **Declined (no data to support it)**: object **type/category** meta + a **type facet** — there is no type/classification field anywhere in the domain (objects have number/name/count/description/location/owner/recorder/recording_date/visibility + flexible fields). That would be a new domain concept — filed as a follow-up. 61 Rust (search+api) tests + 226 frontend tests green; clippy/fmt clean; typecheck/lint/build/check:size (215.5 KB gz)/check:colors clean; en/sv parity (guarded by the #60 test); no codename; no new dependency. **Follow-ups (out of scope):** an object type/classification concept + type facet; a `reindex` CLI command to backfill `recording_date` onto already-indexed objects; making `recording_date` filterable/sortable in search; richer faceting.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
logaritmisk
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#61
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?