User interface elements

Users interact with your business application through user interfaces. Before you begin building your applications, review these user interface elements.

Pages

Pages are the user interfaces (UIs) for your application. You can use pages to build different types of UIs for your user.

You develop your pages with a low-code designer where you can drag various components to your page, and configure them. When your application is deployed, your pages are rendered as HTML web pages at run time.

There are three ways that you can add pages to your application:

Basic and advanced users can click the page menu in the upper navigation pane, and the click New.
When you first start to create an application, your first page is created by default. The view palette is also immediately started, so you can start adding views to your first page. This initial page is known as your starting page. Each time that you create a page by using this method, the view palette is automatically started.
Basic and advanced users can add new pages when configuring certain views within their application.
You can also add new pages when customizing certain views. Imagine you add a button to your starting page. The button is a Next button that calls an action, then directs the user to a designated page. When you define the Next step values, you must select an entry for the Go to page property. You can set this property to New page, then specify a name for your new page. When you finish configuring the Next step page, your new page is generated. You can create new pages when you configure any view that uses Next steps configuration.
Advanced users can use the diagram for their application project to add a new page to their application.

There are two ways that you can delete a page:

Basic and advanced users can delete a page from your application by switching to the page that you want to delete, then clicking the delete icon in the upper navigation pane.
Tip: Take a snapshot of your application before you delete pages.
Advanced users can switch to the application diagram, right-click a page, and then select Delete.

If you delete a page that is used by another view for the Go to page property, you break the logic for that view. Any view that points to the page you deleted, must be updated to point to an existing page.

Page navigation menu

You can organize the pages of your application into a navigation menu that is visible to your users. When you add a page to your navigation menu, a menu item is created for that page, and added to the menu.

You can create three types of navigation menu items:

Pages: A menu item that navigates to one or more pages.
Folders: A menu item that can nest other menu items within it.
External links: A menu item that links the user to a destination outside your application.

You can also associate pages to existing navigation menu items, specifically pages. Let’s say your application has a page flow of four pages, but you don’t want every page in the flow to have its own navigation menu item. You can choose to associate the four pages of you flow to one navigation menu item. That way, no matter where your user is in the page flow, the associated menu item is highlighted.

For advanced scenarios, navigation menu items can fire boundary events. To configure boundary events, switch to your Advanced view mode, and use the Diagram.

Views

Views are reusable sets of user interface widgets, such as text fields, date time pickers, and buttons, that users can use to interact with a business object or service. Views can comprise one or more sets of other views, data bindings, layout instructions, and behaviors.

Because views are reusable, each view instance can share parts of its user interface with other view instances. For example, you create a page that contains a view instance that includes a set of address fields. If you create a second page that needs the same address fields, you can reuse the same view. In both cases, the page is using an instance of the view. You can edit the properties of each instance independently. For example, changing the label of one view instance does not change the label of the other. Both view instances use a reference to point to the view definition. This approach means that if the view definition changes, you can see that the change reflected in the instances of the view.

You can modify the view instances by using configuration properties and by overriding default styling. If you define a binding for an instance, it must match the type in the page definition. A warning occurs if the business object type does not match the type of the data binding that is defined for the view. For each view instance, the configuration properties are presented. If you want to override the default value, you can provide a specific value or you assign a variable. You can also expose the configuration property to any view that contains the view. Exposing the configuration property creates a configuration option in the current view with matching binding. You do not have to create the configuration option and bind it.

Views in toolkits or applications: You can create a view in the application or in a toolkit. In general, create highly reusable views in toolkits and more specialized views in applications. Choosing the application means that you can reuse it only within the application. However, it also means that if someone edits the view, the changes apply to the view instances in that application. If the view is in a toolkit and then someone edits it, the changes might apply to all view instances in all the applications that use that version of the toolkit. Because editing a view definition can affect many instances, be careful when you make changes. For example, deleting a content box in the view definition might mean that pages or views that contain instances of that view cannot display the content that is defined in that content box. You cannot directly edit the definition of the view from within the parent page or view. Instead, you must open the view definition first before you can change it.

UI toolkit: The UI toolkit, which is the default toolkit, provides a rich set of views that you can use to build applications that run on multiple devices. Use the UI views for new development. To become familiar with the UI views, explore the Discover UI sample.

Workplace toolkit: The Workplace toolkit consists of a set of views that you can use to design your own client-side human service-based business applications and dashboards that are customized for work management in Workplace. The Workplace toolkit views are available in the Application Designer palette for dashboard and application design.

Composite-style vs widget-style view development

Typically, when you build your view, you can follow one of the following patterns. Or you can use a combination of both patterns if your user interface is more complex and requires it.

Composite-style views are simple and do not require advanced technical skills to build. To create a composite-style view, add content to the layout from the palette. If your view has multiple areas of information, use the grid layout to arrange the views, then set their properties and complete the data binding as required. Composite-style views can be reused in multiple pages or in other views that can be built hierarchically.
Widget-style views are more complex and require a more technical skill set. Typically, the widget-style views are custom views that can include, for example, a custom HTML segment that you can populate with HTML code, or an iFrame that has a specific ID. You can set the configuration properties of the widget-style view and add inline CSS and inline JavaScript logic in the Behavior page. For behavior that occurs at run time, for example, when a page is loaded or a button is clicked, you can place the JavaScript logic inside the view's event handlers, under Events.

View templates

Templates provide a way to create a standardized look across multiple pages.

A template is a view that someone marks as being usable as a template in the Overview properties. Users can then select the template when they are creating their views. The new views have the content of the template as base content, to which users can then add content. For example, you create a view that has the company logo and name in a banner area, and a content box as a placeholder for other content. When you use this view as a template, you can then select it when you are creating another view or page. The new view has the banner area that is defined in the template along with an area for content. Other users can also use the template when they are creating views so that there is a consistent look across the new views. Because templates are views, you can also drop them onto pages. For example, if you have a template that has a common banner, you can drop it onto a page so that the page has the common banner.

Tip: If the template is using cells in a grid layout, the direction settings of the cells override the preview settings of any content boxes in those cells.

The template also serves as a way to update multiple views simultaneously. Because the template is a reference to a view and not a copy, if you change the template, all the views and pages that are based on that template are updated as well with those changes. To continue the previous example, you update the template to change the logo image. All the views that use your template are updated with the new logo.