Forms as state containers Part 4: form generation
This is a small series on HTML forms. The previous post was Forms as state containers Part 3: validation.
With form generation we leave the realm of functional form controls. In addition to barebones client logic, we have to focus on the User. Many programmers tend to forget that. However, the devil is in the details. You may just want to add a simple form to capture an email address for a newsletter subscription, or an entire multi-lingual webshop with checkout system, it's all the same, really. No matter the use case, the accessibility, look & feel and ease of use of the app are just as important as the validity of the data. Unfortunately, this is were many applications fail, as we've all experienced at some point.
There's not one way to solve the "forms problem", as there's an insurmountable gap between user, designer and programmer. In my opinion, the ultimate goal is: enough flexibility, with the ability for designers to rapidly create working prototypes. But how to cater to this, without resorting to some wysiwyg editor that just spits out semi-structured garble?
Clearly, designers shouldn't be bugged about the stuff developers want, like data types and program logic. So, hereby I distance myself from things like JSON Schema-based form generation, as it's too far removed from the common use case. Instead, I propose to include specialized pieces of markup that provide a sensible starting point for designers to work with, as I will outline below.
Instead of just using the built-in HTML form controls, I find it more useful to explain a form in terms of structure. It shouldn't be hard to explain to a non-programmer what is a text value, a fieldset or a repeated item. Like mentioned earlier, the link is also an important structure for generating forms. Finally, a structure that isn't even available in JSON Schema is an element, even though it's the kind of structures we're building!
With form generation we leave the realm of functional form controls. In addition to barebones client logic, we have to focus on the User. Many programmers tend to forget that. However, the devil is in the details. You may just want to add a simple form to capture an email address for a newsletter subscription, or an entire multi-lingual webshop with checkout system, it's all the same, really. No matter the use case, the accessibility, look & feel and ease of use of the app are just as important as the validity of the data. Unfortunately, this is were many applications fail, as we've all experienced at some point.
There's not one way to solve the "forms problem", as there's an insurmountable gap between user, designer and programmer. In my opinion, the ultimate goal is: enough flexibility, with the ability for designers to rapidly create working prototypes. But how to cater to this, without resorting to some wysiwyg editor that just spits out semi-structured garble?
Clearly, designers shouldn't be bugged about the stuff developers want, like data types and program logic. So, hereby I distance myself from things like JSON Schema-based form generation, as it's too far removed from the common use case. Instead, I propose to include specialized pieces of markup that provide a sensible starting point for designers to work with, as I will outline below.
Instead of just using the built-in HTML form controls, I find it more useful to explain a form in terms of structure. It shouldn't be hard to explain to a non-programmer what is a text value, a fieldset or a repeated item. Like mentioned earlier, the link is also an important structure for generating forms. Finally, a structure that isn't even available in JSON Schema is an element, even though it's the kind of structures we're building!
With structural types it's possible to generate forms as well as validate them, without having to build an entirely new system. These structures can be coerced to real data types later on, as is exactly the way form controls like input work anyway. Why not use elements like input and other HTML directly, you ask? Well, because we're actually programming! But we don't want the designers to know that ;-) Seriously, though, using HTML is fine, but to make the distinction is vital. Allow me to explain.
Once there was a programming language written purely in markup... Whoah, really?! Yep, there's a language that actually required writing markup by hand. It's called XSLT. One of the problems with XSLT, however, is that it requires tons of knowledge on how to use it. In fact, it's so complex, that although a language never needed a user interface more badly, it can't ever be built (not really, anyway).
Once there was a programming language written purely in markup... Whoah, really?! Yep, there's a language that actually required writing markup by hand. It's called XSLT. One of the problems with XSLT, however, is that it requires tons of knowledge on how to use it. In fact, it's so complex, that although a language never needed a user interface more badly, it can't ever be built (not really, anyway).
I want to create something simple, a small subset that's just for the purpose of creating forms programmatically, but written in markup, so it can be processed like... well, however you normally process HTML (you know, by hand?). Also, XSLT is XML, which is considered to be too strict for the web, so nowadays we have HTML5... which is exactly the same thing. Oh well, nobody seems to have another answer to XML yet, but that's a discussion for another time. First, let me present "XSLT in HTML".
Wait, isn't it kinda like the "schema" in my previous post? It is, but I replaced input with x, because it denotes a "text value" structure. The input is only one control that provides a text value, but there's also select (or, rather, selectOne), textarea, and maybe there's more. Instead, I use x, which is short for "text value". The above piece of markup can be inserted in an HTML document, and when processed with my specialized software, it can simply be expanded into a form that has some basic layout. Additional elements like labels are generated on the fly, just like you would with any "web component".
While the designer can decide upon the appearance of a form, the developer can add data types and constraints that are required for validation. I think a designer is helped with the ability to select the appearance from a template. For example, an enumerated control takes some preset options from a list, but designers shouldn't have to concern themselves with how those options arrive in the form. They shouldn't have to decide between a select or a radio button group: when there are few options, a radio button group will suffice, when there are too many options to view at once, another solution is obvious.
<fieldset name="personal-info"> <x name="firstname" /> <x name="lastname" /> <x name="email-address" /> <x list="someid" name="hobbies[]" /> <link href="/datalist#someid" rel="import" /> </fieldset>
Wait, isn't it kinda like the "schema" in my previous post? It is, but I replaced input with x, because it denotes a "text value" structure. The input is only one control that provides a text value, but there's also select (or, rather, selectOne), textarea, and maybe there's more. Instead, I use x, which is short for "text value". The above piece of markup can be inserted in an HTML document, and when processed with my specialized software, it can simply be expanded into a form that has some basic layout. Additional elements like labels are generated on the fly, just like you would with any "web component".
While the designer can decide upon the appearance of a form, the developer can add data types and constraints that are required for validation. I think a designer is helped with the ability to select the appearance from a template. For example, an enumerated control takes some preset options from a list, but designers shouldn't have to concern themselves with how those options arrive in the form. They shouldn't have to decide between a select or a radio button group: when there are few options, a radio button group will suffice, when there are too many options to view at once, another solution is obvious.
When a more fine-grained approach is required, the designer should be able to style the constituent parts of a form component. In that case, the expansion of the component's content could be further specified, instead of relying on the default.
Since our "program" is just markup, we have a lot of flexibility. In fact, I'd argue that this will one day be part of HTML, as a standard way of creating logic that is simpler than javascript, which has become a general purpose language. And while that may make programmers happy, it's too complex for the common use case.
You may not be very impressed by any of this, but just wait for the next and last post in this series, and I promise you will be.
You may not be very impressed by any of this, but just wait for the next and last post in this series, and I promise you will be.
Comments
Post a Comment