The Truth About CMS Form Builders

By Deane Barker • Posted on January 11, 2017

Episerver recently re-did their form building tool. It’s really quite good now. The old one was a mess (they’d be the first to admit that), but the latest incarnation is as well-built as anything I’ve seen. It works as well as some dedicated form building apps.

But it’s still not magic. And when it comes to form builders in general, I don’t think a lot of people realize this. The best CMS form builders in the world still have shortcomings, and we generally expect too much from them.

Form building in CMS is like personalization: it’s a thing people say they want, but also a thing for which they vastly overestimate their need.

Whenever we do pitches and form building comes up, I always feel like I need to make a few points. However, it never fails to seem like a third-rail – “don’t you dare call into question our need for a form-building tool!” And, invariably, it fades away into other concerns, so I never get to mount a significant case around it.

So, here then, is a (too) long sermon on all the things I want to say about form building whenever a client states a need for it or begins to evaluate it alongside other features.

Contents

You will not use a form builder nearly as much as you think

One major reason editors want form builders because, at some level, forms embody their dependence on developers. On a day-to-day basis, CMSs have liberated editors from having to call a developer for almost everything. Almost. Form building promises to resolve that Last Mile .

Some editors have horror stories about the last time they had to get a form built, and they’re seeking to avoid that. They have memories of bottlenecks, delayed projects, and the feeling that “I can do everything I need except that one, single thing…” This might be true, but when you really press someone on how often they think they’ll need to build a form – or how often they’ve built them in the past – the truth usually comes out: not often.

I was just sitting with a prospect the other day who made the traditional case that they need to be able to build forms whenever they wanted with no help from their IT staff. I pressed her on how often she thought she would do this. There was a long pause, then:

Maybe once a year. If even that.

It sounds harsh, but there’s a collective delusion among editors that they’ll be slinging new web forms around all the time. Going back to my earlier point, I think this is because the lack of this capability has stuck in their heads – it’s a much more prominent memory than anything else because the problem was so glaring. What they lose here is the context of how often the problem comes up. Yes, the lack of form building might have been a Big Problem, but if it was only a Big Problem once in the last three years, is it really a Big Problem?

After your website launched, how many forms did you need built in the following year? For most of my clients, the answer is “not many.” How many forms will you need built in the next year? It’s usually the same answer.

Some content management environments exist where the need to create and edit new forms comes up all the time – intranets, in particular, are an outlier. And, yes, some companies are releasing multiple marketing campaigns every quarter with individual landing pages and conversion forms. But are you one of them?

Most websites have a handful of forms, they change rarely, and new form requests are not common.

Building a usable form is harder than you think

Content consumption falls into patterns. We mostly read a passage of text in pretty much the same way, or watch a video the same way. There is room for design and interpretation, but not many editors can screw up a series of paragraphs running down a page. There just aren’t a huge amount of variables, and most of them can be controlled.

But it’s really easy to make a crappy form.

Let’s think about all the things you have to account for when making a form:

Clearly, that’s a lot of stuff. Every form is a massive decision tree – every decision leads to multiple other decisions, and the number of results is exponentially large. Give two editors the same data profile, and there’s a chance the two resulting forms will be hardly recognizable from each other.

Forms are acute usability and design problems. There are entire books written on how to design forms well. Tiny changes in design can have huge effects on the number and quality of submissions.

Giving editors the power to build forms whenever they want might just result in a lot of really bad forms. Some extra time spent having a form designed, prototyped, and tested might be exactly the thing you need.

Form builders only give you “freedom” in a narrow range of use cases

There’s often confusion between simple form building and application development. Editors claim they want the former, but they’re often dreaming of the latter.

The core use case for a form building is this: a visitor submits a form, and that data is emailed to someone, or stored in the CMS for later retrieval. Full stop. For many CMS form builders, this is the only use case that gives editors the freedom to do what they want, and even then it has to be qualified in numerous ways.

There are three potential integration points for a form:

  1. When the form is rendered.

  2. When the form is validated.

  3. When the form is submitted.

Each of these points might need interaction with the server. And in each case, those interactions often need to be developed and cannot be done by an editor.

Let’s consider a completely realistic use case:

