Learning about user interface design guidelines for offline

When you develop a user interface for an offline-enabled application, it is recommended that you work in App Studio, use an Ajax container in a screen layout and use data pages or a local list to source data. You can also use back-to-back assignments in a standard flow for offline mode.

  • You build upon the functionality that is available in Pega Infinity Mobile Client that supports multiple views and a native bottom bar.
Before you build the user interface for an offline-enabled application, review the best practices for UI-Kit 7, the Case Worker portal, tables, sections, dynamic layouts, actions, and controls.

UI-Kit-7 and Case Worker portal

You use a portal in the UI-Kit-7 (14-01-01) ruleset to build offline-enabled applications by default. You can create your own portal for offline capability, as long as it uses some of the key principles and design of the pyCaseWorker portal.

To build an offline-enabled application, you must:

  • Use the latest version of UI-Kit-7 in your application stack.
  • Use the pyCaseWorker portal as a starting point.
  • Make the application skin inherit from the pyEndUser skin.

A portal that is based on the Case Worker portal (such as pyCaseWorker) has the following requirements:

  • It must be set as the default portal for every access group whose users access the offline-enabled application.
  • It must use an iFrame-less dynamic container: a Single Page application (SPA) mode of dynamic container. The AJAX container is not supported.
  • The harness in the portal must be defined in the Data-Portal class.
  • The cases must use stages and use pyStartCase as the starting flow on a case.
Note: For more information, see Composite portal and Creating a composite portal.

Repeating dynamic layout for lists

You must use a repeating dynamic layout for lists instead of tables when using the offline capability in your application. Actions are supported on the repeating dynamic layout for a worklist in which the opening of an assignment is supported, as well as open by handle, and actions are also supported when adding or removing a row. When using the Add or Remove action on a repeating dynamic layout, you do not need to use a Run script action. You can configure master-detail interaction and views for both online-only and offline-enabled cases.

Keep in mind the following information:

  • The Delete action button must be configured within the repeating dynamic layout row.
  • A developer should take care of creating and deleting the row context page.
  • The local action used to populate the row page should be configured with the Use data page option.
  • The Add and Remove APIs are active even if there are errors on the row page.
  • The source of the repeating dynamic layout should be a Page List.

Tables, sections and dynamic layouts

Tables with too many columns might not display correctly on a mobile device. Therefore, follow these guidelines:

  • Use layout groups instead of tabs and accordions. You can activate when rules for layout groups.
  • Use screen layouts instead of containers.
  • Use repeating dynamic layouts instead of tables for repeating structures.
  • Autopopulated properties are also supported.

Sections that are displayed on a mobile device might need to be refreshed and reoriented. Therefore, follow these guidelines:

  • Use skin rules to specify the presentation of your content by defining mixins and style formats.
  • Use sections instead of solid structural elements to promote reusability.
  • Use dynamic layouts, column layouts, and flexbox helper classes to position user interface elements within layouts.
    Note: Repeating dynamic layouts support the following features:
    • An ability to add and remove rows
    • Master-detail interaction and view for both online and offline-enabled cases
  • Configure your dynamic container to render as a single page in the central panel of the portal screen layout.
  • Instead of refreshing entire sections, configure refresh when rules on the user interface elements that need to be refreshed, such as dynamic layouts.
  • When using the defer load option:
    • The defer load sections or layouts are loaded on the initial load, and the defer load preactivity is always ignored. This behavior affects the performance of loading screens.
    • Defer load is not supported in tabs. You must use a layout group instead.

For guidelines about working with dynamic layouts in an offline-enabled application, see Creating the user experience and the Using dynamic layouts to create responsive user interfaces Pega Community article.

Actions and controls

When adding buttons, links, icons, and menu items, use only the supported set of actions. Not all controls in Pega Platform are supported in offline mode.