The recent DevCamp in New Jersey presented several sessions on new developments in CiviCRM land as well as showcased several of its inner workings. One session presented by Core Team member Tim Otten stood out for me: Form Builder. If you’re like me, you listen to folks like Tim with a great deal of respect and appreciation for what they say (and do). That doesn’t necessarily mean you understand everything he says, but you know enough to know that what he’s saying is probably right and well thought out! Occasionally, you do understand it though.
I’ve had one of those moments, and I wanted to report back to the rest of the world. As you might be aware, we kicked off a Make It Happen campaign to flesh out a working prototype of Form Builder. In the Make It Happen campaign we talk about building forms on the fly, mixing and matching fields and functionality. That’s accurate, but there’s a bigger picture here.
Let’s start with the CiviCRM administrator area. You log in, view the dashboard, and bounce to a few contacts, maybe manage an event and then a contribution page. In the process, you’ve viewed a half dozen screens that, right now, you really have little control over. Imagine if you could have much deeper control though. Imagine if you could take any of these screens and, through a nice user interface, change layouts, expose/hide fields, and control functionality at the field level. If you’ve used the recently released Contact Summary Editor extension, you’ve probably had a small taste of this sort of capability. But take that extension, add a bunch more functionality, and roll it out to every screen where there’s a “form” in CiviCRM, and that’s form builder.
Aren’t there a lot of “forms” in CiviCRM? Well, yeah, but that’s the point (and the reason why this is a big effort!). This effort is more than about building forms. It fundamentally changes the way organizations can display and use data within their CiviCRM instance. It deepens the control over CiviCRM and how it’s used in its entirety, allowing organizations to more readily customize their data and workflows.
Sounds exciting, right? How does it apply to public facing forms, like online event registration and contribution forms? Currently you can expose fields via profiles, so you can capture target data in addition to what is built into the stock event and contribution forms. But, let’s face it, those are pretty clunky and only provide partial control over the entire form. So, think of Form Builder as a replacement for profiles. Actually, think of it as a replacement for profiles and the stock forms (event, contribution, etc.), because in truth, you will be able to fully customize public facing forms.
The name “Form Builder” probably doesn’t do this effort justice because it creates the notion that you will be able to, well, build forms. While that’s certainly true, Form Builder fundamentally changes the way users can use, display and capture data within CiviCRM. In layman’s terms, take the Contact Summary Editor extension, shoot it full of steroids, and roll it across CiviCRM in its entirety.
That is Form Builder.
There’s a prototype underway now, and plans are taking shape to roll out a functional “piece” of it in the near future. You can help make it happen. Make a donation today and help bring this amazing capability to CiviCRM.
Thanks for articulating this clearly Josh. I know when i first heard this I probably slipped quickly in to the 'but drupal's webform already unlocks so much' - but that was before I realised this could help us transform "add a new Contribution page" and other such screens.
Knowing the fundamental leave of transformation this is offering I have now happily made a contribution for the MIH. Thank you all for the leadership you continue to provide for this amazing project.