← ClaudeAtlas

forms-and-controlslisted

Input design for data apps - period and date-range pickers, numeric and currency inputs, scenario assumption controls, segmented filters, search, validation timing, and control layout. Covers the finance-specific cases that generic form advice gets wrong. Trigger on "form", "input", "date picker", "date range", "filter control", "validation", "assumption input", "scenario slider", "dropdown", "search box".
Lukehle/chartroom · ★ 0 · Web & Frontend · score 70
Install: claude install-skill Lukehle/chartroom
# Forms and controls Controls in a data app are not a signup form. Nobody is being onboarded — they are steering a view they will steer again tomorrow. That changes what good looks like: **speed, precision, and reversibility** over friendliness and hand-holding. --- ## Period selection — the control finance actually uses most Generic date pickers are wrong here. People do not want to pick July 1 and July 31; they want "July" or "Q3" or "last month". ``` [ Jul 2026 ▾ ] [ Month | Quarter | Year | Custom ] ← named periods first Comparison: [ Prior period | Prior year | Plan | None ] ← comparison is a first-class control ``` Rules that matter: - **Named periods before custom ranges.** Custom is the escape hatch, not the default. - **Show period status.** `Jul 2026 (closed)` versus `Aug 2026 (open)` changes how the numbers should be read — an open period can still move. - **Comparison basis is its own control.** "Up 12%" is meaningless without it, and burying it in a settings panel guarantees misreads. - **Never default to a custom range**, and never default to a range whose boundaries are ambiguous. - Use **half-open ranges** internally (`>= start AND < end`) so the final day is not silently truncated at midnight — the same trap as in SQL. - Disable or mark future periods rather than allowing a silent empty result. --- ## Numeric and currency inputs Finance users type numbers all day, in formats generic inputs reject. **Accept what people actually type**,