# Desktop UI Text Inputs

> Use whenever designing or reviewing text fields, search bars, textareas, combo boxes/selects, or form validation in a desktop app. Depends on desktop-ui-foundations. Trigger on "text input," "search bar," "form field," "validation," or "this input looks off."

- Skill: `simply-ehis/desktop-ui-text-inputs` (Agent Skill)
- Install (CLI): `npx skillmds@latest add simply-ehis/desktop-ui-text-inputs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/simply-ehis/desktop-ui-text-inputs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: simply-ehis (https://skillmd.com/u/simply-ehis)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/simply-ehis/desktop-ui-text-inputs

---


# Text Bars & Inputs (Desktop)

## Labels, not just placeholders

**A placeholder is not a label.** Placeholder text disappears the moment the user starts typing, so if it was the only identifier for the field, the user loses context mid-entry — a real problem in a longer form or when returning to a field. Every input needs a persistent label above or beside it; use the placeholder for a short example of the expected format ("e.g. sakura@otoyin.app"), not for the field's name.

## Sizing and states

Match the control-sizing scale from `desktop-ui-buttons-controls` (sm/md/lg), and cover the same state set:

| State | Treatment |
|---|---|
| Default | Neutral border, `surface-base` or slightly recessed background |
| Focus | Clear, distinct border/ring color (usually the accent color) — this is one of the most-seen states in any form-heavy app, don't skip it |
| Filled (has content, not focused) | Same as default — don't add a separate "filled" style that fights the focus state |
| Disabled | Reduced opacity, `cursor: not-allowed`, background flattened so it doesn't look editable |
| Error | Danger-colored border + an inline error message directly below the field (see `desktop-ui-feedback-messaging`) — never color alone |
| Success/valid (only where confirmation genuinely helps, e.g. a username-availability check) | Subtle success-colored border or a small checkmark, not a full color flood |

## Search bars specifically

- Icon on the left (magnifying glass, from your chosen icon set — never Lucide, see `desktop-ui-icons`), clear/×-button on the right that only appears once there's input.
- If the app has a global search/command-palette pattern, keep the visual language consistent between the inline search bar and the palette — they're the same mental action to the user.
- Debounce live-search input (typically 150–300ms after the user stops typing) rather than firing a query on every keystroke — this matters for both perceived responsiveness and for not hammering a local search index on modest hardware.
- Show a keyboard shortcut hint (e.g. a small `⌘K`/`Ctrl+K` badge) inside or beside the field if one exists — desktop users rely on this far more than mobile users ever will.

## Textareas

- Auto-grow to fit content up to a sane max-height, then scroll internally — don't force a fixed tiny box for potentially long text, and don't let it grow to consume the whole window either.
- Show a character/line count only when there's an actual limit that matters (e.g. a title field) — don't add one decoratively.

## Combo boxes / selects

- If the list is short (under ~8 options) and all options benefit from being visible at once, consider a segmented control or radio group instead (see `desktop-ui-buttons-controls`) — a dropdown hides information a visible set wouldn't.
- If the list is long or searchable, a combo box with type-to-filter is the right call — but it needs its own focus/keyboard-navigation handling (arrow keys to move, Enter to select, Escape to close) since desktop users expect this to work.

## Validation timing

- Validate on blur (when the user leaves the field) for most fields, not on every keystroke — validating while someone is mid-type flashes errors for a value they haven't finished entering yet, which reads as broken rather than helpful.
- Exception: fields with an immediate, calculable constraint the user benefits from seeing live (a password-strength meter, a character counter near its limit) — those can update live, but the *error* styling/messaging should still wait until the field is complete or blurred.
- Re-validate immediately on submit, and scroll/focus to the first invalid field if there's more than one.

## Review format

| Before | After | Why |
|---|---|---|
| Field identified only by its placeholder text | Persistent label above the field, placeholder used for an example value | Placeholder disappears on focus, leaving no identifier while the user is typing |
| Live search fires a query on every keystroke | 200ms debounce after typing stops | Reduces redundant work and feels less jittery, especially on modest hardware |
| Error shown in red border only | Red border + specific inline error text below the field | Color alone doesn't explain what's wrong or meet accessibility contrast expectations for all users |

