Visual Design Patterns for JSON Schema Options

String (`type: "string"`)

Strings are the most versatile type and can be represented by various UI elements depending on their constraints (`format`, `enum`, `minLength`, `maxLength`, `pattern`).

• Single-line Text Input: The default for general strings (`<input type="text">`). Use `minLength`/`maxLength` for character limits.
• Textarea: For multi-line strings, often indicated by a suggestion in the schema or context (`<textarea>`).
• Select/Dropdown: When `enum` is defined, offering a fixed list of string values (`<select>`).

  {
    "type": "string",
    "enum": ["red", "green", "blue"],
    "description": "Choose a color"
  }

• Radio Buttons: Also for `enum`, especially when the list is short (e.g., 2-4 options).
• Date/Time/Color Input: When `format` hints at a specific data type like `date`, `date-time`, `time`, `email`, `url`, or `color`. Use specific input types (e.g., `<input type="date">`, `<input type="color">`).

  {
    "type": "string",
    "format": "email",
    "description": "Enter your email address"
  }

• File Input: Sometimes strings might represent file paths or URLs, but for file uploads, a dedicated file input (`<input type="file">`) is more appropriate. Schema might use a custom `format` or context.
• Password Input: For sensitive string data (`<input type="password">`). Often indicated by key names (`password`) or context.

Number & Integer (`type: "number"` / `"integer"`)

Numeric types are best represented by inputs that enforce numerical values and respect range constraints (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, `multipleOf`).

• Number Input: The standard (`<input type="number">`). Use `min`, `max`, and `step` attributes based on schema constraints.

  {
    "type": "integer",
    "minimum": 1,
    "maximum": 100,
    "description": "Enter an integer between 1 and 100"
  }

• Slider / Range Input: Ideal when the range is well-defined and granular control isn't strictly necessary, offering a visual selection (`<input type="range">`).

  {
    "type": "number",
    "minimum": 0,
    "maximum": 1,
    "format": "float", // Or just implied by type: "number"
    "description": "Adjust the transparency (0.0 to 1.0)"
  }

• Stepper: A number input with increment/decrement buttons, useful for integer values with a clear step (`multipleOf`).

Boolean (`type: "boolean"`)

Booleans are typically represented by controls that have two states: true/false, on/off, yes/no.

• Checkbox: The most common representation (`<input type="checkbox">`).
• Toggle Switch: A visually distinct component for on/off states, often used for settings that take immediate effect.
• Radio Buttons: Using "Yes" and "No" labels, sometimes clearer than a single checkbox, especially if the phrasing is complex.

Array (`type: "array"`)

Arrays represent lists of items. The visual pattern depends heavily on the type of items (`items`) and constraints like `minItems` and `maxItems`.

• List Input (Add/Remove): For simple item types (strings, numbers, booleans), display items as a list with buttons to add new items and remove existing ones.

  {
    "type": "array",
    "items": { "type": "string" },
    "description": "List of tags"
  }

• Tag Input: A specific pattern for arrays of strings, where items are displayed as "tags" inside a container with an input for adding new ones.
• Table: For arrays where `items` is an `object` type. Each object in the array becomes a row, and object properties become columns. Includes buttons to add/remove rows.

  {
    "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "age": { "type": "integer" }
      }
    },
    "description": "List of people"
  }

• Reorderable List: If item order matters, allow drag-and-drop or up/down arrows to change item positions.
• Fixed Tuple: If `items` is an array of schemas (tuple validation), display fixed inputs for each item type.

Object (`type: "object"`)

Objects represent structured data with named properties. They typically translate into nested forms or sections.

• Nested Form/Fieldset: Display the object's properties as inputs within a clearly defined section (e.g., using `<fieldset>` with a `<legend>` or a simple container with a heading).

  {
    "type": "object",
    "properties": {
      "address": {
        "type": "object",
        "properties": {
          "street": { "type": "string" },
          "city": { "type": "string" }
        }
      },
      "phone": { "type": "string" }
    }
  }

• Accordion or Tabs: For objects with many properties, group related properties into collapsible sections (accordion) or separate panes (tabs) to manage complexity.
• Conditional Fields: Use schema keywords like `dependencies` or logic within `if`/`then`/`else` to show/hide fields based on the values of other fields within the object.
• Key-Value Pairs: If `additionalProperties` is used without a strict schema for known properties, a flexible interface to add/remove arbitrary key-value string pairs might be suitable.

