Help Content Registry
Component Detail
Description
Stores and serves inline contextual help texts keyed by screen identifier and field identifier. Loaded from a bundled asset so help content can be updated independently of widget code. Used by the InlineContextualHelpWidget throughout the app.
help-content-registry
Summaries
The Help Content Registry delivers contextual, screen-specific guidance to users exactly when and where they need it, without requiring them to leave the app or search documentation. This directly reduces user errors on complex forms and workflows, shortens onboarding time for new users, and decreases inbound support requests for common questions. Because help content is stored in a standalone bundled asset rather than embedded in code, the content team can revise, clarify, or localize help texts independently of engineering sprints — accelerating response to user feedback and reducing the cost of iterative content improvements. The component is shared across all screens, meaning this investment in user guidance scales to every part of the product.
The Help Content Registry is a low-complexity shared component with no external service dependencies, making it low-risk and straightforward to schedule. It should be delivered early so the InlineContextualHelpWidget can depend on it from the start. The primary coordination task is establishing the (screenId, fieldId) key schema in collaboration with UX and content teams before screens are built — late changes to this schema will require content asset updates. QA must cover graceful empty-string returns for missing keys, asset loading on startup, and runtime bundle reloading in development builds.
The content asset itself should be treated as a separate deliverable, maintained by content or UX, with a defined update and review process to prevent stale or missing help texts at launch.
The Help Content Registry loads a JSON asset at startup via `loadBundle(assetPath)`, populating an in-memory two-level map keyed by `screenId` then `fieldId`. The `getHelpText(screenId, fieldId)` method returns the matched string or an empty string if no entry exists — callers must handle the empty case gracefully. `hasHelpText(screenId, fieldId)` allows widgets to conditionally render help affordances only when content is available. `registerHelpEntry(screenId, fieldId, text)` supports test setup and development-time injection without touching the asset file.
The development runtime-reload path should use Flutter's hot reload hook to re-invoke `loadBundle` when the asset changes. Because this is a shared, stateless registry, it should be provided via a top-level `InheritedWidget` or service locator so all widget subtrees access the same instance without prop-drilling.
Responsibilities
- Provide help text by (screenId, fieldId) composite key
- Load help content bundle from a JSON asset at startup
- Return an empty string gracefully when no help text exists for a key
- Support runtime reloading during development
Interfaces
getHelpText(screenId, fieldId): String
loadBundle(assetPath)
registerHelpEntry(screenId, fieldId, text)
hasHelpText(screenId, fieldId): boolean