Any one of these requirements is going to need development. Some form building engines have options to handle these situations, but I give long odds that a single system is going to give you all the options you need. Integrating with external data and systems is especially difficult because data is so naturally variant that there’s just no way to account for everything.

Even form layout can require programming or at least something like it. Many editors want some fields to be conditional – Field Z appears only if the visitor picked Option Y on Field X. Other editors want the ability to create multi-part forms, which is extremely rare (Episerver’s new engine does it, which is commendable). The combination is even worse – some editors think it should be simple to have a multi-part form in which entire sections are conditional and there’s branching and looping logic (so the same section can be filled out multiple times).

That is not a web form. That is a web application. There are so many logical avenues to go down that it’s just not reasonable to be able to roll these all up into a simple interface than an editor can use.

Assuming you did get it rendered how you like, form submission actions can be deceptively vexing. Form engines generally offer three options:

  1. Email the results

  2. Store the result in the CMS

  3. Post the result to a URL, or trigger a webhook, or something similar

You can usually do any combination of the three.

In many cases, emailing the result is fine, but it some cases it’s absolutely not. There might be security concerns (secure email is rare), and there’s the persistent problem that just throwing another email at someone’s inbox is rarely an efficient way to get something done.

Storing the result in the CMS is handy, but again, there can be security concerns because you might have private data on a server which is often publicly available. Additionally, in many cases, the person who has to deal with the data is not an editor – they occupy some other role in the organization. To access the data, they have to have access to the CMS and have to be aware that something was submitted (there’s the email thing again).

Often, you need a record created in some other system. The last option accounts for this, but it’s a rabbit hole of integration. Vendors will say, “with webhook/POST, you can effectively do anything!” Yes, but you have to have a developer code the second half of it for you.

Sure, you can post that form to any URL endpoint that you like, but what’s waiting on the other side? Someone probably has to code that.

And if you suddenly don’t like the way the form works and want to add or change a field…did you just break the endpoint? Whatever gets developed is expecting data in a certain format. If you adjust the form (using the “freedom” a form builder grants you), you might have invalidated all the development.

You effectively now have a web application in two parts – the form is controlled by the editor, and the endpoint is controlled by the developer. If I was that developer, the first thing I’d do is change the permissions on the form so that no one could modify it. Ironically, now you’re worse off – you’re depending on a developer who has to “code” half of their application inside a CMS.

For most purposes, form builders are closed systems. If they’re built into a CMS, they can freely interact only with that CMS without usually requiring additional development. They can refer to content, they can store results in the CMS, and they can usually send an email. That’s about it. When a form needs to reach outside the CMS to do anything, then you’re right back to needing the development work that you sought to avoid in the first place.

The most usable form builders generate very generic, derivative forms

I’ve enjoyed working with the Drupal Webform module. I deployed it for my church and I’ve developed several forms with it over the years. It works well, and here’s why: the forms it generates are extremely similar, boring, and predictable.

Remember when I said that designing a form is harder than you think? The best way to reduce this complexity is to drastically limit a form designer’s options. The form builders that editors seem to get the most use out of, it seems, are the ones that force them into very narrow channels of UI design.

Sadly, these are also the form builders editors don’t want. Editors often crave complete freedom when building forms. It’s almost like they want every form to be a masterpiece of interpretive art, and they resent any attempt to limit their options.

But boring forms work. The Principle of Least Astonishment tells us that users prefer to be able to predict what is going to happen in an interface. Forms that lack visual complexity are inviting, and a series of form fields that work pretty much the same way gives users a sense of comfort. If a user fills out more than one field on your site, having those fields look and work similarly provides cohesion. These are good things.

Forms are complicated enough. The way to make them worse is to allow every editor to run wild with all the possible variables they can use. Forms can be styled through CSS to be clear, concise, and usable, but only if the core markup is predictable and, yes, boring. More options mean more complication in the interface, more chances for something to go wrong, and less consistency between forms.

When it comes to forms, you need to be willing to stay boring. Your users will thank you and your form builder has a better chance of keeping you happy.

A truly integrated form builder will balloon your design budget

If you have a single form on your website, that form can be specifically designed. Your stylesheet can have rules to style the elements on that form so it looks good. However, if editors can design any form using any number of elements in any combination, that opens up a black hole of design problems that need to be preemptively solved in the abstract so the site can be ready for anything.

