After creating the WebApp, create required construct pages and assign page properties for the WebApp. Once the pages are created for a WebApp, they must be linked to the Navigation Menu to access them within the same or different WebApp. You can design a page based on how you want to display information to a user and what actions can be taken on a page.
Refer to Create a Construct Page for more information.
Page Design Guidelines
Follow these guidelines to design a fully implemented page with all available and relevant features to ensure a high-quality user experience for both Business Users and Business Administrators (or WebApp Designers).
When naming pages:
Use parentheses "rather" than hyphens to delineate the description of the page, For example, Request (Role) rather than Request - Role.
Pluralizing page names is acceptable.
A custom page built in Construct Preview operates solely based on Datastores and Datasets, which can contain views and tables. Scanning a datastore can automatically determine the primary key(s) and other profiling data. If a view or table does not have a primary key, you can enable the Is Key property to set a key field. You can then create pages that are bound based on primary key and key fields.
If applicable, determine an Update and Insert method relevant to the page's underlying dataset. For simple record sets, solely Updates/Inserts on the Grid display may be sufficient. If the record requires several or lengthy fields to be filled out, a Property Card or Form View is a good page supplement. If the fields to be filled out are dependent on a choice made on the Grid View, a dynamic substituted Form View is a good option.
Add in all Page Column Properties to ensure the page flow is user friendly. Form Views should make use of tabs and labels to avoid the use of vertical scrolling. Horizontal Views should utilize the resizable and width_flex_grow properties as required to ensure the record length doesn't exceed a reasonable resolution. Prioritize important text-based contextual information on the left, and actions on the right.
Review existing WebApp Groups. Determine which groups apply to the page and apply them. Ensure that the relevant groups have a valid navigation path to the page.
Assign control status value required to ensure that only the relevant fields are editable in the right contexts.
Identify which columns may benefit from a watermark, such as list boxes that search for particularly named values/objects. Use the Placeholder Text property in a field to display watermark. Watermarks can display the expected formats to ensure that the user understands what's expected. Also, suggested text formats can be useful. If the user is expected to use a namespace convention, indicating it during the add/edit is more useful than providing a warning after the save.
Identify which columns may contain data that should be translated. Because of potential for translation overhead as well as the Pareto principle, cell (and other) translations are opt-in. For example, if a list box within the application has the options "Active" and "Inactive," any application string literals or user input that may be used as configuration should be translated. However, do NOT translate everything by default. This results in a slower page load and a more encumbered cache. Refer to Field Translations and Dictionaries for more information to set up Dictionaries in the Admin module.
Consider which supplemental page features are relevant for the page.
Support Direct Update - Direct update allows a user to enable or disable a check box or toggle switch without having to edit the page. Enable this setting if there is a check box or toggle switch on the page, and updating the check boxes or toggle switches is commonly the only change that a user makes on the page. Disable this setting if it is expected that the user will update additional information on the page.
Are there fields that should not be filterable? You can control which fields are available for filtering by using the Filterable property, or by configuring Filters for a List Box field when setting up fields.
Does the page contain referential data to another application that can be implicitly secured? For example, if the application is meant to supplement functionality based on a Wave or Release, create a WebApp Group for that particular Release shipped with the required pages. When a user is granted access to that particular Release, the user can view and edit data in the WebApp that relates to that Release.
Note
Functionally complete does not mean Code complete. It's possible the page behaves correctly until it is scaled. The Designer may implement the page in a more efficient way.