A no data found HTML template should separate source loading from result count. This original local specimen has two records, a text filter and five display outcomes. The companion uses local fixtures and explicit source-state controls; it makes no network request.
Begin with source status, then inspect records
Carbon's pattern guidance distinguishes no-data, user-action/search-result and error-management situations and recommends contextual recovery. Adopt those distinctions without copying its illustrations or interface or claiming IBM tested this specimen. Carbon Design System: Empty States
The original supplied records are:
| Stable ID | Title |
|---|---|
| R1 | Draft sketch |
| R2 | Final outline |
They are fictional local data, not actual user documents. Source F1 is a successfully loaded two-record fixture; F0 is a successfully loaded empty fixture. A Loading or Failed fixture has unknown current records, not an empty array.
Evaluate source status first. Loading renders its pending message. Failed renders LoadError. Only Loaded proceeds to inspect dataset length and filter matches.
For Loaded, an empty dataset gives NoRecords. A nonempty dataset gives Results or NoMatches according to the query. This precedence prevents a retained query from turning a failed source into a purported zero-match result.
Keep five outcomes and their evidence visible
| Display state | Known source evidence | Original message/action |
|---|---|---|
| Loading | Outcome pending; records unknown | Loading fixture outcome; wait for explicit resolution |
| Results | F1 loaded; draft matches R1 | Show R1 and labeled match count |
| NoMatches | F1 loaded; zebra matches neither row | No matches for zebra; Clear filter |
| NoRecords | F0 loaded with zero records | No records supplied in this fixture; Choose fixture |
| LoadError | Source failed; current count unknown | Could not load source; Retry fixture |
These are local specimen messages, not observations of a network request. NoRecords means a known empty loaded source. LoadError means the current source could not provide a trustworthy count.
Do not turn a failure into Records: 0 by replacing unknown data with an empty array. Do not display the NoRecords message while Loading is still unresolved.
Make filtering preserve the source
Use trimmed, case-insensitive title substring matching for these local rows. Query draft matches R1, while zebra matches none. A blank query matches both supplied rows.
Clear filter changes the query to blank and recomputes from the same F1 records, restoring R1/R2. It does not create records, fetch a replacement source or restore deleted data.
Keep Source records: 2 separate from Matching records: 0 in NoMatches. Label the query so the user can see why two existing records are not displayed.
Source-state transitions and Retry retain the current query. Only an explicit Clear filter empties it; Reset intentionally returns to the original draft demonstration. Clearing a failed source's query does not change Failed into Loaded or recover data.
For F0, a nonblank retained query still yields NoRecords because there are no supplied records before filtering. Clear filter would leave that source empty, so it is not the primary recovery action there.
Offer an action with a real local effect
NoMatches offers Clear filter. NoRecords offers Choose fixture, moving focus to the supplied fixture selector; the user can choose the two-row fixture and inspect what it contains.
That selection is a specimen-source change, not a Create document operation. Do not place a fake Add record or Save button under the empty message if this prototype has no creation/persistence behavior.
LoadError offers Retry fixture. It changes Failed to Loading, hides unavailable results and waits for a manually selected outcome: loaded F1, loaded F0 or Failed again. A separate Resolve fixture outcome control commits that selection.
Selecting Loading directly also starts a pending local fixture. Every new pending fixture clears its outcome selection; Resolve requires a manually chosen F1, F0 or Failed outcome and otherwise changes nothing. Retry starts no real network request, automatic backoff or guaranteed success. If the chosen outcome is Failed, return to LoadError and keep the query. If loaded F1 resolves while query is zebra, the result is still NoMatches; successful loading does not mean the filter must find something.
Use only the error reason supplied by the fixture. Do not diagnose permissions, a missing route or a server outage without evidence.
Hide stale results while the source is unavailable
Start the demonstration with F1 Loaded and query draft. If the source changes to Loading or Failed, remove R1 from the current result area and replace the known match count with Unknown.
A retained previous fixture in an internal test ledger is not current source evidence. It cannot remain labeled Results while the new source is unavailable.
Preserve query text visibly during those transitions. The user needs to know which filter will apply when a loaded outcome is supplied. A stale NoMatches message must also clear when status changes to Loading.
Record source version/status, query, dataset count when known, match count when known, rendered message and recovery action together. Actual test observations remain blank until the implementation is executed.
Specify the transition matrix before the layout
| Original test path | Expected outcome |
|---|---|
| Loaded F1, draft | R1 only; source 2/matches 1 |
| Change query to zebra | NoMatches; source 2/matches 0 |
| Clear filter under F1 | R1/R2; source 2/matches 2 |
| Select Loaded F0 | NoRecords; source 0 |
| Select Failed with retained query | LoadError; counts unknown |
| Retry fixture | Loading; no stale rows/counts |
| Resolve F1 with zebra retained | NoMatches again |
| Resolve Failed again | LoadError again |
The fixture selector chooses source status/data; query input chooses the filter. Together they produce five display states. Query changes while Loading/Failed are retained but cannot produce current matches from unknown records.
Reset restores F1 Loaded, query draft, the exact two original records and no pending outcome. It cancels any prior fixture-resolution generation so an old completion cannot overwrite the reset state.
The matrix is a proposed expected trace, not a runtime report. No API, simulated random data or actual user records are required.
Keep the result region readable and test its controls
Use a concise title, source-state explanation, query and one appropriate primary action. Loading is not decorated with a success message; an error is not written as a joke or treated as first-time onboarding.
Native query/fixture/outcome controls, Clear filter, Retry fixture, Resolve outcome and Reset must each follow the declared guards. Retry is available only in LoadError; Resolve outcome only while a fixture is pending. Rapid repeat activations cannot create parallel outcomes.
Test keyboard/focus, message announcements and readability at production article width/360 px. The record titles are literal text, not markup inserted from data. No copied Carbon artwork or automatically certified accessibility is claimed.
Maintain native source and state tests together. A static empty card alone cannot demonstrate correct filter restoration or source recovery.
Copy this prompt to prepare the original result-state specimen
Create one complete, self-contained US-English HTML companion for “Documents · Source State Specimen”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Clear filter; Choose fixture; Retry fixture; Resolve fixture outcome; Reset demonstration. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Create complete original native HTML/CSS/JavaScript source and manual state matrix for a local result-state specimen. Reference https://www.carbondesignsystem.com/building-blocks/core/patterns/empty-states for contextual no-data/search-result/error recovery distinctions only. No copied IBM art/UI, actual network/request/backoff, user records or tested/accessibility-certified claim.
Fictional F1 loaded rows R1 “Draft sketch”, R2 “Final outline”; F0 loaded empty. Loading/Failed current records unknown, never coerced to []. Default F1 Loaded/query draft. Status first: Loading→Loading message; Failed→LoadError. Loaded empty→NoRecords before filter; Loaded nonempty→Results or NoMatches by query.
Trim/case-insensitive title substring. draft→R1/source 2/match 1; zebra→NoMatches/source 2/match 0; blank→both 2. Clear filter empties query/recomputes unchanged F1, not create/fetch. F0 remains NoRecords even with query. Query preserved across status/Retry; explicit Clear filter empties it, Reset intentionally restores draft.
Five messages: Loading fixture outcome pending; Results literal rows/labeled count; NoMatches names query/Clear filter; NoRecords no records supplied/Choose fixture; LoadError cannot load/count unknown/Retry fixture. No fake Add/Save, unsupported permission/server diagnosis, missing-route or zero count for failure.
Native source selector (Loading/Loaded F1/Loaded F0/Failed), query field and matching state. Choose fixture focuses selector only. Retry fixture from LoadError→Loading; direct Loading selection also starts pending local fixture. Every new pending generation clears outcome selection. Manual outcome selector F1/F0/Failed plus Resolve commits chosen next state; missing outcome changes nothing. Retry only Error, Resolve only pending, repeats create no parallel outcomes. Retain query; resolve F1 with zebra→NoMatches; Failed again→LoadError, no guarantee.
Unavailable Loading/Failed hides stale rows/empty messages/counts and labels counts Unknown; don't filter cached records as current. Query can change but matches stay unknown until Loaded. Ledger source version/status/query/known source count/known match count/message/action, actual test observations blank. Titles literal text, no HTML insertion.
Reset original F1/draft/two rows/no pending outcome; invalidate stale resolution generation. Test five states, status precedence, draft/zebra/Clear filter, empty with query, failure unknown, Loading/manual outcome validation/success/error, stale messages/counts, query retention, recovery guards and Reset. Actual source/controls/keyboard/focus/announcements/production article width/360 px/host checks pending; no code/HTML/capture built now. Keep the required native records authoritative; actual controls/functions need tests. No live data/sync/create/save promise.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# No Data Found HTML Template: Separate Empty, Filtered and Failed
A request fails, and the page says No records yet with an Add button. A user types zebra, gets no matches and concludes the source is empty. Both screens hide the state that determines the next useful action.
A no data found HTML template should separate source loading from result count. This original local specimen has two records, a text filter and five display outcomes. The companion uses local fixtures and explicit source-state controls; it makes no network request.
## Begin with source status, then inspect records
Carbon's pattern guidance distinguishes no-data, user-action/search-result and error-management situations and recommends contextual recovery. Adopt those distinctions without copying its illustrations or interface or claiming IBM tested this specimen. [Carbon Design System: Empty States](https://www.carbondesignsystem.com/building-blocks/core/patterns/empty-states)
The original supplied records are:
| Stable ID | Title |
|---|---|
| R1 | Draft sketch |
| R2 | Final outline |
They are fictional local data, not actual user documents. Source F1 is a successfully loaded two-record fixture; F0 is a successfully loaded empty fixture. A Loading or Failed fixture has unknown current records, not an empty array.
Evaluate source status first. Loading renders its pending message. Failed renders LoadError. Only Loaded proceeds to inspect dataset length and filter matches.
For Loaded, an empty dataset gives NoRecords. A nonempty dataset gives Results or NoMatches according to the query. This precedence prevents a retained query from turning a failed source into a purported zero-match result.
## Keep five outcomes and their evidence visible
| Display state | Known source evidence | Original message/action |
|---|---|---|
| Loading | Outcome pending; records unknown | Loading fixture outcome; wait for explicit resolution |
| Results | F1 loaded; draft matches R1 | Show R1 and labeled match count |
| NoMatches | F1 loaded; zebra matches neither row | No matches for zebra; Clear filter |
| NoRecords | F0 loaded with zero records | No records supplied in this fixture; Choose fixture |
| LoadError | Source failed; current count unknown | Could not load source; Retry fixture |
These are local specimen messages, not observations of a network request. NoRecords means a known empty loaded source. LoadError means the current source could not provide a trustworthy count.
Do not turn a failure into Records: 0 by replacing unknown data with an empty array. Do not display the NoRecords message while Loading is still unresolved.
## Make filtering preserve the source
Use trimmed, case-insensitive title substring matching for these local rows. Query draft matches R1, while zebra matches none. A blank query matches both supplied rows.
Clear filter changes the query to blank and recomputes from the same F1 records, restoring R1/R2. It does not create records, fetch a replacement source or restore deleted data.
Keep Source records: 2 separate from Matching records: 0 in NoMatches. Label the query so the user can see why two existing records are not displayed.
Source-state transitions and Retry retain the current query. Only an explicit Clear filter empties it; Reset intentionally returns to the original draft demonstration. Clearing a failed source's query does not change Failed into Loaded or recover data.
For F0, a nonblank retained query still yields NoRecords because there are no supplied records before filtering. Clear filter would leave that source empty, so it is not the primary recovery action there.
## Offer an action with a real local effect
NoMatches offers Clear filter. NoRecords offers Choose fixture, moving focus to the supplied fixture selector; the user can choose the two-row fixture and inspect what it contains.
That selection is a specimen-source change, not a Create document operation. Do not place a fake Add record or Save button under the empty message if this prototype has no creation/persistence behavior.
LoadError offers Retry fixture. It changes Failed to Loading, hides unavailable results and waits for a manually selected outcome: loaded F1, loaded F0 or Failed again. A separate Resolve fixture outcome control commits that selection.
Selecting Loading directly also starts a pending local fixture. Every new pending fixture clears its outcome selection; Resolve requires a manually chosen F1, F0 or Failed outcome and otherwise changes nothing. Retry starts no real network request, automatic backoff or guaranteed success. If the chosen outcome is Failed, return to LoadError and keep the query. If loaded F1 resolves while query is zebra, the result is still NoMatches; successful loading does not mean the filter must find something.
Use only the error reason supplied by the fixture. Do not diagnose permissions, a missing route or a server outage without evidence.
## Hide stale results while the source is unavailable
Start the demonstration with F1 Loaded and query draft. If the source changes to Loading or Failed, remove R1 from the current result area and replace the known match count with Unknown.
A retained previous fixture in an internal test ledger is not current source evidence. It cannot remain labeled Results while the new source is unavailable.
Preserve query text visibly during those transitions. The user needs to know which filter will apply when a loaded outcome is supplied. A stale NoMatches message must also clear when status changes to Loading.
Record source version/status, query, dataset count when known, match count when known, rendered message and recovery action together. Actual test observations remain blank until the implementation is executed.
## Specify the transition matrix before the layout
| Original test path | Expected outcome |
|---|---|
| Loaded F1, draft | R1 only; source 2/matches 1 |
| Change query to zebra | NoMatches; source 2/matches 0 |
| Clear filter under F1 | R1/R2; source 2/matches 2 |
| Select Loaded F0 | NoRecords; source 0 |
| Select Failed with retained query | LoadError; counts unknown |
| Retry fixture | Loading; no stale rows/counts |
| Resolve F1 with zebra retained | NoMatches again |
| Resolve Failed again | LoadError again |
The fixture selector chooses source status/data; query input chooses the filter. Together they produce five display states. Query changes while Loading/Failed are retained but cannot produce current matches from unknown records.
Reset restores F1 Loaded, query draft, the exact two original records and no pending outcome. It cancels any prior fixture-resolution generation so an old completion cannot overwrite the reset state.
The matrix is a proposed expected trace, not a runtime report. No API, simulated random data or actual user records are required.
## Keep the result region readable and test its controls
Use a concise title, source-state explanation, query and one appropriate primary action. Loading is not decorated with a success message; an error is not written as a joke or treated as first-time onboarding.
Native query/fixture/outcome controls, Clear filter, Retry fixture, Resolve outcome and Reset must each follow the declared guards. Retry is available only in LoadError; Resolve outcome only while a fixture is pending. Rapid repeat activations cannot create parallel outcomes.
Test keyboard/focus, message announcements and readability at production article width/360 px. The record titles are literal text, not markup inserted from data. No copied Carbon artwork or automatically certified accessibility is claimed.
Maintain native source and state tests together. A static empty card alone cannot demonstrate correct filter restoration or source recovery.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review: a reading copy of the state and recovery matrix
Keep the native result-state source and test matrix together. Use the companion to show why an empty source, unmatched query and failed load need different messages.
Verify actual filtering, fixture transitions, recovery guards and layout before presenting a working example. A saved empty-state panel does not establish that a source successfully loaded.
The useful screen explains what is known and offers the action that can change that specific condition.