算法艺术创作
algorithmic-art
通过代码和可调参数创作生成艺术与交互式视觉效果。
progressive-disclosure【设计与创意】Use this skill whenever a design has *more* available than the user needs to see at this moment — settings panels with advanced options, forms with optional fields, dashboards with drill-down detail, navigation with deep IA, dialogs with "More options" affordances, marketing pages with FAQ accordions. Trigger when designing or fixing surfaces that fe…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Progressive disclosure is the discipline of revealing information and controls in layers — showing only what's needed for the current decision and tucking the rest behind explicit affordances the user can invoke when they need more. It's one of the most decisive cognition principles in software UI: it reduces visible complexity for the 80% case while preserving access to the long tail.
Instead of presenting every option, control, and piece of information at once, divide the surface into layers based on usage frequency or relevance. Show the "primary layer" — what the typical user needs in the typical case — and conceal the rest behind disclosure affordances (a "More" button, an accordion, an "Advanced" tab, a menu). Users who need the deeper layers can reach them with one explicit action; users who don't are spared the cognitive cost of looking past them.
Every visible option costs the user something. They must:
For options that are rarely used, the user pays this cost on every visit and almost never gets value from it. The math is brutal: a user visiting a settings page 50 times pays the cost on each of the 47 fields they don't need to see, every time, in service of changing the 3 fields that matter.
Progressive disclosure inverts the math: the 3 frequent fields are visible, the 47 are tucked away with one explicit affordance. Cost-per-visit collapses; access is preserved.
A useful model: think of every surface as having a primary layer and a deeper layer (or two).
What's visible by default. Should answer:
Visible after one explicit user action. Should answer:
Visible only after deeper navigation. Should be:
Going deeper than 3 layers is rare and usually a sign the IA itself is too dense.
The mechanism by which the user reveals deeper layers. Patterns:
The Xerox Star pattern. A button at the edge of the visible content reveals additional fields or options inline.
<form>
<label>Find: <input name="q" /></label>
<button type="button" onclick="toggle('advanced')">More choices ▾</button>
<fieldset id="advanced" hidden>
<label>Search in: <select>...</select></label>
<label>Match: <select>...</select></label>
</fieldset>
<button type="submit">Find</button>
</form>
The toggle is reversible; "More choices" becomes "Fewer choices" when expanded. Users can close back to the simpler view.
Multiple disclosure affordances stacked vertically, each revealing its own deeper content.
<details>
<summary>Account</summary>
<div>...account fields...</div>
</details>
<details>
<summary>Notifications</summary>
<div>...notification settings...</div>
</details>
<details>
<summary>Advanced</summary>
<div>...advanced settings...</div>
</details>
Native <details> / <summary> provides the accessibility scaffolding for free; reach for it before custom accordions.
Different views within the same region, only one visible at a time. Useful when the secondary content is parallel to the primary, not deeper.
<nav role="tablist">
<button role="tab" aria-selected="true">Overview</button>
<button role="tab">Activity</button>
<button role="tab">Members</button>
<button role="tab">Settings</button>
</nav>
The strongest form of disclosure: a separate page reached by navigation. Use when the deeper content is large enough to warrant its own URL, breadcrumb, and orientation chrome.
A primary surface remains in context while a deeper surface overlays. Useful for editing a single object's detail, configuring something, or reviewing.
The lightest disclosure: a tooltip or popover on hover/focus. Reserved for supplementary information that doesn't disrupt the main flow.
<button>
Free trial
<span class="info" tabindex="0" aria-describedby="trial-info">ⓘ</span>
</button>
<div id="trial-info" role="tooltip" hidden>
14 days, no credit card required.
</div>
Caveat: hover-only disclosures fail on touch and for keyboard users. Always pair with focus or click.
The canonical Xerox Star pattern, still the right answer for most search UIs.
<form action="/search">
<input name="q" placeholder="Search" autofocus />
<button type="submit">Search</button>
<details>
<summary>Advanced</summary>
<fieldset>
<label>In: <select name="in">
<option>All</option>
<option>Title</option>
<option>Body</option>
</select></label>
<label>Posted after: <input type="date" name="after" /></label>
<label>Author: <input name="author" /></label>
</fieldset>
</details>
</form>
99% of users hit Enter on the search field. The 1% who need scoped search expand Advanced and refine.
Long settings pages benefit from accordion-style disclosure: each section is collapsed by default; the user opens the one they want.
<form class="settings">
<details open>
<summary><h2>Profile</h2></summary>
<div>
<label>Display name <input /></label>
<label>Bio <textarea></textarea></label>
</div>
</details>
<details>
<summary><h2>Notifications</h2></summary>
<div>...notification controls...</div>
</details>
<details>
<summary><h2>Security</h2></summary>
<div>...security controls...</div>
</details>
<details>
<summary><h2>Advanced</h2></summary>
<div>...power-user options...</div>
</details>
</form>
The first section is open by default (open attribute) so the user lands somewhere; the rest expand on demand.
<form class="filters">
<input type="search" placeholder="Search" />
<select><option>Status: Active</option>...</select>
<select><option>Owner: Anyone</option>...</select>
<details>
<summary>+ More filters</summary>
<fieldset>
<label>Created after <input type="date" /></label>
<label>Tag <input /></label>
<label>Custom field 1 <input /></label>
<label>Custom field 2 <input /></label>
</fieldset>
</details>
</form>
Three filters cover most use; the rest are an explicit gesture away.
A marketing page with 25 questions and answers is overwhelming. Show the questions; expand answers on click.
<section class="faq">
<h2>Common questions</h2>
<details>
<summary>How long is the free trial?</summary>
<p>14 days. No credit card required.</p>
</details>
<details>
<summary>What happens after the trial?</summary>
<p>You can choose a paid plan or downgrade to our free tier...</p>
</details>
<details>
<summary>Do you support SSO?</summary>
<p>Yes, on Pro and Enterprise plans...</p>
</details>
</section>
The page reads as 25 questions, not as 25 paragraphs of answers. Users open only the ones they care about.
A user signs up for a complex product. Showing every feature on day one would overwhelm. Instead:
The complexity is temporally disclosed rather than spatially.
A theme park line stretching to the horizon discourages joining. Modern parks use serpentine queues, walls, and visual breaks to disclose only a small segment of the line at a time. Visitors at the front can't see the back; visitors at the back can't see the front; the apparent line length is much shorter than the actual length.
The same logic underlies "infinite scroll" in software (the user only sees the current view; the apparent content depth is limited) and "lazy loading" (only what's needed now is loaded; the rest waits).
A multi-page menu with categories on tabs is progressive disclosure. The user picks a category (Appetizers / Mains / Desserts) and sees only those items. Without the categorization, all 80 items would compete for attention.
A single-page menu by contrast — common at fast-food counters — exposes everything because the order decision happens in seconds and Hick's Law cost is small enough to absorb.
Government and legal forms often fold the long instructions out of the way until the user reaches a relevant section. Tax forms, insurance applications, and the IRS-style worksheet model all use spatial disclosure to manage a 30-page form's visible complexity.
A book is progressive disclosure of content. The reader doesn't see Chapter 12 while reading Chapter 1; they reach it sequentially. Books that violate this (showing all spoilers up front) frustrate readers; books that respect it (gradual reveal) succeed.
hicks-law — partner principle; progressive disclosure shrinks the visible decision space, reducing Hick's Law cost.80-20-rule — partner principle; tells you which 20% to surface and which 80% to disclose.chunking — disclosure groups items into chunks (sections, accordions); chunking organizes within them.recognition-over-recall — disclosed items must be recognizable; "More options" needs to suggest what's behind it.mental-model — disclosure depth must match the user's mental model; surprise depth confuses.performance-load — progressive disclosure reduces both cognitive load (less to read) and kinesthetic load (less to scroll).wayfinding — disclosure interacts with wayfinding; users must be able to find the disclosed content when they need it.signal-to-noise-ratio (perception) — disclosure is the procedural form of SNR discipline applied to time-of-display.progressive-disclosure-defaults-and-tucking — how to decide what's primary vs. tucked, and how to default disclosure states.progressive-disclosure-disclosure-affordances — the specific UI patterns (buttons, accordions, tabs, modals) and when each fits.Progressive disclosure is one of the highest-leverage cognition moves in modern UI design. Done well, it creates an experience that feels simple to novices and powerful to experts — the same surface serving both. Done poorly, it hides what users need and surfaces what they don't. The discipline is in the editorial choice: who is this for, and what do they need now?