09 — User Behaviour (Search Module)
- 1. Typing behaviour
- 2. Query vocabulary by intent
- 3. Result-consumption behaviour
- 4. Zero-result behaviour
- 5. Failure-tolerance behaviour
- 6. Freshness expectations
- 7. Power-user patterns
- 8. Behavioural metrics (proposed)
Observed and designed-for behavior patterns around global search. Backend behaviors cited with source; client behaviors
(proposed).
1. Typing behaviour
- Users type partial, unordered tokens ("rah sharma" for Rahul Sharma).
- Mongo
$texttreats space-separated tokens as AND-ish word search; the fallback regex treats the whole string as one substring (search-index.repository.ts:24-50) — so multi-word partials behave differently between paths. Debounce (300 ms, 06 §1.3) absorbs bursts. - Users do not press Enter; they expect live results (submit exists but is secondary).
2. Query vocabulary by intent
| Intent | Query shape | Matched fields (indexer) |
|---|---|---|
| Find a person | name fragment | title = name / firstName+lastName (search-indexer.service.ts:68-75) |
| Find by roll/admission no | ADM-2024-118 | title = admissionNumber (:71) |
| Find by email | sharma@ | description = email (:77-79) |
| Find a book | title words / author | title, description (:68-81) |
| Find an announcement | keyword | description = body (:80) |
| Find by department/grade | "grade 5", "science dept" | tags = role/department/grade (:83-86) |
3. Result-consumption behaviour
- Users scan group headers first, then the top 2–3 rows per group — group order matters (people-first proposal in 06 §2.3).
- Users rarely go past page 1 of the aggregate; they use "See all" for a type when they need depth (05 §3).
- Result count is an expectation cue: with
meta.totalItems(search.service.ts:59) users expect a total, but per-type counts are per-page only (search.service.ts:44-49) — copy must not claim totals (07 §3).
4. Zero-result behaviour
- Users re-type with fewer words (fallback regex substring helps here —
search-index.repository.ts:36-50). - Users then clear and try a different field (email vs name). Landing chips (07 §6) pre-empt this by advertising the field vocabulary.
5. Failure-tolerance behaviour
- Server auto-fallback (
search.service.ts:35-41) means users see results even when$textbreaks — most users will never observe the fallback. - When offline: users retry on connectivity restore (banner + retry, 06 §2.5); cached last results are acceptable interim state (00-shared/10 §2).
6. Freshness expectations
- Users expect immediate visibility of edits: rename a student → search
shows the new name (event-driven upsert,
search-indexer.service.ts:90-96). - Hidden surprise: leads and announcements never re-sync on update/delete
(
search-indexer.service.ts:29-31) — stale rows persist; mitigate with the(planned)reindex job and surfaceupdatedAt(06 §5).
7. Power-user patterns
- Keyboard
/to focus the bar,Escto clear (desktop — 06 §6). - Direct deep links into
/search?q=(forward-looking)from notifications/push(forward-looking)— ledger B3. - Scanning a printed admission number into the bar
(forward-looking)— ledger B4.
8. Behavioural metrics (proposed)
| Metric | Definition |
|---|---|
| Search latency p95 | time from debounce fire → results rendered (< 1 s target) |
| Zero-result rate | empty responses / total searches (search.service.ts:28-30 path excluded) |
| Fallback rate | how often the regex path is hit (search.service.ts:38-41) |
| See-all usage | drill-downs per session (05 §3) |
| Refinement rate | queries changed before any tap |