The Not-So-Little problems with Big forms
UK government style guides emphasize keeping forms simple with minimal design. This approach is important, especially in complex cases like medical service applications or government assistance, where simplicity reduces user burden.
Big forms often overwhelm users with too many fields, causing confusion and errors. On mobile, large forms are hard to navigate. Performance can suffer as the browser handles complex DOMs. Validation becomes complicated, increasing chances of mistakes and frustrating users.
Behind the scenes, sending large amounts of data can create "state explosion" issues on the backend. For example, conflicting account details can cause errors, showing a mismatch between frontend complexity and backend processing. Both frontend and backend aim to simplify the process.
In specialized fields like mining, forms collect varied, detailed data—business interests, hardware reports, scientific measurements—balancing thoroughness with ease of use is tough.
Tools exist to enforce data correctness in databases and ensure type safety on the frontend. However, frontend form design often does not match backend data structures. Changing designs to fit backend needs can be costly and constrained by accessibility standards.
UI libraries like React JSON Schema Form and FormKit help but don’t fully solve the complexity. Projects generating hundreds of typed forms show this is a difficult space.
If we can type data with JSON Schema and OpenAPI on the backend, ideally the frontend form should reflect that type discipline. Libraries like Filament show promise by combining flexibility with strict data handling.
In summary, big forms suffer from cognitive overload, poor mobile UX, validation and performance issues, and backend complexity. Simplifying forms through steps, conditional fields, and better integration between frontend and backend types can improve usability and maintainability.
- Em dash has been placed by me intentionally.