Setup Checklist with Progress
The get-started card that ships with its first item already ticked, a native <progress> element rather than a div bar, and a dismiss control that appears only once there is nothing left to abandon.
The first screen after signup, asking only the two things that cannot be changed silently later.
components/workspace-setup-form.tsxnpx hoverlab add workspace-setup-form
Or over MCP, from your editor's agent — no account needed.
Free to read, copy and install, for personal and non-commercial projects. Shipping it in client work or a paid product needs Pro ($79 once). The source lands in your repo and stops being ours — no attribution, nothing to upgrade.
Start a page with this section — add more, order them, and leave with the page source.
Everything else in setup has a sensible default and can be changed later without telling anyone. These two appear in URLs and invitations, so they are worth one screen.
Rendered live in your current theme — this is the same component whose source is below, not a screenshot of it.
'use client'
/**
* <WorkspaceSetupForm> — The first screen after signup, asking only the two things that cannot be changed silently later.
*
* The first screen after signup is where products ask fourteen questions
* and lose the person who has not yet seen anything work. The layout problem
* is deciding what genuinely cannot wait, and the obvious wrong answer is a
* multi-step wizard covering team size, industry and use case — none of
* which changes what happens next.
*
* Two fields survive that test, and only because of the asymmetry the hints
* spell out: the name is changeable at any time and the URL is not, because
* the URL is already in every link that has been shared. That distinction is
* the entire reason this screen exists rather than defaulting both.
*
* Everything else in setup has a sensible default and can be changed later
* without telling anyone, so it is not here.
*
* Accessibility: labels wired with `htmlFor`/`id` so the hints are announced
* through `aria-describedby` — and the URL hint is the one that must not be
* missed, since it is the warning about the irreversible field. The
* `role="status"` region is in the DOM and empty from the first render, so
* the created-workspace confirmation is announced rather than silently
* replacing the form.
*
* The demo defaults to `idle` with both fields empty. A real implementation
* should derive the slug from the name as it is typed and let it be
* overridden, which is why they are separate fields rather than one.
*/
import * as React from 'react'
export interface WorkspaceSetupFormProps {
heading?: string
intro?: string
submitLabel?: string
/** Called with the collected values. Resolve to accept, throw to reject. */
onSubmit?: (values: Record<string, string>) => Promise<void> | void
className?: string
}
type Status = 'idle' | 'pending' | 'done' | 'error'
/*
A typed array rather than `as const`. With `as const` the entries have
different shapes - some carry a hint, some do not - so `field.hint` is a
type error on the members that lack it, and the `'hint' in field` dance
needed to work around that is worse than declaring the field optional once.
*/
interface WorkspaceSetupFormField {
name: string
label: string
type: string
hint?: string
}
const FIELDS: WorkspaceSetupFormField[] = [
{ name: "name", label: "Workspace name", type: "text", hint: "Shown to everyone you invite. Changeable at any time." },
{ name: "slug", label: "URL", type: "text", hint: "Becomes part of every link you share. Changing it later breaks the old ones." },
]
export function WorkspaceSetupForm({
heading = "Name your workspace",
intro = "Everything else in setup has a sensible default and can be changed later without telling anyone. These two appear in URLs and invitations, so they are worth one screen.",
submitLabel = "Create workspace",
onSubmit,
className,
}: WorkspaceSetupFormProps) {
/*
Per-instance prefix for every id this block emits.
The literals these replaced were a latent duplicate the moment the
block appeared twice on one document, and `aria-labelledby` on a
duplicated id resolves to the first match -- so the second copy was
labelled by the first copy's heading. Client component, so `useId` is
the right tool.
*/
const uid = React.useId()
const [status, setStatus] = React.useState<Status>('idle')
const [message, setMessage] = React.useState('')
async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
event.preventDefault()
const data = new FormData(event.currentTarget)
const values = Object.fromEntries(
FIELDS.map((field) => [field.name, String(data.get(field.name) ?? '')]),
)
setStatus('pending')
try {
await onSubmit?.(values)
setStatus('done')
setMessage('Thanks — that came through.')
} catch (error) {
setStatus('error')
setMessage(error instanceof Error ? error.message : 'That did not go through.')
}
}
return (
<section
aria-labelledby={`${uid}-workspace-setup-form-heading`}
className={`w-full bg-background px-6 py-16 ${className ?? ''}`}
>
<div className="mx-auto max-w-md rounded-xl border border-border bg-card p-8 shadow-sm">
<h2
id={`${uid}-workspace-setup-form-heading`}
className="text-xl font-semibold tracking-tight text-card-foreground"
>
{heading}
</h2>
<p className="mt-2 text-sm text-muted-foreground">{intro}</p>
<form onSubmit={handleSubmit} className="mt-6 space-y-4">
{FIELDS.map((field) => (
<div key={field.name}>
{/*
htmlFor / id rather than a wrapping label, so the hint can
sit outside the label and still be announced — that is what
aria-describedby is for.
*/}
<label
htmlFor={`${uid}-workspace-setup-form-${field.name}`}
className="block text-sm font-medium text-foreground"
>
{field.label}
</label>
<input
id={`${uid}-workspace-setup-form-${field.name}`}
name={field.name}
type={field.type}
required
aria-describedby={field.hint ? `${uid}-workspace-setup-form-${field.name}-hint` : undefined}
className="mt-1.5 w-full rounded-md border border-input bg-background px-3 py-2 text-sm text-foreground placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring"
/>
{field.hint ? (
<p
id={`${uid}-workspace-setup-form-${field.name}-hint`}
className="mt-1 text-xs text-muted-foreground"
>
{field.hint}
</p>
) : null}
</div>
))}
<button
type="submit"
disabled={status === 'pending'}
className="w-full rounded-md bg-primary px-4 py-2 text-sm font-medium text-primary-foreground transition-opacity hover:opacity-90 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring disabled:opacity-60"
>
{status === 'pending' ? 'Working…' : submitLabel}
</button>
{/*
The live region is always in the DOM and starts empty. A region
mounted at the moment it gets text is frequently not announced —
the assistive tech never saw it become live.
*/}
<p
role="status"
aria-live="polite"
className={`min-h-5 text-sm ${
status === 'error' ? 'text-destructive' : 'text-muted-foreground'
}`}
>
{message}
</p>
</form>
</div>
</section>
)
}
bg-card, text-muted-foreground) — it inherits your theme instead of overriding it.Drop it at components/workspace-setup-form.tsx and import it where you need the section:
import { WorkspaceSetupForm } from '@/components/workspace-setup-form'2 of this block’s props are simple enough to drive from here. Change them and the block below re-renders — it is the same component whose source is above, not a mock of it. Everything else it accepts is in the table underneath.
Read out of the component’s own type and signature, so this cannot drift from the source below. Every prop has a default — the component renders standalone before you pass it anything.
| Prop | Type | Default |
|---|---|---|
heading | string | "Name your workspace" |
intro | string | — |
submitLabel | string | "Create workspace" |
onSubmitCalled with the collected values. Resolve to accept, throw to reject. | (values: Record<string, string>) => Promise<void> | void | — |
className | string | — |
The same block rendered once to markup, wrapped as a file your framework compiles. Tailwind classes are framework-agnostic, so the design transfers intact — the behaviour does not.
This block is interactive. The markup below is its initial state with the event handlers stripped — you will need to re-wire the behaviour in your framework.
<!--
Workspace Setup Form — markup from the Hoverlab catalog.
This is the block rendered once to HTML and wrapped as a component
file. It is not a port of the React source: the Tailwind classes carry
the design, which is the part that took the work, and they are the same
in every framework.
This block is interactive in React and the handlers are NOT here.
Buttons, toggles and menus render in their initial state and do
nothing until you wire them up.
-->
<section aria-labelledby="_R_0_-workspace-setup-form-heading" class="w-full bg-background px-6 py-16 ">
<div class="mx-auto max-w-md rounded-xl border border-border bg-card p-8 shadow-sm">
<h2 id="_R_0_-workspace-setup-form-heading" class="text-xl font-semibold tracking-tight text-card-foreground">Name your workspace</h2>
<p class="mt-2 text-sm text-muted-foreground">Everything else in setup has a sensible default and can be changed later without telling anyone. These two appear in URLs and invitations, so they are worth one screen.</p>
<form class="mt-6 space-y-4">
<div>
<label for="_R_0_-workspace-setup-form-name" class="block text-sm font-medium text-foreground">Workspace name</label>
<input id="_R_0_-workspace-setup-form-name" type="text" required="" aria-describedby="_R_0_-workspace-setup-form-name-hint" class="mt-1.5 w-full rounded-md border border-input bg-background px-3 py-2 text-sm text-foreground placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring" name="name" />
<p id="_R_0_-workspace-setup-form-name-hint" class="mt-1 text-xs text-muted-foreground">Shown to everyone you invite. Changeable at any time.</p>
</div>
<div>
<label for="_R_0_-workspace-setup-form-slug" class="block text-sm font-medium text-foreground">URL</label>
<input id="_R_0_-workspace-setup-form-slug" type="text" required="" aria-describedby="_R_0_-workspace-setup-form-slug-hint" class="mt-1.5 w-full rounded-md border border-input bg-background px-3 py-2 text-sm text-foreground placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring" name="slug" />
<p id="_R_0_-workspace-setup-form-slug-hint" class="mt-1 text-xs text-muted-foreground">Becomes part of every link you share. Changing it later breaks the old ones.</p>
</div>
<button type="submit" class="w-full rounded-md bg-primary px-4 py-2 text-sm font-medium text-primary-foreground transition-opacity hover:opacity-90 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring disabled:opacity-60">Create workspace</button>
<p role="status" aria-live="polite" class="min-h-5 text-sm text-muted-foreground"></p>
</form>
</div>
</section>
What each framework gets across the whole catalog — effects convert properly; this rung is markup.
The component, its props, the design tokens it expects and the command that installs it — as one prompt. Paste it into Claude, Cursor, v0 or ChatGPT and what they build around it will match the rest of the catalog instead of inventing its own system.
Want the whole screen instead of this one section? Open a page and copy it entire.
All of them free to read, copy and install — no account, no locked tiles, no watermarked preview. The whole catalog is open, and so are the API and the CLI.
Browse OnboardingCopying the code is free. Putting it in client work or a paid product is what Pro is for — the licence, not the access.
The get-started card that ships with its first item already ticked, a native <progress> element rather than a div bar, and a dismiss control that appears only once there is nothing left to abandon.
A choice-driven wizard with a persistent side rail, real radio groups in a fieldset so arrow keys work, and visited steps navigable while steps ahead stay out of the tab order.
The onboarding step where a product becomes multiplayer: pasted addresses split into chips, typos marked rather than dropped, and an honest way to skip.
A tour step anchored to the control it explains, with a spotlight cut by one spread shadow, a visible step count and focus that follows the step.
The "what best describes you" step, asked honestly — every option states what it actually changes, the skip is visible and names what you get instead, and the choice is reversible.
The empty product’s real first question. Sample data is offered with equal weight rather than as grey small print, every connector names its scope before the redirect, and each option carries the honest duration.
What a migration actually moves and what it cannot, stated before the switch rather than discovered after it.