The single-page complex form

Goal

The single-page complex form allows to fill in larger amounts of data and replaces the existing form with horizontal tabs. The main characteristic of this form is that it provides an instant overview over all key values, even those contained in other tabs (see also UX:the explanation below).

The data sets the form collects are organized using vertical tabs to make the forms wider than high. Inside a single form, the fields used to obtain the actual data can be grouped using various grouping elements such as blocks and field sets. In fact, the single-page complex form builds on the same principles as the standard form and also uses the same mechanisms to show notification messages.

Concept

Vertical tabs, which are currently not topped, use one short line to show the key values of the aspect they represent. These value lines are emphasized compared to the actual title of the tab. If you look at all vertical tabs at once, it is very easy to get an overview of all currently hidden values.

The single-page complex form is designed to guarantee good structured forms by providing a hierarchical set of grouping elements. The following picture shows the overall structure of the form.

The form uses vertical tabs to split a larger form into several sections called aspects containing one sub form each (3). Each aspects receives one vertical tab. If an aspect has several topics, which you don't want to or can't spread over several tabs, you may use horizontal tabs on layer 4 as an additional measure to sub divide one sub form into several sub sub forms (4). The fields on these forms may then be grouped even further: layers 5 and 6 correspond exactly to the two inner-most layers 3 and 4 of the standard form (see there).

In fact, the two outer-most layers 1 and 2 are similar to the outer layers of the standard form as well. The single-page complex form, however, may employ horizontal tabs on layer 2 to capture several content layers of the item you're capturing with the form. Do never use these horizontal tabs to sub divide your form. They are optional and should only be used to capture different semantic layers, which must be handled by different forms all together, but should be bundled together nevertheless. Multiple translations of the same item or the page references, both shown in the mockup above, are very good examples of such semantic layers.

Mandatory values on first form

Properly structuring and arranging form elements is often a UX task, but one that should be somewhat straight forward in this case, if you have a clear understanding of the type and structure of your data and use the UX:grouping elements described above according to their intent. Try to place all mandatory values into the first form of the first tab. The idea is that these important fields pop up immediately as soon as the form shows up. In a typical case, I would only have to look at the first form, fill in values there, glance over the summary texts of the other tabs to verify if the defaults match my expectations, and if they do, click save. I should not have to click through every tab sequentially once I'm accustomed to a form and don't have any extra requirements.

Providing meaningful value lines

If you look at all vertical tabs at once, it is very easy to get an overview of all currently hidden values, if the values shown are meaningful and the tabs don't contain forms with a large number of fields. Don't show every value in a tab, but focus on key values instead. Try to summarize what's on a tab rather than simply listing the values. It is actually amazing how much information fits in just a couple of words. If it doesn't fit, consider using two lines, but don't go beyond that. You may also want to consider splitting up one tab into several tabs.

When not to use this form

Do not use such a form, if you end up with a single vertical tab (3) and no horizontal tabs (2) only after structuring your form: in this case, employ a simple standard form instead - it completely matches your requirements and is actually quicker to grasp. Likewise, if you detect that you actually intend to collect sets of data using multiple steps, refer to the multi-step process instead.

Notifications

Please refer to Showing validation messages in forms for a complete treatment of validation and other messages in forms.

Note that field descriptions are optional. The form may choose to only provide a help page (which is required, however).

Growing and shrinking dialogs

If the form is shown in a dialog, it will have to adjust its height to accommodate previously invisible form elements or messages - it does so by using a transition showing the dialog growing in size. Try to avoid scrollbars, if possible. If you must use a scrollbar, check out the concept for UX:long forms below.

The dialog only reduces its height, if the reduced form occupies less than 2/3rds of its current height. This avoids too many movements in the interface. If a dialog chooses to not reduce its height, the superfluous whitespace is inserted right above any possibly showing field description, or else above the bottom edge of the form. E.g. in the first mockup on this page, this would be between the last field and the field description.

Note that the dialog must not change its size to fit the help page, but shall retain its current width and height. If the help text does not fit into the current dimensions, add a scroll bar.

Abort editing

If the form is shown using an overlay dialog or a dialog in a separate window, the user aborts editing by clicking the "close window" button in the upper right corner or by clicking the "cancel" button. If the form is shown on a page directly, the only option is the "cancel" button.

Preview

The whitespace between the last vertical tab and the lower edge of the form should actually be large enough for the form to look good. Some forms may actually use this space to show a preview of the content item they allow to edit. This is a very convenient and clear way to link to the item the user is looking at. Such a preview only works, if there's still enough whitespace between the preview and the last tab - if the two are too close, the resulting form will look too crammed. If in doubt, leave out the preview.

Long forms

If a sub form has many elements, add a scrollbar inside the tab to allow to scroll it. If there are too many tabs, consider re-engineering the form or splitting it up into a multi-step process, if applicable.

If that is not possible, add a scrollbar on the very right to allow the tabs to be scrollable as well. Note that a possible preview will scroll as well - this is almost certainly not what you want, so consider splitting up the form entirely.

Please also note that messages must not scroll - an error message at the top of the form or a field description below must be sticky. The scrollbar on the right edge should only scroll the tabs (and a possible preview). See the remark on long standard forms for a approximative visualization of this requirement.