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.
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.
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.
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 |
|
Submit |
|
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:
|
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.
|
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:
|
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:
|
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. |
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.
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.