View-First Forms: See Before You Edit
Most business application forms open directly in edit mode. Every field shows as an input, cursor blinking. If you're there to read the record — to check a value, to verify information, to review before acting — you're looking at an interface designed for writing, not reading.
Read mode and edit mode have different design requirements. View-first forms recognize this.
Read Mode as the Default
When you open a record in Swifty, it opens in read mode. Fields display their values in clean, readable form — not inside input boxes with borders and placeholder text. Text is text. Dates are formatted. Choices show their labels. Related records show clickable links.
The read-mode view is optimized for scanning. You see the record's information arranged for comprehension, not for data entry.
Edit on Intent
When you want to edit a field, you click it. The field activates an input in place, pre-filled with the current value. Everything else on the page remains in read mode.
This means editing is intentional. You click the thing you want to change, change it, and save. Other fields don't accidentally receive changes from keyboard navigation, from clipboard pastes into the wrong field, or from browser autofill.
Fewer Accidental Changes
Edit-by-default forms are surprisingly prone to accidental modifications. A user presses Tab to move focus, accidentally modifying a value they were only reading. They paste something in the wrong field. Browser form fill populates fields with saved values.
View-first forms eliminate this class of accident. If you didn't click a field, it can't be modified. The record stays unchanged unless there's explicit editing intent.
Better Information Architecture
The distinction between read and edit modes also creates space for different information design. The read view can show computed values that don't have inputs — formatted totals, derived status indicators, relationship summaries. The edit view shows fields that can be changed.
These two views can include different elements. The read view might show a formatted invoice total that's computed from line items; the edit view provides the line item form for changing the inputs that drive the total.
Saving Changes
When editing, a save button becomes active. Changes are committed on save; discarded by clicking cancel or navigating away without saving. The record's saved state is always visible in the background during editing — you can see what you started from.
View-first forms match how most users actually interact with records: reading far more often than writing. The interface reflects the actual usage pattern.