This might seem like a pretty simple question. If you look at a form you generally see fields, labels, descriptions (if you’re lucky), and maybe some other input types like checkboxes or radio buttons. In our experience, most people conceive of forms in the way they are presented, meaning the interface and logic are tightly bound together and there is no conception of them as separate entities. This is reinforced by the tools that are used to make forms, where logic is built into interface components for drag and drop or WYSIWYG (pronounced whiz-e-wig to the uninitiated) style editors.
Before forms moved from paper to digital, there was no real concept of a form “interface”. On a piece of paper, form fields and input types are static and the natural assumption is that all of the logic happens with the person processing the form. Early digital forms were mirrors of their analog counterparts, displaying a form exactly as it would be experienced on paper. As solutions have evolved, concepts and practices from web UX and UI helped to enrich data capture experiences.
Having a nice interface is certainly charming but is not inherently valuable to a business. The logic layer of a form is where the magic happens. This is the engine that drives the process and ultimately where the real value of forms solutions can be found. The logic layer is responsible for preparing form data to be consumed by other systems and then submitting that data.
The logic layer is where you can put intelligence into data capture experiences, which turns manual or inefficient processes into great ones. Dynamic behavior like showing and hiding fields, pre-filling data, and validation patterns ensure that data arrives in good order while reducing the cognitive burden for end-users. When data arrives in good order it takes far less effort to take action on that data, and actionable data should be what a form solution is all about.
This lower-level layer is often misunderstood. Since forms are primarily used to collect data, it makes sense to take a moment to understand how that data is expressed and organized. The data layer is usually composed of a structured and serializable format like JSON or XML. The structure is important to defining information hierarchy. If you’ve ever worked with systems that expect or produce flat formats such as CSV or tab-delimited data (the 90s called, they want their data formats back), you understand the pain. Another important aspect of the data layer is that it should be serializable. Since data is usually collected, transported, and processed, it’s important to use a format that travels well. Serializable formats like JSON or XML can be expressed with simple text which is what gives them those properties.
Lastly, the data layer is responsible for interoperability. Most tools can easily process and parse formats such as JSON and XML, but the information hierarchy mentioned earlier often comes into play to allow multiple systems to agree to a defined structure that allows specific data elements to flow between systems. To achieve this, data schemas are often used to describe the structure that data payloads must respect. If you’re working with a data capture system that can’t produce a predictable data structure, prepare to have some fun.
Decoupling the interface and logic layer is nothing revolutionary, and is how most web forms operate today. However, the focus of most forms technologies for the last two decades has been on building form interfaces and making it easier for non-technical stakeholders to be able to do so. This approach removes barriers to building nice-looking and functional web forms but has marginal returns on building better processes.
At Morf, we think the interface should be table stakes. Beautiful, responsive, themeable forms aren’t something you should have to build but are rather a byproduct of designing a great process. We contend that if the value exists in the logic and data layers, why are we spending so much time and money on the interface? It’s time for machine generation.
Our message is simple – stop building forms, and start using them.