[UX][P2] Audit input and textarea sizing by tool intent instead of using one flat default

[baixiangcpp]

User signal

A product walkthrough reported that some input boxes feel too flat/thin and should adapt to the actual tool.

Original feedback: 有些输入框 太扁了，要根据实际工具决定。

Current pattern observed

There is a shared Input component with a global height rule: h-11 ... lg:h-9. There is also a shared Textarea with field-sizing-content min-h-16. Individual tool pages override these ad hoc, for example QR Code Generator uses a short h-24 textarea for QR content and h-9 color hex inputs.

Relevant files:

• src/components/ui/input.tsx
• src/components/ui/textarea.tsx
• src/features/tools/qr-code-generator/page.tsx
• scripts/scaffolding/create-tool.js
• representative tools under src/features/tools/*/page.tsx

UX problem

One global input height does not fit every tool:

• URL, color, number, enum, and short scalar inputs can be compact.
• Code/data payloads need taller editors or textareas.
• QR/barcode content, regex samples, CSV/JSON, Markdown/HTML, logs, and JWT-like values need different affordances.
• Mobile users need larger tap targets and enough vertical space when the software keyboard is open.

Recommended implementation

Define a small sizing taxonomy and make it available through components or tool shell helpers:

• scalar: compact single-line inputs such as color hex, margin, size.
• shortText: URL/text fields that should be comfortable but not editor-sized.
• payload: JSON/CSV/YAML/log/code input with a larger min height.
• workbench: dense split-pane/editor tools.
• generatedOutput: read-only output area with copy/export actions.

Then audit representative tools and remove one-off height decisions where possible.

Representative routes

• /en/qr-code-generator
• /en/base64-encode-decode
• /en/regex-tester
• /en/json-formatter
• /en/csv-json-converter
• /en/jwt-decoder
• /en/pipeline-builder

Acceptance criteria

• Inputs and textareas on representative tools are sized according to expected content, not only by shared defaults.
• Short scalar controls remain compact; user-authored payload fields are visibly comfortable.
• Mobile touch target requirements remain satisfied.
• npm run create:tool scaffolds a sensible default input size or requires choosing an input intent.
• Add a guard or component test that documents the sizing taxonomy and prevents regressions in the scaffold/template.

[baixiangcpp]

Agent-side expanded audit note: add a static + visual inventory instead of relying on subjective review. Static scan should list every Input, Textarea, raw <input>, and raw <textarea> with hardcoded sizing classes such as h-9, h-24, min-h-16, min-h-[...], and field-sizing-content. Then classify by input intent: scalar, shortText, payload, workbench, generatedOutput. Add screenshot checks for representative routes and update the scaffold so new tools choose an input intent instead of inheriting one flat default. Manual review should only validate the final feel after the inventory is corrected.

[baixiangcpp]

Visual browser audit update - 2026-07-01

The sizing issue is mixed rather than universal.

Good patterns observed:

• Base64 Encode/Decode has large input and output panels and feels comfortable for text transforms.
• JSON Formatter uses large split input/output panels and the empty-state output panel is clear.
• JWT Decoder has a tall token input and separate header/payload outputs.

Needs improvement:

• QR Code Generator's content field is short for longer URLs or text and was fixed in PR Fix QR input and export UX #326 by increasing the min height and allowing resize.
• Pipeline Builder is dense. Inputs, side panels, run summary, validation, and gallery cards all fit on desktop, but the page has high visual load and should stay in the wide workbench layout class.
• Scalar controls such as color hex fields are fine as compact controls, but they should be explicitly classified as scalar instead of inheriting generic input sizing.

Suggested follow-up:

• Keep this issue open for a full static inventory and taxonomy guard.
• PR Fix QR input and export UX #326 should only be treated as the QR-specific slice, not as closure for the whole input sizing audit.