Form builder that allows dynamic flow based on answers

Question

I'm working on a project where we need to create a form builder that allows nesting of follow up questions based on a questions answer.

Currently we're thinking of a treeview that allows dragging and dropping of question types (multi-select, free form text) onto the tree like so:

We would then have an editor panel next to or below to add answers or modify the question.

This will work, but it doesn't really feel like you're creating a form.

I did a bit of research, and it looks like most form builders use drag and drop on to a realistic form:

And then have conditional logic on future questions:

This seems much more flexible, but seems like it could quickly become complicated, and I couldn't find an example that seemed intuitive (which question was triggered by which answer).

So my questions are, any examples of this done differently? Any advice on whether I should pursue the treeview vs the conditional logic?

Answer 1

This is a very abstract customization problem. Flexibility creates complexity. I don't think there's going to be an elegant solution that will meet all the boundary cases.

Having said that, can you use domain knowledge to narrow scope? i.e. who is the form builder for?

• Are you building this as a general tool? In which case, we can't predict how deep a form will be.
• Is this for a specific domain? Perhaps this will allow you to create templates. Maybe it'll restrict the question-types. If you foresee a 100-level deep branch, maybe a form isn't even the right interaction. Or questions as a unit is too granular and you should be looking at this at page-level.

---

Re: tree vs. conditional-logic.

You would need a condition wizard regardless of tree or form view: When you're adding a new node to the tree, you would need to know if you need to branch. When you add a new field to the form, you need to know if it has subsequent questions. (Although the example of the condition wizard that you provided isn't very good. It's too systematic/technical for the general user.)

I'm partial to the tree. It clearly communicates the decision points. It's harder to communicate that logic in a form. Although I would go with a visual tree rather than a text tree:

I would not fixate so much on it not looking like you're creating a form. You're really performing two actions: (1) Creating the interface--the form, (2) Creating the behaviour--the conditions. It's hard to mash the two together because the behaviour requires the user to interact with a form that doesn't yet exist. How can you show something that doesn't exist yet?

In the diagram that I provided, the user is seeing the behaviour. When he clicks on "Add a field", the system would launch a dialog that initiates task (1). This is the condition wizard that I didn't mock up.

The drawback of the visual tree is breadth (limited by horizontal real-estate). Whether or not this is the right approach, again, will depend on the context of the form builder.

Answer 2

Yes, this will quickly become convoluted.

You add iterations (how many employees do you have? 5 Give us the name of employee 1.. Give us the name of employee 2) and basically you have a complete programming language.

A complete programming language makes people want complete programs, and a decision tree of an average enterprise program can be 10-100 levels deep, so I wouldn't recommend a tree representation.

Another visual abstraction would be pipe-based, like Yahoo! Pipes or Apple's Quartz Composer:

You can also do flowcharts, or perhaps block diagrams, like Scratch or App Inventor:

(Image credit: The Open Sourcery)

Answer 3

You could simply have every possible question on your tree present on the page(s), but only show and mandate completion of the ones users ought to see based on their previous responses using if/than + javascript