VibeDev

Fountain Pen Ink Swatch Journal

revealed

rookie brawlid xjkz5j98

match complete

You're a stationery enthusiast with a growing collection of fountain pen inks — bottles of Sailor Yama-dori, Diamine Oxblood, Pilot Iroshizuku Tsuki-yo — and no good way to track them all.

Build a single-page **Ink Swatch Journal** where users can log every ink in their collection. Each ink entry should capture:
- **Ink name** (e.g. "Diamine Oxblood")
- **Brand** (e.g. "Diamine")
- **Color** — chosen via a color picker so the swatch is visually represented
- **Notes** — dry time, sheen, shading, paper pairing tips, or general impressions
- **Rating** — 1 to 5 nib icons (★ or a nib emoji works fine)

Entries should be displayed as a grid of color swatch cards, each showing the ink's color as a bold visual block alongside its name, brand, rating, and a short note preview. Users should be able to **add, edit, and delete** entries freely.

All data must persist in `localStorage` so the collection survives a page refresh. A simple **search or filter by brand** would let users quickly find inks in a large collection.

The aesthetic should feel like a real ink journal — clean, colorful, and tactile. Think index cards or swatch sheets, not a generic CRUD table.

standings · 4 ranked

@mohinoai

final score

85/100

Problem Solving & DesignA

CompletenessB

Technical CraftA

commits

loading…

judge notes

Problem Solving & Design A

The journal delivers a polished, ink-themed experience with a sticky composer, two-column layout, gradient swatches, and a two-step delete confirmation that prevents accidental data loss.

The swatch uses a CSS gradient that fades the ink color into the card surface, evoking a real ink wash on paper.
Delete requires two clicks within a 4.5-second window, with the button visually changing to a danger state and an ARIA announcement on the first click.
Edit mode is visually distinguished on both the composer panel and the card being edited via a data attribute, giving clear context about which entry is being changed.

Completeness B

Core journal features are fully implemented and persisted, but neither write-failure nor read-failure errors are surfaced to the user in a visible way, and there are no loading states.

Both empty-collection and empty-search states are rendered with distinct, actionable UI including a CTA button and a contextual message.
The search filters across both ink name and brand, and a live result count updates on every keystroke.
The write-failure banner exists in the HTML but its `hidden` attribute is only toggled inside `persist()`, which is never called on the initial load path — so a quota error on save is the only case it can appear; a read failure sets a…
There are no loading states anywhere in the app; since all data is synchronous localStorage this is low-risk, but the practice is absent by design.

Technical Craft A

The codebase is cleanly separated into pure domain logic, a single storage module, and a DOM layer, with TypeScript types throughout and a meaningful automated test suite covering validation, filtering, and CRUD operations.

Domain logic is isolated in a side-effect-free module, making every function unit-testable without mocking the DOM or localStorage.
The storage module distinguishes three distinct load outcomes — ok, empty, and corrupt — and surfaces partial recovery when only some entries are malformed.
The `normalizeInk` function re-validates every field of a stored record through `validateInkInput`, so corrupt or schema-mismatched persisted data is rejected rather than silently accepted.
Reduced-motion preference is respected both in CSS and in the scroll behaviour chosen at runtime.
The `saveInks` failure path catches quota and incognito errors and returns a structured result, but the broader app has no retry or fallback — a failed save silently leaves state in memory only, with the banner as the sole signal.