Design Principle
A library page is not valuable because it shows many cards. It helps users move from fuzzy intent to a callable item while preserving source, quality, category, and next action.
Large Theory
Knowledge and asset libraries are both external memory for agents and audit surfaces for human maintainers. They must support search and browse together: search helps when users know what they want, while categories and facets help when they do not. A mature library page makes query, active filters, result count, sorting, matched excerpts, item quality, and empty-result recovery visible instead of flattening everything into a wall of cards.
Small Points
- Provide search input and result count near the top so users understand scope and feedback speed.
- Category, tags, resource type, license, quality score, and status should become facets or tabs instead of hiding inside card copy.
- Active filters must be visible, removable one by one, and resettable together; on mobile they can live in a tray, but result count should remain visible.
- Cards need title, category, tags, matched excerpt or summary, quality/source signal, and primary action; not only a decorative cover.
- Empty results should explain the current constraints and offer paths such as changing query, removing filters, viewing popular categories, or creating an item.
- Detail pages should preserve return context: same query, filter, scroll position, or at least same tab/category.
Design Judgment
A library is callable infrastructure when users can move from a fuzzy query to a concrete skill, knowledge item, or asset, understand why it is trustworthy, use it, and return to the list. If users can only scroll a card wall, it is content display, not retrieval UX.
Implementation Notes
Persist query state such as tab, q, category, tag, license, and sort in the URL. Show result count for server or client filtering. Display highlighted or extracted matched excerpts when search is active. Use chips for filters. Empty states include reset and query suggestions. Detail links preserve return state. RAG management views should expose item slug, section, score, source, quality, and recent hit events.
Counterexamples/Risks
Search changes do not update the URL, mobile filters hide result count, empty state only says No results, cards lack source and quality signals, returning from details loses scroll/filter state, and token matching uses naive substrings so Rive matches driven.
Case Study
A List Apart describes faceted navigation as a master pattern that affects the entire information architecture because it tightens the relationship between search and browse. NN/g distinguishes filters and facets, noting that facets help users discover attributes they might not otherwise think of. Carbon's Search and Empty states patterns require useful loading/empty copy and help users adjust search or filters. Atlassian Empty State similarly emphasizes explaining what users can do next. The reusable lesson is that a library page is not just search plus cards; it is a recoverable, explainable exploration state machine.
Source Links
A List Apart Faceted Navigation: https://alistapart.com/article/design-patterns-faceted-navigation/ NN/g Filters vs. Facets: https://www.nngroup.com/articles/filters-vs-facets/ NN/g User Intent Affects Filter Design: https://www.nngroup.com/articles/applying-filters/ Carbon Search Pattern: https://carbondesignsystem.com/patterns/search-pattern/ Carbon Empty States: https://carbondesignsystem.com/patterns/empty-states-pattern/ Atlassian Empty State: https://atlassian.design/components/empty-state
Agent Directive
When generating library pages, design search, facets, active filter chips, result count, matched excerpt, empty recovery, and detail return state together; do not output only a card grid.