I will definitely be using this! I was just about to code my own for a project I'm working on. The ability to put the fields in columns would be great. An example would be to allow some to have two separate text fields, like First Name & Last Name, on the same line.
Yay a backbone.js article! No hate on Angular.js but that's mainly what I've been seeing on HN lately. I miss the Ember.js, Knockout.js, etc.js articles.
I disagree with this type of form builder. In a previous job, we built lots of forms (for gov/banking sectors), had a formbuilder product, and used multiple commercial formbuilders too. They were all more complex but fundamentally the same: making you focus on layout and field types up front, not content. (think Powerpoint vs LaTeX)
What we needed, it seemed to me, was something that started simply with the list of questions the user wanted to ask, and elaborate on that, adding field types/lookups/help text after the fact. The type of response had to be something you could change without deleting the form control and replacing it eg; start with a text box. Change it to a date picker. Then change it to a selection when you realise that only Monday & Wednesday are valid answers. This kind of change happened pretty regularly, but is stupidly hard in most form builders.
The other mistake of allowing too much flexibility in layout doesn't apply to Formbuilder.js - but many products made it easy to design forms that were inaccessible, or that wouldn't work on different screen sizes, or couldn't be laid out well on paper (ultimately many of these forms had to be printed for archiving). The form builder should generate accessible layouts that worked on multiple devices, and very little of the layout should be in the hands of the end user.
A less visible aspect of what was wrong with form design was versioning the data model. A user may submit drafts of the same form several times, over many weeks (applications get rejected, plans change etc). Meanwhile, the regulations driving the forms would change, or bugs would be found, and the form would change. It's important to be able to load the old data in a new form, and not choke on validation failures. Particularly, if some piece of data is now missing that means large optional sections are no longer displayed, we should not lose the data that the user had filled in in those sections.
A final data model issue was that we were also creating xsd's for electronic submissions etc. At that time the best solution was to massage the data after form submission into a schema specified format; but this meant that validation code was essentially written twice (once in the form, once in the schema), and the two were out of step. I wanted to generate schemas for valid complete forms, and to be able to clean up the saved data (which may be out of step with the current form version, see last para)
Anyway it turned out all this was possible, but I was leading a different team from the formbuilder one, so they went with a more conventional design. Sadly part of this was commercial: producing complex forms layout-first is hard enough for non-techies that the company could offer this as a service...rather than producing a better UX :(
Coincidentally, I am working on a BSD-licensed form builder (as part of a larger project), and I found your comment timely and insightful. You may have unknowingly improved our form builder, so thanks :)
14 comments
[ 3.5 ms ] story [ 46.2 ms ] threadThen it can be renamed PageBuilder.js. Any plans to do so?
What we needed, it seemed to me, was something that started simply with the list of questions the user wanted to ask, and elaborate on that, adding field types/lookups/help text after the fact. The type of response had to be something you could change without deleting the form control and replacing it eg; start with a text box. Change it to a date picker. Then change it to a selection when you realise that only Monday & Wednesday are valid answers. This kind of change happened pretty regularly, but is stupidly hard in most form builders.
The other mistake of allowing too much flexibility in layout doesn't apply to Formbuilder.js - but many products made it easy to design forms that were inaccessible, or that wouldn't work on different screen sizes, or couldn't be laid out well on paper (ultimately many of these forms had to be printed for archiving). The form builder should generate accessible layouts that worked on multiple devices, and very little of the layout should be in the hands of the end user.
A less visible aspect of what was wrong with form design was versioning the data model. A user may submit drafts of the same form several times, over many weeks (applications get rejected, plans change etc). Meanwhile, the regulations driving the forms would change, or bugs would be found, and the form would change. It's important to be able to load the old data in a new form, and not choke on validation failures. Particularly, if some piece of data is now missing that means large optional sections are no longer displayed, we should not lose the data that the user had filled in in those sections.
A final data model issue was that we were also creating xsd's for electronic submissions etc. At that time the best solution was to massage the data after form submission into a schema specified format; but this meant that validation code was essentially written twice (once in the form, once in the schema), and the two were out of step. I wanted to generate schemas for valid complete forms, and to be able to clean up the saved data (which may be out of step with the current form version, see last para)
Anyway it turned out all this was possible, but I was leading a different team from the formbuilder one, so they went with a more conventional design. Sadly part of this was commercial: producing complex forms layout-first is hard enough for non-techies that the company could offer this as a service...rather than producing a better UX :(