Considering User Experience

This topic describes concepts related to using forms that implementation teams need to consider when designing forms.

In general, when designing forms always seek to optimize usability and accessibility and consult industry-standard design guidelines to help address any challenges.

Required Fields

The system validates that required fields contain values prior to a submit request.

If a required field is empty the system displays the following error message on the page.

This example illustrates how the system displays messages to indicate what is required for a field.

The system displays an itemized list at the top of the form when clicking Submit so that in the case of multiple pages, the user can navigate quickly to the item and provide an acceptable value. The error message lists the error and the location to which the end user must navigate to correct the error. The list if errors can be expanded and collapsed as needed.

This example illustrates an error message appearing at the top of the form, displaying in the list the error, and the location of the offending field.

Runtime Application Form Save Behavior

You can save an intake form as a draft prior to submitting it. You may need to save an intake form as a draft for a variety of reasons, such as needing to gather additional information or the form requiring more time than anticipated. After saving the form, the user can return to it to provide more information and ultimately submit the form.

Note: Saving a form is not currently an option for the Code Enforcement offering.

When saving a form as a draft, not all of the data validation occurs. However, the user will need to resolve any critical errors that the application can’t save, such as adding a value with an incompatible data type. For example, the system can’t save an alphabetic character entered into a field of a number data type.

The complete data validation process and logic runs for user-defined fields and field groups when the form is submitted.

When users take advantage of saving forms, consider these items:

Consideration	Description
Save	Validates user-defined fields. Ignores empty required fields. Validates field groups fields.
Submit	Validates user-defined fields. Flags empty required fields. Validates field groups fields.
Groovy	To compensate for the ability to bypass Groovy validation during a save, incorporate the "pending" status in your logic. An intake form is in "pending" status when it has been saved but not submitted. For example, add the following to the top of applicable Groovy scripts: if (Status == "Pending") { return true }
Upgrade	Intake forms from previous releases with fields set as required need to be updated to include the validation adjustments associated with the ability to ignore required fields during a save. Open the intake form. Locate all the fields set as required, and turn off the Required switch. Save and publish the form. Locate all the fields that need to be set as required, and turn on the Required switch. Save and publish the form.

Runtime Train Stop Drop-Down Behavior

The train stop drop-down list, appears in the center of the application form header to provide:

Feature	Description
Context	The system automatically prepends the appropriate step number to the application form page name. The step numbers are assigned in the order the pages appear in the designer (from left-to-right). For example, assume you have three pages in your form: Application Details, Fence Details, Property Details. The train-stop drop-down list displays the pages as: Step 1: Applicant Details Step 2: Fence Details Step 3: Property Details
Current Page	To show the current page the user is viewing, the system displays a single, right-pointing, chevron character (>) to the left of page label in the drop-down list.
Navigation	Select any page in the application form, including the review page, to access it immediately.
Switch to Single/Multi-page view	Toggle between the multi-page view or the single-page view.

Using the Single-Page View

When accessing the single-page view in review or advanced-edit mode, end users will notice these characteristics of the page elements.

Page Element	Behavior
Edit button	Enables the end user to activate the form fields for editing. Initially, the system displays them in read-only mode. Once clicked, the system toggles the Edit button to the Done button.
Done button	Once the end user completes any changes, clicking Done: Performs any configured data validation. Saves changes to the database. Returns the form fields to read-only. Toggles the button back to read Edit.
Group boxes	If a group box contains multiple group boxes, only the outer (parent) group box displays an Edit/Done button.
Field groups	If there are multiple field groups in a group box, they will appear to be a single page section, with one Edit/Done button controlling all the field groups within the parent group box. Otherwise, if the field groups are on the page tab separately (not within the same parent group box container), then the system displays an Edit/Done button for each field group.
Expand All/Collapse All	Expands or collapses all the elements on the page, including group boxes and field groups within parent group boxes.

Note: The Edit button and the Done button do not appear on a page rendered in advanced edit mode if the form is displayed in a read-only context. For example, if the user viewing the form does not have sufficient privileges or if the user has already submitted the form, the fields in the form will be disabled and the Edit button and Done button will not be rendered on the page.

Advanced-Edit Mode

If needed, agency staff members can update a form after a public user has submitted the form. Agency staff members access the submitted form using the Permit Details page in the Permit List or by deep linking. Editing a form after a public user has submitted it is referred to as advanced-edit mode.

When in advanced-edit mode, the system:

• Displays only the field groups enabled for advanced-edit mode.

• Presents the form in the single-page view.

Agency staff members click the Edit button to activate fields and update data, and they click Done to save changes.

Note: Customers cannot configure whether a delivered field group appears in advanced-edit mode. Field groups enabled for advanced-edit mode are controlled and delivered by Oracle development. Only the field groups that are appropriate for agency staff members to update are enabled for advanced-edit mode.