Partial Page Rendering (PPR) is a technology provided by the UIX (Cabo) team that allows a portion of a page to be redrawn rather than reloading the entire page. Before PPR, redraw of individual page elements was only available through custom Javascript code, which is generally discouraged in BLAF applications because of cross-browser incompatibility and reliability.
PPR offers significant benefits to users. When implemented correctly, PPR both improves application performance and provides more direct feedback when users perform actions. This guideline includes the following sections:
Note: PPR is automatically disabled when pages are loaded by browsers that do not support PPR. At this time, PPR is only supported by IE 5.5 and higher, Mozilla and Netscape 7.
Technical Note: At this time time, Cabo does not yet provide PPR support for all components listed in this guideline.
PPR is intended only for partial rendering of pages that do not require extensive back-end processing. Do not use PPR when most of a page's content needs to be redrawn, or time-consuming queries are needed to generate/refresh the content.
Unlike full page reloads, PPR does not force focus to the top of the page, and thus provides a minimum of distraction from the task at hand.
With PPR, the "Go" button can be omitted from choice lists and radio groups in many contexts. See Use of the "Go" Button below for a list of exceptions.
PPR is never used when navigating to a page with a different title. The Go button is also required in this case.
The Browser History feature does not track PPR. See PPR and Browser History below for more details.
PPR is disabled if a page is loaded by a browser which does not support PPR.
When the user performs an action that initiates a PPR update, there will be an event block period for a preset time while the update is being performed:
During this period, the wait cursor is displayed, and the user will not be able to perform any other actions on the page until the event block is lifted.
There will be a time out for the event block if the PPR update is not completed by the number of seconds specified: In this case, the event block will be cleared, the page will remain unchanged, and the user will be able to perform other actions on the page.
UIX may be able to provide the time out period as a parameter of "n" seconds/minutes, so that teams can set up the appropriate estimated time for different PPR fields.
The event block period is necessary because a PPR event can change the state of the page, so that a
subsequent click or key entry might target a control that is about to have its state changed (maybe the onClick handler will change, maybe the control will go away altogether).
If an unexpected error occurs during a PPR event, a Javascript HTTP error message should be displayed. Examples of unexpected errors include, server failure to respond, or timeout for event blocking. BLAF messaging cannot be used in these conditions, as the user may lose data if the application attempts to do so. Using Javascript is the "safest" approach.
Re-Render Data: The same fields are redrawn but their data is updated. Examples include the Refresh Data action button, or recalculate totals in a table.
Re-render Dependent Fields: Fields may be added, removed, or change sequence, and data may be updated. Examples include the Country choice list, which may display different address fields, and toggling between Simple and Advanced Search.
Hide/Show Content: Both fields and data toggle in and out of view.
The following table shows specific contexts and examples for each of these general usages, as well as the effect of disabling PPR:
PPR Usage
Context
PPR Initiated By
Related Guidelines
PPR Notes
If PPR Is Disabled
Re-render data (same fields are redrawn but data is updated)
Refresh field(s) with latest data
Functional icon; Action button
The Refresh Data button updates field or table content.
The Refresh Date functional icon updates the date in a field
The key flex field icon is still required, but validation occurs on exit of field. In a banking application, if a user enters the text "checking", the flexfield can automatically update with the user's checking account number.
The key flex field icon is displayed, and the full page is reloaded
The Country choice list displays different address fields depending on country selection.
In an HR application, selecting the job title of "Director" could display fields for budget allocation or a list of job responsibilities.
In a catalog, selecting standard or enhanced models of a product would display different options and prices.
The "Go" button is displayed next to choice lists and radio groups, and the full page is reloaded
*** Note: Depending on context, selection in the controlling field may display the same or different fields. For example, the Country field selection usually changes the sequence and labels of address fields, but Name fields may remain unchanged.
The following images illustrate PPR in several contexts:
Some page elements are always associated with a page, regardless of the content displayed on the page.
As a general rule of thumb, elements above the page title (except message boxes) remain constant and do not change position, whereas elements below the Ski remain constant but may move up or down the page to accommodate changes to page content. The following elements never change when PPR is initiated:
In most cases the following elements will also not change, other than moving up or down the page to accommodate changed elements. Nevertheless, in certain cases actions on the page may require them to be redrawn:
Side Navigation, unless it contains a Hide/Show control.
When PPR is implemented correctly, it significantly improves application performance. When performance improvement is not possible with PPR, it should not be implemented, thus avoiding unnecessary code bloat.
PPR should not be invoked in the following contexts:
When navigating to another page (with a different title).
When response times may be long, such as:
Database queries or database maintenance operations
Processes that demand significant middle-tier processing
When multiple sections of the page need to be redrawn, such as:
Action or choices that affect more than half the content of the page.
Inline messaging, which features a message box at the top of the page, and may insert inline messages below multiple fields.
PPR is disabled in browsers which do not support PPR. When disabled, both display and behavior of UI elements may change:
Action buttons, such as the "Go" button, are always displayed together with choice lists and radio groups.
Actions usually initiate a reload of the entire page. The only exception
to this rule is when applications use Javascript to check that required
fields have been filled out, and to validate the format of data entered
into fields. Note that this option is not recommended. For more information
on field validation, see the Messaging
Templates guideline.
Before PPR, choice lists and radio buttons with dependent fields required a "Go" button for users to activate their selection. With PPR, actions can be initiated on field exit, so the "Go" button can often be omitted.
However, in the following contexts, the "Go" button MUST always be retained, even though these contexts may only require redraw of the current page:
Search: All types of search, including Views, (except when a Search button is used instead) because search depends on back-end processing, which may be extensive, and require the user to wait. If users explicitly click a button to initiate the search, they will be less likely to be surprised by the wait time. For details on different types of search, see the Search Templates guideline.
Actions List: This list typically includes a mix of choices, some of which may navigate to another page, and some which may only redraw the current page. The Go button is required to confirm any choice to navigate to another page, and there is no way to know beforehand which action the user will choose, so the Go button is displayed regardless of the choice made in the list.
Table Filters: The table filter mechanism depends on back-end processing (like Search). Requiring users to click a 'Go' button will reduce confusion caused by the resulting wait time.
The Browser History feature tracks the pages and page anchors loaded into the browser, but does not track PPR. When users click the browser Back or Next buttons, they leave the initial page or anchor and go to the previous or next pages/anchors in the History stack. If they return to the initial page, it will be reloaded in its initial state, and any PPR-related display changes are lost. The following example illustrates the issue:
A user navigates from an Overview page to an object list page containing a table, and then navigates through forty sets of records. Each of those record sets is displayed via PPR. If the user then clicks the browser Back button, the initial Overview page is reloaded. If the user then clicks the browser Forward button, the object list page is reloaded with the first record set, and the browser Forward button is disabled. The user must then navigate through the records again to return to the fortieth record set.
Note: In this example, the loss of record navigation
History can be offset by use of a record locator with a choice list, which
speeds up navigation through large record sets. See the Record
and Page Navigation guideline for details.
This partial loss of browser History is not optimal, but it is offset by PPR's benefits. PPR not only improves application performance, but it also improves user experience of the application -- unlike full page reloads, PPR does not does not "flash" and force the user to the top of the page, and thus provides a minimum of distraction from the task at hand.
Before PPR, redraw of individual page elements was only available through custom Javascript code. Use of custom Javascript to redraw portions of the page should be avoided for the following reasons:
Reliability of Cross-browser Code: Both PPR and Javascript code must be customized for different types and releases of browsers. However, PPR code is developed and tested centrally, providing greater reliability. Custom Javascript code can crash browsers.
Coding Model: Because custom Javascript is not centrally supported, variances in scripting between development teams cause inconsistency in user experience, as well as requiring duplication of development effort.
Performance: The Javascript approach typically requires larger file sizes to accommodate UI variables, resulting in slower page load.
Error Handling: User error on a Javascript-enabled page can easily result in display of multiple alert windows with little indication of the fields generating the errors. This can be extremely frustrating to users, and can lead to failure to perform a task. Standard BLAF error messages can be displayed inline with pointers to related fields, or on more informative message pages.
Open/Closed Issues
Open Issues
None
Closed Issues
25-Nov-2003: Removed Table Filter and Switching Modes from list of contexts for use of PPR.
18-Sep-2003: There is no longer any restriction on using PPR with accessibility mode. Testing has shown that PPR provides a benefit to accessibility users rather than creating problems.
21-May-2002: Dynamic enable/disable of action/nav buttons is only allowed when switching contexts or modes as described in this document.
Bookmark
