User experience optimization techniques and methodologies

Dividing complex cases into smaller, more manageable child cases, namely the Divide and Conquer pattern, 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 Field Service applications, for example The parent case represents the overall problem that needs to be addressed. Child cases are then spun off to record work performed by technicians.

Loading a single, complex form into the user's session can impact performance. Design the user interface to allow the user to focus on completing a specific task. Techniques 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 the form is divided into layout groups, design each layout group to use the deferred load feature. This approach allows data in the layout group to be loaded 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 user interface significantly. The screen is rendered almost immediately through asynchronous or background processing, allowing the user to get on with the task at hand. At the same time, additional information is retrieved and displayed as it becomes available. Use the defer load option on dynamic layouts to display secondary content.

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

Pega Platform provides multiple mechanisms to run processing in parallel or asynchronously when integrating with external systems. For instance, you may 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 of the processing is not needed immediately.

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

You can use the Run in Parallel option on the Connect method to accomplish this. 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 feature is useful when subsequent tasks can be performed 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.  

Imagine the following scenario. You have a SOAP connector called 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 be executed in queue mode. Select queueing in the Processing Options section on the connector record’s Service tab to configure queuing.

Each request is queued and then processed later in the background by an agent or queue processor when queueing is used. The next time the agent or queue processor associated with the queue runs, it attempts to execute the request. The queueing characteristics are defined in the connector's Request Processor.

Background processing can also be leveraged to allow an initial screen to load. Doing so enables the user to continue working while additional detailed information is retrieved. This strategy is beneficial when using the SOR design pattern.

Pagination can be leveraged to allow long-running reports to retrieve just enough information to load the first page of the report. As the user scrolls down to view the report, additional records are retrieved and displayed 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 validation instead of server-side expressions, calculations, and validation whenever possible. Whenever expressions, calculations, and validations can run on the client, they execute in the browser. This is typically true for expressions used for visibility conditions, disabled conditions, and required conditions and for the declare expressions that are referencing editable properties on the form.

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

Only embed sections if they are truly intended for reuse. Pega Platform copies the configuration of included sections into the sections they are included. It is more efficient to reference a section by simply dragging and dropping the section into a cell.

Use refresh section instead of refresh harness to refresh only what is required on a form. To reduce markup, use the Optimized code-based settings in the dynamic layouts Presentation tab.

PEGA0001 alerts typically mask other underlying performance issues that can negatively impact the user experience. Leverage one of the Pega-provided performance tools such as AES or PDC to identify the underlying performance issue. Once you have identified 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

Leverage 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 legacy tabs, which have been deprecated. 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 applications, as well as mashup functionality that you can use to embed Pega frames in your non-Pega application. Also, Pega provides 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.

These REST APIs are known as digital experience APIs because they leverage 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 on using the Digital Experience API to design custom screens, see creating custom screens with the digital experience APIs.

Avoid these design practices:

• Misuse of list controls
• Uncoordinated parallel development

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. 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, use a different UI component or data lookup mechanism. Always source list controls from data pages. Consider loading data pages used to source list controls asynchronously.

Uncoordinated parallel development efforts can also adversely impact performance for the user. For example, multiple development teams could invoke the same web service returning the same result set multiple times and within seconds of each other. Multiple service calls returning 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.