Mycelium

The Field Kit

Codex: Inputs

Each input, its promise, and where it fits

Text input. Tell me in your own words, in your own format. Use when the answer is open-ended and format-independent (names, messages, descriptions), when valid answers are unbounded, or when the person's exact wording is the data. Avoid when the data has a known format (phone, date, postcode, currency), when valid values come from a set the system knows, or when the structured value matters more than the wording. A phone number is not free text: separate country code with a searchable flag picker, numeric input, live formatting, validation against the country's rules. Any field whose output renders in a specific way should show that format while the person types (variable syntax inline, a URL slug previewing the full path).

Textarea. This answer is long, multi-line, prose. A character limit is part of the promise and must be live and visible as a counter that gains weight as the limit nears, never a static note below the field. If the content will render as formatted output (an email, a template, a description), the textarea is the wrong container; the person should write in the context where it will be seen. See What Happens When They Finish?

Select. Choose one from a large set I'm managing for you; too many to show at once. Use for more than 7–8 standardised options the person knows and needs to find (countries, currencies, languages, timezones), or when space is constrained. Avoid under 5 options (radios), when the person needs to see all options to decide, when options differ visually, or when the person knows their answer as a typeable value (see The Year-of-Birth Dropdown). The searchable select (combobox) covers large sets where the person can type to filter or scroll to browse.

Radio group. Exactly one, from a small set you can see in full. Use for 2–6 mutually exclusive, self-explanatory, text-labeled options where seeing them all helps. Avoid above 6–7 (select), for binary-with-immediate-effect (toggle), or when options need showing rather than naming (card radio).

Card radio. Exactly one, and here is what each option looks like. Use when the difference between options can't be carried by a label: layout density, color scheme, template, plan tiers whose features differ visibly. It belongs in Builders where the choice changes the visible output. It is decoration in a Submission where the label suffices, and wrong wherever the card size inflates the form beyond the decision's weight.

Checkbox. Any combination, including none; each option independent. The promise is independence. It breaks when options are actually mutually exclusive (radio) or when some combinations are invalid and the form neither prevents nor explains them. A single checkbox for a two-state preference is a toggle in disguise.

Toggle. Two states, and the change takes effect now. The second half is the one usually broken: a toggle that needs a Save button looks immediate and isn't. Use in settings and live states with clearly opposite labels. Avoid when the change requires saving (checkbox), when the states aren't opposites (radios), or when the person should preview a consequence before committing (card radio).

The composition

Four questions before choosing

1. How many options are there? 2. Does the person know the options, or need to discover them? 3. Does the choice have visible consequences? 4. How long will this take, and is the input type the reason?

Rule of thumb that survives: if they know the answer as something they could type, typing beats choosing. The canonical case is the year-of-birth dropdown: a four-digit number the person has typed a thousand times, offered as a hundred-item list to scroll, because "year" looked like a category and categories look like dropdowns. Five to fifteen seconds instead of two. Nobody who built one was careless; they were matching the data's shape instead of the person's hand.