`oneOf` / `anyOf`

These indicate that the data must match one or more of the provided subschemas.

• Schema Selector (Radio/Select): If the subschemas are distinct (e.g., defining different object structures), provide a way for the user to choose which schema they are providing data for (e.g., "Choose Contact Method:" followed by radio buttons for "Email" or "Phone"). Display the form fields corresponding to the selected schema. This is common for `oneOf`.

  {
    "oneOf": [
      { "type": "string", "format": "email" },
      { "type": "string", "format": "uri" }
    ],
    "description": "Contact by email or website"
  }

• Merged Form + Validation Feedback: For `anyOf`, or when subschemas overlap, display a form with all fields from all subschemas. Use validation to show which constraints from which subschema(s) are being met or violated.
• Step-by-step Wizard: Guide the user through satisfying the criteria, perhaps one subschema at a time.

`allOf`

Indicates that the data must *all* of the provided subschemas.

• Merged Form: The most common pattern is to merge the properties and constraints from all subschemas into a single form interface. For instance, if one schema defines an address object with required street and city, and another schema in `allOf` adds an optional zip code, the final form simply shows inputs for street, city, and zip code, with street and city marked as required.

  {
    "allOf": [
      { "$ref": "#/definitions/addressSchema" }, // Assume this defines street/city
      {
        "type": "object",
        "properties": {
          "zipCode": { "type": "string" }
        }
      }
    ],
    "description": "Complete address including zip code"
  }

`not`

Indicates that the data must *not* match the provided subschema.

• Validation Feedback: This constraint is difficult to translate into a direct input control. It's primarily used for validation. The UI should accept input and then provide feedback if the entered data violates the `not` schema.

`title` and `description`

Provide human-readable context for the data.

• Labels: Use `title` as the label for an input field or section header.
• Help Text / Tooltips: Use `description` to provide more detailed explanation or guidance, often displayed below the input or in a tooltip/popover.

  {
    "type": "string",
    "title": "Username",
    "description": "Choose a unique username for your account. Minimum 5 characters."
  }

`default` and `examples`

Suggest initial values or demonstrate valid inputs.

• Pre-filled Fields: Use the `default` value to pre-populate an input field when the form is initially loaded.

  {
    "type": "boolean",
    "title": "Enable Feature",
    "default": true
  }

• Placeholders or Examples: Use `examples` (or sometimes `default` if it's not a value to be saved but a suggestion) as placeholder text in an input field or to show typical valid inputs near the field.

`readOnly` and `writeOnly`

Control whether the user can modify the data.

• Read-only / Disabled Inputs: If `readOnly` is true, display the value but disable the input field so it cannot be edited. Alternatively, just display the value as text.

  {
    "type": "string",
    "title": "User ID",
    "readOnly": true,
    "description": "Your unique system identifier (cannot be changed)."
  }

• Hidden Inputs / API Only: If `writeOnly` is true, the property should generally not be displayed for reading (e.g., a password confirmation field) but might be included when submitting data.

Live Validation Feedback

Use schema constraints (`minLength`, `pattern`, `minimum`, `maxItems`, etc.) to validate user input as they type or when they leave a field.

• Display error messages clearly linked to the input field when validation fails.
• Indicate required fields (from the `required` array in an object schema).

  {
    "type": "object",
    "properties": {
      "username": { "type": "string" },
      "email": { "type": "string", "format": "email" }
    },
    "required": ["username", "email"]
  }

• Show success states when input is valid.

Usability

• Consistency: Use consistent UI patterns for the same schema types throughout your application.
• Simplicity: Avoid overly complex nested structures where flatter forms might suffice for simple data.
• Progressive Disclosure: Use accordions, tabs, or steps to hide complexity until needed, especially for large objects or complex combinators.
• Clear Labeling: Ensure labels (from `title`) are always visible and clearly associated with their inputs.

Accessibility

• Ensure all form elements have proper ARIA attributes and linked labels for screen readers.
• Keyboard navigation should be fully functional.
• Validation errors must be clearly communicated to assistive technologies.