Refer above to the complexity of designing a form, and know that all that stuff has to be styled too. As a designer, if I know you can drop any type of form anywhere, I need to examine each form element in isolation and come up with styles for it. I have to design and style field elements, field labels, section labels, field validation text, global error text, help text, submit buttons, etc. I have to make sure that any design puzzle you drop on a page looks cohesive and well put together.

Of course, you don’t actually have to do this, and most implementations don’t. In most cases, they have a representative form or two on the wireframes, and these are specifically styled. Other forms just kind of make do. But then you get two cascading problems:

  1. Some forms look terrible. If an editor uses odd elements or some off configuration that no one planned for, you get an awkward-looking form, in among an otherwise nicely designed site, which means…

  2. …credibility suffers, along with response rates. Awkward forms make people uneasy, and if something sticks out like a sore thumb, you lose any goodwill and implied credibility from your design.

What usually happens is that the form builder gets used sometime after launch, and the result is unique or uses some construct that other forms haven’t used (remember all the variables at play). It comes out looking…wrong. So the dream of an editor being able to create a form with no help comes tumbling down when everything has to stop so a designer can debug what’s missing, a front-end developer can code the correct CSS, and dev ops can deploy the changes.

Designing an all-encompassing, flexible “palette” of form elements is a lot of work. It requires thought, talent, testing, and some speculation of what you might want to do with it. This is expensive. And given my prior point about how much less you’ll use a form builder than you think, the payoff here is low.

Consider this: if all permutations of a form builder were accounted and designed for so that there was no way an editor could build an ugly, awkward form, that portion of the design budget would likely dwarf everything else.

Relatively speaking, vendors don’t put a huge amount of effort into form builders

Truth: in most cases, CMS vendors don’t love form builders. They have to include them because other vendors have them, but they’re largely uninterested in doing them well. They do them only to the extent that they have to.

Expect form building demos to be very limited and very controlled. When a vendor shows you a form builder, understand that this is dressed up and staged like it’s a wedding day – the form builder is likely never going to work that well ever again.

The lack of emphasis here is not unfounded. A content-based website is going to push content out much more often than it takes content in, so a concentration on output functionality is appropriate. Additionally, form building is rarely ever the main selection criteria, it’s usually just somewhere down the list. And even the best form builder in the world can’t make up for terrible performance everywhere else unless form building was the only thing the website needed to do.

(And it’s not just the vendors. Integrators usually hate the result too. I had a terrible experience last year with Sitecore’s much-vaunted “Web Forms for Marketers.” It was a disaster. Several Sitecore integrators told me, “Yeah, it sucks, don’t use it.” Even better: there’s a YouTube video about WFFM called “Welcome to a World of Pain” with a slide which refers to the product as “Fucking Webforms for Fucking Marketers.” In the end, form builders basically make everyone unhappy.)

Another caveat: be careful that vendors aren’t letting development creep into discussions through the back door. You might ask, “Hey, can this form builder automatically create records in my custom CRM system?,” to which the vendor answers “Yes!” Left unsaid was “…because it can post the form contents to any URL, so you can have a developer build a custom integration on the other side of that.” Technically the form build can do that, but it’s probably not what you really want.

Closing Thoughts and Potential Solutions

Let’s a take a breath for a second…

This post sounds really negative, and I’m sorry for that. I don’t mean to condemn all CMS form builders. There are some very good ones. But I will say this, conclusively –

In my almost 20 years of doing this, no form builder has completely lived up to my client’s expectations. All of them have disappointed the users to some extent. The most valuable thing I can do as an integrator is to simply manage (read: lower) their expectations.

So, what are the solutions here? If you’re staring down a CMS purchase, what do you about form building?

Some ideas:

Form building is a consistent source of problems and frustrations in every CMS implementation. These mostly seem to source from unrealistic expectations and an inability for prospective CMS customers to put the feature in the correct context and line it up accurately next to other features.

You need to step back and take a long view of your need, the feature, and what you actually might achieve with it in the real world. Some honest answers and reflection will likely lead you different conclusions than you first expected.

This is item #17 in a sequence of 353 items.

You can use your left/right arrow keys or swipe left/right to navigate