User experience optimization techniques and methodologies

Dividing complex cases into smaller, more manageable child cases by using the Divide and Conquer pattern, read about design patterns.  Divide and Conquer allows you to process each child case independently. This technique avoids loading a single large case into the user's session. This technique is used in many Pega applications, for example, the parent case represents the overall problem that requires attention. Child cases are then spun off to record the work that technicians perform.

Loading a single, complex form into the session of the user can impact application performance. Design the UI so that users can focus on completing a specific task. Techniques to divide intricate UI include:

• Breaking complex forms into logical modules that allow users to focus on an immediate goal.
• Using layout groups to break long forms into logical groups.

Once you divide the form into layout groups, design each layout group to use the deferred load feature. This approach allows data in the layout group to load only when the form loads. The data for the other layout groups dynamically loads when users select each layout group on the browser.

Deferred data loading can improve the perceived performance of a UI significantly. The system renders the screen almost immediately through asynchronous or background processing and allows users to proceed with the task at hand. At the same time, the system retrieves and displays additional information as it becomes available. Use the defer load option on dynamic layouts to display secondary content.

You can use data pages as the source for list-based controls. Data pages act as cached data sources that can be scoped, and invalidated based on configured criteria and the garbage collected. 

Pega Platform provides multiple mechanisms to run processing in parallel or asynchronously when integrating with external systems. For example, you can initiate a call to a back-end system and continue your processing without blocking and waiting for the response of the external system. This method is useful when the external system processing time can be long and when the result is not immediately necessary.

Consider the following scenario. In a claims application, you retrieve the data and policies for customers who call to file a claim. The system accesses this data by using two connectors: GetCustomerData and GetPolicyList. To speed up the loading of customer data, you run the connectors in parallel.

The Run in Parallel connector on the any Connect- method controls this timing. In this case, each connector runs as a separate child requestor. The calling activity, the parent requestor, retains control of the session and does not have to wait for each connector, in succession, to receive its response. The Run in Parallel connector is useful when users can perform subsequent tasks while waiting for multiple connectors to retrieve their responses. When the service call runs in another requestor, users do not wait for the service call to finish and can continue with other tasks.  

Consider the following scenario. You have a SOAP connector, UpdateCustomerData, that updates a customer record in an external system. The response returned by the service is irrelevant for subsequent processing. Because other applications might temporarily lock the customer, you retry the execution if it fails.

In addition to being executed synchronously and in parallel, the SOAP, REST, SAP, and HTTP connectors can also run in queue mode. You select queueing in the Processing Options section on the Service tab of the connector record to configure queuing.

The system queues each request. An agent or queue processor later processes the requests in the background. The next time the agent or queue processor that is associated with the queue runs, it attempts to run the request. The queueing characteristics are defined in the Request Processor of the connector. 

You can also use background processing to load an initial screen. Doing so enables users to continue working while additional detailed information is retrieved by the system. This strategy is beneficial when using the SOR design pattern.

Use pagination to allow long-running reports to retrieve just enough information to load the first page of the report. As users view the report, the system retrieves and displays additional records as they are needed. Use appropriate pagination settings on grids and repeating dynamic layouts to reduce the markup used in the UI.

Use repeating dynamic layouts for nontabular lists. Avoid multiple nested repeating dynamic layouts.

Ensure that multiple actions that are processed on the server are bundled together so that there is only a single round trip.

Use client-side expressions, calculations, and validations instead of server-side expressions, calculations, and validation whenever possible. Whenever expressions, calculations, and validations can run on the client, they run in the browser. Client-side expressions is typically true for expressions used for visibility conditions, disabled conditions, required conditions, and the declare expressions that reference the editable properties on the form.

Use non-iFrame (iFrame-free) single-page dynamic containers because they are much lighter on the browser and enable better design and web-like interaction.

Configure the system to refresh sections instead of harnesses to refresh only the necessary information on a form. To reduce markup, use the optimized code-based settings on the Presentation tab for the dynamic layouts.

PEGA0001 alerts typically mask other underlying performance issues that can negatively impact the user experience. Use one of the performance tools that Pega Platform includes, such as Autonomic Event Services or Pega Predictive Diagnostic Cloud (PDC), to identify the underlying performance issue. Once you identify the cause of the performance problem, redesign and implement a solution to address the problem.

Examples of alerts that are behind the PEGA0001 alert messages include:

• PEGA0005: Query time exceeds the limit
• PEGA0020: Total connect interaction time exceeds the limit
• PEGA0026: Time to connect to database exceeds the limit

Apply all the newest technologies in Pega Platform for better client-side performance and smaller markup. The newest user interface technology is all HTML 5 and CSS 3.0.

Take advantage of icon fonts and new menus. Use the least number of layouts and controls possible, and always use the latest components and configurations.

Use screen layouts, layout groups, dynamic layouts, dynamic containers, and repeating dynamic layouts. Avoid legacy accordion, column repeat, tabbed repeat, and freeform tables as they run in quirks mode. Use layout groups rather than deprecated legacy tabs. Also, avoid inline styles (not recommended, although still available), smart layouts, and panel sets.

Pega Platform provides a robust and configurable user interface for your Pega Platform applications, as well as mashup functionality that you can use to embed Pega frames in your non-Pega application. Also, Pega Platform includes REST APIs that you can use to populate your non-Pega user interface with the results of Pega rules. When you use the Pega REST APIs, your application users access Pega business functionality in a familiar interface.

This REST API is the Pega Digital Experience (DX) API; it uses Pega user interface rules (harnesses and sections) together with Pega business rules to return JSON-equivalent structures that you can render with your native interface.

For more information about using the constellation digital experience API to design custom screens, see Creating custom screens with the digital experience APIs.

Avoid the following design practices:

• Misuse of list controls.
• Uncoordinated parallel development.

Misuse of controls

Misuse of list controls is a common problem and is easily avoidable during the design of a solution. Configure autocomplete controls to fetch data from data pages that never return more than 100 rows of data. Limit drop-down list boxes to no more than 50 rows of data.

Autocomplete controls negatively impact the user experience if:

• The potential result set is larger than 100 rows.
• If all the results in the list start with the same three characters.

Reduce the result set size for all list controls as much as possible. Use a different UI component or data lookup mechanism if the result set size is longer than 100 rows for an autocomplete, 50 rows for a drop-down list, or seven rows for radio buttons. Always source list controls from data pages. Consider loading data pages used to source list controls asynchronously.

Uncoordinated parallel development

Uncoordinated parallel development efforts can also adversely impact performance for users. For example, multiple development teams might invoke the same web service that returns the same result set multiple times and within seconds of each other. Multiple service calls that return the same result set waste CPU cycles and memory. To avoid this situation, devise a strategy for the development teams to coordinate web service calls by using shared data pages.

Check your knowledge with the following interaction: