What is the best way to show conditional fields?

Question

We are creating a desktop app where (business) users can enter contracts. The issue is that the contract form contains a very large number of fields, with some of them being conditional. An example would be:

• Contract can be "Open" or "Fixed"

• If a Contract is "Fixed", users need to additionally enter the duration (number of years). They are not using calendars they just enter numbers.

Issue is that we want to make the form as simple as possible for the users. There are many fields, so the more the app can do in the background, the better... But such conditional fields add to the complexity.

What I came up with is:

1. Typical show/hide the additional field as presented on screens 1&2. The choice is quite obvious, but the form jumps up/down. It also works well if there are a few radio buttons (2-3). But if there are more radiobuttons - it will fall apart.

2. Convert the two radio buttons into a checkbox + edit (screen 3). The form looks cleaner, but it is not so obvious that "unchecked" means "Open" and "checked" means "Fixed Term". It also may not always be possible.

What do you think would be the best presentation of such conditional fields? There are numerous such cases on this form and I would like to come up with a good generic solution. Or maybe you have some other ideas? I have searched the net for examples but failed to find any...

Answer 1

I think you could have better use of space and the screen would not have to jump
You don't need that much space for years
Only have the years visible if Fixed is checked and years text in gray so it looks like an instruction

As for screen jumping have years toggle from visible to hidden (not collapsed)
Different languages use different verbs but hidden reserves space so the the screen does not jump

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 2

If you are showing all fields at once, grouping them in a way to show relationships is important. Don't forget to disable items that are not relevant given the current selection, and be sure that your input fields have units (i.e., "years").

^{download bmml source – Wireframes created with Balsamiq Mockups}

You can compact the form a bit, if it is visually appropriate:

^{download bmml source}

This is relatively clear and a user can easily understand the relationship between the radio buttons and the text entry field. But what if the user has a duration set and then sets it back to "Open"?

^{download bmml source}

This can easily create confusion for a user who is quickly scanning the form to pull information from it. A solution is to clear out the duration field, but you are now performing actions for the user that they did not explicitly ask you to do (which is generally frowned on).

Showing the fields that are only pertinent to the user is generally a better practice. It becomes more important in mobile, but is valid in desktop applications too. The idea is simply to not expose items the user does not need by default.

^{download bmml source}

LukeW has a video discussing this: http://www.lukew.com/ff/entry.asp?1896

Check out the 2:30 time mark for the specific discussion. He also calls out that studies shown that hiding irrelevant form controls:

• create forms that are faster to complete
• have less errors
• result in more satisfaction

Presenting your options in a sentence structure can also help your user see the options in the context of the end product.

^{download bmml source}

How your overall form flows is just as important in all this. You need to make sure that it works for the language of your user and how they process the data on a daily basis. For example, if you are dealing with people who type this in once-ever that is very different than people who have to fill this form out several times a day!

Answer 3

Ran into similar situation in the past. We ended up solving it with a vertical form design and placing the fields this way:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Vertical forms are the fastest to process if you're doing strict data entry. So if it's possible to redesign the form structure that might work.

If not, option 1 is better than option 2 from the point that as you said, it's not crystal clear that unchecked means "open contract". The "show/hide" animation from option 1 should make it clear the 2 are related. Also if you change the label from "Duration" to "Term Duration" that'll be even more clear that the 2 fields are related.

Answer 4

The Why

According to this great guide on 58 Form Design Best Practices & Form UX Examples:

Use conditional logic to shorten your forms

Conditional logic (sometimes called 'branch logic') is where you only display a question if a user has answered a previous question in a certain way.

This technique reduces the average length of your form, while also reducing form abandonment by not displaying questions that might be irrelevant to certain users.

NNGroup also advocates for Conditional Logic in Forms and Applications

Eliminate irrelevant steps

Users never need to see questions and options that don't apply to them. If, for example, your business logic requires you to know whether customers are married, don't show single customers questions relating to the spouses they don't have.

The How

There are a lot of possible forms, so there's not going to be one right answer.

Globally speaking, dynamic elements will fall into 2 possible categories:

1. Dynamically appear on current page
2. Added to flow in subsequent views

1. Adding a conditional element to the current page

Any new element must either a) occupy currently unused spaced or b) displace existing elements.

In either case:

• Avoid page jumps when adding elements to the current page
• Use animations to reveal new elements (e.g. Bootstrap's collapse)
• Highlight new fields that require user attention (e.g. jQuery UI's highlight)

Example of a Conditionally Added Field:

Exception: Conditionally disable VERY common fields

If you have a highly common field that the majority of your users will expect to be visible, users may be confused if they are unable to find it. In that scenario, you should conditionally enable/disable it based on user testing, feedback, and research.

Note: All disabled fields should always include helper text with an explanation of why the field is disabled and how to enable it if applicable:

Example of a Conditionally Enabled Field:

2. Multi-Page Wizard - add dynamic step

Any wizard/stepped field collection should always give the user a sense of their current progress within the total set of questions. There are pros and cons of hiding/disabling anticipated sections that we may or may not need.

• A few additional pages is okay and will keep your form visibly short
• Don't add so many dynamic pages that users are spinning their wheels

Example of a Wizard with a conditional section:

^{Here's an interactive demo in Fiddle}

Luke Wroblewski also offers several layout options for Selection-Dependent Inputs

Answer 5

A general rule of forms is "keep them as short as possible".

I think the first one works best for that, the only problem you would have is if there are too many radio buttons, in that case when there are too many (whenever you feel radio buttons lose their advantages) change to a dropdown. Also, a nice animation helps to make sense of it.

And you also avoid possible confusing fields for users that don't need them, so they don't have to think if they need them or don't, you do it for them.

Answer 6

Last option with the checkbox is the cleanest. However, you can also drop it and just leave the input control with the guidance text to skip the field if the contract is open.

^{download bmml source – Wireframes created with Balsamiq Mockups}