Design and build Boardly's responsive, fully interactive Kanban board from the frozen prompt, rules, board data, and requirements, including pointer and keyboard drag and drop without a drag-and-drop library.
Difficulty: Mediumweb-app · 3 outputs · 3 runs · 3 revisions · frozen 2026-09-24 21:42 UTC
One archived screenshot per published Run against version 1.1.0, of the Run’s representative Revision. Ordered by setup and then by repetition, not by quality.
Frozen with this version. Requirement IDs are stable across versions and are cited unchanged by evaluation records.
Automated checks are not an accessibility certification. Recorded axe findings describe what the tooling observed at capture time, on a pinned browser and viewport. A check that reports no violation is not proof that the interface is accessible, and a selector problem is inconclusive rather than an implementation failure.
| # | Model | Tool | Revision | Status | Actions |
|---|---|---|---|---|---|
| Fig. 01 | DeepSeek V4.1 Flash (max) | OpenCode | 0 · initial | live | |
| Fig. 02 | GLM-5.3 (max) | OpenCode | 0 · initial | live | |
| Fig. 03 | GLM-5.3-Flash (max) | OpenCode | 0 · initial | live |
Fig. 01DeepSeek V4.1 Flash (max)
Fig. 02GLM-5.3 (max)
Operator-attested: the Configuration, tool version, displayed model, and elapsed time were recorded by the operator from what the tool showed at Run time. They are not independently verified. An exact model ID appears only when the tool exposed one; it is never inferred.
Published sites are independent, AI-generated demos served from separate preview origins with local mock data. They are not products, and no UIBenchmark session data crosses to them.
Exact model ID, tool version, elapsed time, run state, stop reason, discarded attempts and every published Revision, repairs included, in run log order. Each Run and each Revision links to its own page.
01Run 1 · DeepSeek V4.1 Flash (max) · OpenCode
Every Run here received exactly the frozen inputs of this version, so they form one cohort. Runs against another frozen version are listed on that version’s own page.
All published Runs of Boardly — Website RelaunchDesign and build Boardly's responsive, fully interactive Kanban board from the frozen prompt, rules, board data, and requirements, including pointer and keyboard drag and drop without a drag-and-drop library.
The workflow designs the interface itself from the frozen brief.
Read PROMPT.md and BENCHMARK_RULES.mdThis is the immutable Challenge Version: the exact inputs every Run against it received. Frozen inputs never change, so an older Run stays readable against precisely the brief it was given.
Both are shown as the stored source text, unrendered and unedited, so what you read is byte-for-byte what the frozen version contains.
Launch prompt
The prompt submitted at the start of every Run against this version.
# Boardly — Website Relaunch board Build the Kanban board view of **Boardly**, a fictional project-management tool for small product teams. The board belongs to the workspace **Harbor Studio** and tracks its **Website Relaunch** project. ## Product - **Name:** Boardly. - **Feel:** focused, calm, fast. A tool people keep open all day: dense enough to see the whole project, quiet enough not to tire the eyes. - **You own the visual identity.** Design the Boardly wordmark/logo, color palette, type scale, label colors, member avatars, icons, and layout yourself; nothing is prescribed. Any graphics you need must be created in this workspace (inline SVG or CSS). There is no supplied photography. - **Microcopy is part of the task.** Write all interface copy yourself: empty states, validation messages, confirmations, screen-reader announcements, and the explanation shown when a column limit blocks a move. ## Data - `public/data/board.json`: workspace and board names, the fixed date `today`, labels, priorities, columns in order (with an optional `wip_limit`), each column's ordered `card_ids`, and all cards. - `public/data/members.json`: the team members cards can be assigned to. Use the supplied data as the initial board state. Do not add, remove, or rename supplied cards, columns, members, or labels in the initial state. **Dates:** treat `today` from `board.json` as the current date, not the system clock. A card is **overdue** when its due date is before `today` and it is not in the Done column. A card due on `today` is not overdue. ## Board view One application screen with: 1. **App frame** — the Boardly wordmark you design, the workspace name, and the board name. 2. **Board** — all five columns in the supplied order, each showing its title, its card count, and its cards in the supplied order. Columns with a `wip_limit` show the limit next to the count. 3. **Cards** — each card shows its title, labels, assignee (or a clear unassigned state), due date, an overdue indication when overdue, and checklist progress (for example 2/4) when it has checklist items. 4. **Filter bar** — filter by assignee and by label, plus a text search over card titles and descriptions. Filters combine; column counts reflect the visible cards. Show an empty state when nothing matches, and offer a way to clear all filters. 5. **Fictional notice** — the note “Boardly is a fictional product created for UIBenchmark.” (verbatim, must be visible). ## Interactions - **Drag and drop with a pointer.** Move cards between columns and reorder them within a column; the card lands where it was dropped. Show clear feedback while dragging (for example a placeholder at the drop position). No drag-and-drop library is installed and none may be added: build it with React and browser APIs. - **Keyboard moves.** A focused card can be picked up, moved within its column or to an adjacent column with arrow keys, dropped, or cancelled with Escape, which restores its original position. Announce pick-up, each move, drop, and cancel through a live region. - **Move without dragging.** Every card can also be moved to another column through a visible control (your choice of pattern). This must work at mobile width, where dragging is not required. - **Column limit.** A move or new card that would exceed a column's `wip_limit` is blocked, whichever way it is attempted, and the interface explains why. - **Card details.** Opening a card (pointer or Enter) shows a dialog with all of its fields. Title, description, assignee, and checklist items (done or not done) are editable there, and the board reflects the changes. An empty title is rejected with a visible message. The dialog keeps focus inside, closes with Escape, and returns focus to the card. - **Create and delete.** Add a card to any column; the title is required. Delete a card only after a confirmation step. - **Undo.** The most recent move, creation, or deletion can be undone through a visible control and with Ctrl+Z / Cmd+Z (outside text fields). - **Persistence.** The board state survives a page reload using local storage. A “reset demo” action restores the supplied initial state. ## Constraints - Responsive at 1440×900 (desktop) and 390×844 (mobile). At mobile width the document must not overflow horizontally; the board may scroll inside its own region, and every column must remain reachable. - Respect reduced-motion preferences for any animation you add. - No external network requests, fonts, or images. System font stack only. See `BENCHMARK_RULES.md` for binding rules and `REQUIREMENTS.json` for the behaviors that will be evaluated.
Shared rules
The rules every Configuration worked under for this version.
# Benchmark rules (shared, v4)
These rules are binding and identical for every Configuration.
## Allowed
- The supplied starter, images, data files, and installed dependencies.
- Additional graphics you create yourself inside this workspace (inline SVG,
CSS art, or authored SVG files).
- Local development preview while working.
- The provided local test browser (headless Chromium with Playwright) at
`/opt/uibench/browser`: `import { chromium, launch } from
"/opt/uibench/browser/launch.mjs"` in a Node script, or run
`/opt/uibench/browser/bin/uibench-screenshot <url> <file.png>`. Use it only
against your own local preview on `localhost` or `127.0.0.1`.
- Building, testing, and correcting your implementation before completion.
## Required
- Browser-compatible production output under `dist/` via the starter's build
script, deployable at a hostname root.
- Implement required interactions as working behavior.
- Responsive behavior at 1440×900 and 390×844.
- Keep demo state in memory or origin-scoped local storage; no cookies.
- Required forms, if any, simulate behavior locally and never transmit data.
- All navigation stays within the demo.
## Prohibited
- Modifying `BENCHMARK_RULES.md`, `PROMPT.md`, `REQUIREMENTS.json`,
`AGENTS.md`, `CLAUDE.md`, or the dependency lockfile.
- Delegating any part of the work to subagents, sub-sessions, or spawned
agent tasks; complete the task in this single session.
- Adding, removing, or updating dependencies.
- External network resources of any kind: requests, fonts, images, embeds,
analytics, service workers, or background requests, including external
navigations or requests made through the provided test browser.
- Researching on the web while you work: searching the web or fetching web
pages or online documentation.
- Generating images with an image-generation tool or model.
- Backend services, databases, credentials, payments, or personal data.
- Deploying the result or accessing deployment credentials.
## Completion
Remove generated self-test artifacts (screenshots and test scripts) from
`dist/` before completion.
Before declaring completion, run the production build. In your final response,
state whether it succeeded and identify any incomplete requirements.
The declared rules and viewports this version was executed and captured under.
Fig. 03GLM-5.3-Flash (max)
02Run 1 · GLM-5.3 (max) · OpenCode
03Run 1 · GLM-5.3-Flash (max) · OpenCode
Discarded attempts failed for a technical reason — a crashed session, a tool outage, a broken upload — and were discarded and retried from the same frozen inputs. The count is not a quality signal.
Generation cost: Not separately metered. Runs were executed on the operator’s personal tool subscriptions, which do not itemize a per-Run charge. No amount is attributed, and no zero-cost claim is made.
Starter and asset hashes are published so every run can be shown to have received the same bytes. There is no starter download and no asset download.
Starter SHA-256
2151c0ae15bdb87cbc2a971e6e4d02a9e4441ed55ac79266f91b9c4e6e4b82d5
Asset pack SHA-256
d098bf9ed5103f51ac70c32a2363ba3e0b88276acd6a858ab7530efe37c6e3dc