Goal
The single-page complex form allows to fill in larger amounts of data. The main characteristic of this form is to provide an instant overview over all key values. Its data sets are mostly independent of each other, but still connected in the sense that they are part of a larger whole. While these sets could be spread among multiple tabs, in your use case, you see a clear advantage to make all of them visible at once on one page.
In order to improve orientation in the form, data shall also be grouped visually. Each group of data must be consistent and constructed such that it may largely stand on its own. In addition, we distinguish between important and less important data sets, the former being visible at all times while the latter may be hidden at first.
Concept
As stated in the goals, we distinguish between data sets containing values, which have to be entered every time or at least most of time a user fills out the form, and sets which are changed less frequently. We use a combination of fieldsets to group important data and accordion-type tabs for hiding forms for less important sets. Important data sets must be visible immediately when opening the form and may not be hidden by the user.
In contrast, less important data sets are mostly hidden, but show a block containing a title naming their topic and a short overview of the values of their most significant fields. These overviews are an essential add-on of the complex form: since less important data sets are usually not touched when filling out the form, the overviews must present their default settings in a concise, readable, quickly understood short sentence or sequence of words. We want to avoid that the user has to open these sets only to check the values contained in them. The advantage of the single-page complex form to present all settings at once largely depends on the quality of the overviews.
Do not use such a form, if your form actually does contain data sets, which are more like multiple, connected steps. In such a case, use a multi-step process. Also, if the overview over all values is not a requested feature, your form may be less overwhelming if you break it up and make the parts accessible using tabs.
Notifications
Messages such as description for fields as well as warning and error messages are shown right above the bottom edge of the form, as is also shown in the mockup above. Please refer to Showing validation messages in forms for the complete treatment of validation messages in forms.
Note that field descriptions are optional and the form may alternatively provide help screens.
Growing and shrinking dialog
If the user opens the block of a less important data set, a surrounding dialog might have to adjust its height to accommodate the entire form. It does so using a transition - introducing scrollbars is unwanted.
If a block is closed again, the dialog only reduces its height, if the reduced form occupies less than 2/3 of the current height. This avoids too many movements in the interface. If a dialog chooses to not reduce its height, the superfluous space is inserted right above any possibly showing notification message or else above the bottom edge of the form box. E.g. in the mockup above, this space would be added between the "language settings" block and the field description message (similar to what is defined for multi-step process forms).
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. If the form is shown on a page directly, use a "cancel" button instead.
Help screen
The form may also provide a help button offering additional information about the values it collects. Try to make it clear what you expect from the user by providing a good, initial description and clear labels in the form. Only provide an overall explanation in a help screen through the help button, if this is not enough.
Note that the dialog must not change its size to fit the help screen, but should retain its current width and height. If the help text does not fit into the current dimensions, provide a scroll bar.
Additional notes
If presented in a dialog, the form is embedded in a colored frame, which contains all controls, such as buttons for submitting the form, to cancel submission in a review step or for closing a help screen. The form frame should focus on content, the frame on control. If the form is presented on a page directly, leave out the frame, but still ensure that the form itself resides in a box and the controls are arranged around it using a layout much like in case of the dialog.