Designing Pages for Optimal Performance and Accessibility

Developing pages for internet applications requires certain design techniques to optimize performance and offer the greatest accessibility for users. This section discusses how to:

• Improve online performance.

• Design accessible pages.

Improving Online Performance

To improve online performance of internet applications, you must optimize the transmissions to the server. Optimizing transmissions improves overall processing speed and reduces the user’s data entry time.

Transactions that are designed using deferred mode reduce traffic to the application server but do not operate interactively.

This section provides an overview of processing modes and discusses how to:

• Refresh a page.

• Trigger server processing.

• Use PeopleCode in deferred mode.

• Use page controls in deferred mode.

• Use error and warning messages.

Understanding Processing Modes

PeopleSoft applications can run in two different processing modes: interactive and deferred.

Interactive Mode

In interactive mode (formerly called standard), when the user exits a field that has a field-level event (for example, FieldChange, FieldEdit, RowInsert PeopleCode, prompt validation, related display, and so on):

1. A transmission to the application server is performed to run that field-level event.

2. The page is displayed again.

Deferred Mode

Deferred mode enables you to defer many of the conditions that need server processing until running them on the application server is required or requested. For example, when a user exits a field that has a field-level event (like FieldChange or FieldEdit PeopleCode, prompt validation, related display, and so on), that event is not run until the next transmission to the application server. When the next transmission to the server occurs, PeopleTools determines which fields have changed since the last transmission. Logic on the application server runs the appropriate system edits and PeopleCode events (in field layout order).

You can select deferred mode processing at the field, page, and component levels. For a field in the component to run in deferred mode, you must select deferred mode at each of those levels. Deferred processing is the default mode at the field, page, and component levels.

Refreshing a Page

Click the Refresh button on a page to force processing on the application server to determine which fields have changed since the last transmission and to run processing logic that is associated with those changes.

Users can also refresh by pressing the alt-0 hot key, which keeps the cursor in the same field when the page is displayed again. You can refresh at any time during data entry to enable an expert user to:

• Update related display field values for the data that is already entered.

• Recalculate totals and balances.

• Provide defaults that are based on prior data that was entered on the page.

• Validate the data that has been entered on the page so far.

• Invoke any hide, unhide, gray, or ungray code that is associated with specific fields.

Note. The refresh button does not refresh the page from the database. It does cause a server trip so that any deferred PeopleCode changes can be processed. If there are no deferred changes or the deferred changes do not cause any errors or other changes on the page, clicking Refresh has no effect. It may appear to the user that nothing happened. Fields on derived work records are not updated if the user clicks the Refresh button.

Triggering Server Processing

The following table shows the events that cause the PeopleTools runtime environment to run logic on the application server when operating in deferred or interactive processing mode:

Using PeopleCode in Deferred Mode

When designing transactions to run in deferred mode, note the following:

• Code field edits in FieldEdit PeopleCode; it is not necessary to move field edits to SaveEdit PeopleCode.

• Code field change logic in FieldChange PeopleCode.

• Set all fields, including those that have FieldEdit or FieldChange PeopleCode, to deferred processing.

• Do not use gray and hide fields on the same page to achieve a form of progressive disclosure on the page.

  Specifically, do not include hide or unhide and gray or ungray FieldEdit and FieldChange PeopleCode for definitions on the same page, unless it is triggered by a separate push button. Instead, use either page Activate PeopleCode or FieldChange PeopleCode for definitions that are on another page in the component. The page display should be static as the user enters values and moves between fields on the page.

  PeopleSoft recommends that you hide or unhide definitions, or set them to display-only in page Activate PeopleCode before the page is initially displayed based on setup data, configuration options, or personalization settings. Set fields to display-only in PeopleCode by setting the DisplayOnly property in the Field class to true.

• Show all fields as a static form, and perform cross-validation edits to prevent invalid data combinations from being written to the database.

• Cross-validation edits should always assume that the controlling field (for example, a radio button, check box, drop down list box, and so on) is correct when editing for invalid combinations.

  Use SaveEdit to code cross-validation edits. If the transaction requires that the edits be performed before the user can select another folder tab, code the edits in a function that is called from the page Activate PeopleCode for every other visible page in the component. If the transaction is a sequential step-by-step process, add the cross-validation edits to the Next and Previous buttons that navigate the user through the process. Code cross-validation edits at the record level if the cross-validation edits apply to all components and at the component level if they apply to only one component.

Publishing Messages in PeopleCode

Use the SavePostChange event, either from record-field or component PeopleCode, to publish messages online. PeopleTools has special logic in SavePostChange PeopleCode that defers publishing until just before the commit for the transaction. This minimizes the time that the system locks single-threaded PeopleSoft Integration Broker tables.

See Also

Deferred Processing Mode

Using Page Controls in Deferred Mode

Consider the following when designing transactions to run in deferred mode.

Edit Tables

Fields that have edit tables should be set to deferred. The user can click the Refresh button for immediate validation of the field; otherwise, the prompt validation is deferred until the next required transmission to the application server.

Prompt Tables

Use deferred processing on prompt table edits that use %EditTable to set the prompt keys based on the values of other fields on the page. Deferred processing still results in the appropriate behavior being run. For example, if the user clicks the prompt icon, the system:

1. Determines which fields have changed since the prior server transmission.

2. Runs the appropriate PeopleCode events.

3. Applies the values from the page to the buffer.

   This results in setting the correct values before resolving the %EditTable function, provided that any controlling fields come before the prompt table edit based on the page layout order.

4. Runs the prompt table edit lookup logic for the corresponding field.

Drop-Down List Boxes

Do not use drop-down list boxes when the high-order key values are set on the same page. If you do, it requires the server to transmit the correct drop-down list box values based on the high-order key values. Therefore, set the high-order keys on another page, if possible, or use a prompt lookup instead.

For pages that have an effective-dated scroll area and a drop-down list box based on the PSXLATITEM translate table, the drop-down list box is not refreshed when the effective date is changed on the page. However, the drop-down list box does accurately reflect the new effective date the next time that the page is displayed. Evaluate whether this is a problem for the transaction, based on whether customers typically enter effective-dated XLAT rows for the field and on how often changes to the XLAT values are made. If this is an issue, either replace the drop-down list box with an edit box and a prompt, or use the refresh icon after the effective date field.

Drop-down list boxes are a good design choice because they present users with a small number of selections from which they must select one. They are typically more appropriate than prompts for transactions that are targeted at casual, untrained users. Prompts are more appropriate when a power user is entering the transaction from a paper form or document that contains the necessary codes.

Check Boxes and Radio Buttons

Remove any FieldChange PeopleCode associated with check boxes in a grid that are mutually exclusive (meaning only one row can be checked). Instead, implement cross-validation edits in SavePreChange PeopleCode. When you design cross-validation edits between a radio button or check box and any associated edit box fields, assume that the controlling field (in this case, the radio button or check box) is correct.

Related Displays

When you include related displays on your pages, make sure that they are set to deferred mode and that the standard Refresh button is enabled. Then, users can press the Refresh hot key to display related displays when they want to see them. Self-service transactions should not display the code and corresponding related display, but rather should use descriptive prompts.

Adding Multiple Rows

This feature enables the user to specify the number of blank rows to be added by clicking the InsertRow icon.

The number of blank lines that are specified by the user is included on the page when it is displayed again, so application server processing is no longer required for each row that is added.

Do not use this for effective-dated grids or scroll areas.

Multirow inserts might not apply if the entire row is populated using PeopleCode, especially if the data is copied from prior rows. If a multirow insert does apply, the default value of the ChangeOnInit property can be used. (The default value is True, which means that any PeopleCode updates done in the RowInit or RowInsert events set the IsChanged and IsNew properties to True.)

Once a transaction is saved, empty rows are discarded before the page is displayed again to the user. An empty row means that the user did not access the data and that PeopleCode or record defaults might have been used to initialize the row for the initial display.

PeopleCode Save processing (that is, SaveEdit and SavePreChange PeopleCode) runs for all rows that are in the buffer (including the empty ones). Therefore, SaveEdit and SavePreChange PeopleCode should be coded so that it runs only if the field contains data or if the row properties IsNew and IsChanged are both true.

An alternative method is adding PeopleCode in the first save program in the component to explicitly delete any row based on the IsNew and IsChanged properties. If you choose this method, then rows should be deleted from the bottom of the data buffer to the top (last row first).

To implement multirow insert:

1. Ensure that deferred processing is set.

   Open PeopleSoft Application Designer and ensure that deferred mode is set for the component, all pages in the component, and all fields on each page.

2. Access the Page Properties dialog box of the appropriate control.

3. Enable multirow insert.

   For each grid or scroll area where appropriate, select the Allow Multi-row Insert check box under the Use tab in the grid or scroll area property sheet.

4. Add ChangeOnInit PeopleCode.

   Setting the ChangeOnInit property for a rowset to FALSE enables PeopleCode to modify data in the row set during RowInit and RowInsert events without flagging the rows as changed. This ensures that only changes entered by the user cause the affected row to be saved.

   Note. Each rowset that is referenced by a grid or scroll area with multirow insert enabled should have the ChangeOnInit property for the rowset to FALSE. This includes child, or lower level, rowsets. In addition, this property must be set before any RowInsert or RowInit PeopleCode for the affected row.

Using Error and Warning Messages

When components, pages, and fields are set to deferred mode, FieldEdit PeopleCode errors and warnings are not displayed when the user exits the field, but rather after the next application server transmission. Therefore, users might not receive an error message until they enter all of the data and click the Save button.

For FieldEdit error messages running in deferred mode, the system changes the field to red and positions the cursor to the field in error when it displays the message. This allows the user to associate the error message with a specific field. However, for warning messages, the system does not display fields, nor reposition the cursor. Consequently, create warning messages that clearly describe to which fields they apply. For example, if a page contained a "Date out of range" warning, it would be confusing to users if there were multiple date fields on the page.

Designing Accessible Pages

You want to design an application page that is useful to the user and supports assistive technologies.

This section provides an overview of accessibility issues and discusses how to:

• Use labels.

• Use color to convey meaning.

• Verify titles for grids and scroll areas.

• Add unique labels for buttons and links.

• Deactivate adornment images.

• Maintain logical tab order.

• Use deferred processing.

• Use foreground and background colors.

• Use instructional text.

Understanding Accessibility Issues

PeopleSoft is committed to designing transactions that are accessible to all users. When you create or modify PeopleSoft Internet Architecture pages for your system, consider the needs of all users who might access these pages. Make sure that users with disabilities can navigate quickly and cleanly through your transactions when using screen reader software. Before you design your page, use the following checklist to create a properly designed application page that also addresses important usability issues:

• Do all functional images have labels?

  Do these labels effectively communicate the purpose of the image?

• Do all data entry fields have labels near the entry field?

• Do all grid columns have labels (excluding columns with buttons or links)?

• Do all grids and scroll areas have titles?

• Do all buttons and links have unique labels?

• Do adornment images have labels deactivated?

• Is the tab order correct?

• Is deferred processing activated?

  If not, is field processing kept to a minimum?

• Do foreground and background colors provide sufficient contrast?

• Do your self-service pages have instructional text?

• Did you remove abbreviations used in labels and column headers?

• If your page contains HTML not generated by PeopleTools (such as code in an HTML area) or an applet, first check that the code follows the Section 508 accessibility standards. The applicable standards are in Subpart B, Technical Standards, Section 1194.22 Web-based Intranet and Internet Information and Applications.

  See http://www.access-board.gov/sec508/508standards.htm

Some of these features are set in design time and can be activated or deactivated by the system administrator and the end user. The system administrator controls the availability of functions to the user from PeopleTools Security. The end user can then activate the options on the My Personalizations page.

See Also

Working with the My Personalizations Interface

Using Accessibility Features

Using Labels

Consider the use of labels for functional images, data-entry fields, and grid columns in your application page.

Labels for Functional Images

All functional images need a good label. Functional images are image buttons, image links, and static and dynamic images that convey meaningful information. Images that do not require labels are spacer (or invisible) Graphics Interchange Format (GIF) files and adornments (images that do not serve a functional purpose other than to provide visual interest). A good label is vital for blind users to understand the meaning of an image. Labels also clarify the meaning of images for sighted users, because the labels appear as mouse-over text on some browsers.

Assign labels to images using alternate text, or the ALT HTML tag. You can set alternate text for static images, dynamic images, push buttons and link images, and control buttons in scroll areas and grids. Assign alternate text on the Label tab of the Properties dialog box for the control that you specify. You can use the Message Catalog, custom label text, or the RFT long or RFT short label, if one has already been designated in the record field. There are alternative text entries in the Message Catalog for the following page elements: folder tabs, scroll left and right buttons, hide and show grid tabs, prompt buttons, expand and collapse buttons for grids, group boxes, and scroll areas.

Note. Any alternate text that you select is visible to all users as mouse-over text on some browsers regardless of whether the system administrator makes the accessibility features available to users in PeopleTools Security.

To specify a label for an image push button or link associated with a record field:

1. Open the Page Field Properties dialog box for the control.

2. Select Image as the type.

3. Determine the RFT names:

   1. If the RFT name is descriptive, set the label type to that RFT name.

   2. If the RFT name is not adequate, edit the RFT name or write a message using the Message Catalog.

Note. Image buttons and links not associated with record fields should use messages exclusively.

The steps to specify a label for other types of images are the same as for image buttons and links, with the following differences:

• For dynamic images, you can choose to use RFT names or messages.

• For static images, you can only use messages or static text.

  PeopleSoft recommends using the Message Catalog.

Labels for Data-Entry Fields

All edit boxes, check boxes, radio buttons, and long edit boxes should have labels near the entry field. The label should be the actual label for the field or the label from a hidden field, and so on.

Do not use a second independent field as the label for an edit field. This causes the field that is serving as a label and the edit field to be disassociated by a screen reader, and it is confusing to blind users. It also results in a page that contains a field without a label and a label without a field.

Labels for Grid Columns

All grid columns need a label. The only grid columns that do not have labels include those that contain buttons or links.

Using Color to Convey Meaning

Do not use color as your only way to convey information. Include a redundant clue so that users who are blind or color-blind are aware that there is something special or different about a field or process. A common misuse of the color red is to change the background or text color to indicate an error. Another common mistake is to use an icon that changes color based on status but is otherwise the same. Color-blind users cannot distinguish between certain colors, nor can screen readers. In addition, if a user prints a page on a black and white printer, color-dependent items on the page become indistinguishable.

Use the approved set of icons in the table and see the following example on how to show status. All icons are GIFs or JPEGs.

Use a text field that describes the status. For example:

Status: Error

Use icons of different shape and color to represent each status. The icons should also have descriptive mouse-over text so that screen readers for blind users can interpret the meaning of the icons.

Verifying Titles for Grids and Scroll Areas

All grids and scroll areas need to have meaningful titles. Sometimes titles are not used due to redundancy because the label repeats the name of the page. However, while the grid may be visually close in proximity to a page title, it may not be close when read aloud by a screen reader. This may cause a loss of association between the page and the grid, and the contents of the grid may become ambiguous.

Adding Unique Labels for Push Buttons and Links

Buttons and links need unique names on a page. While you might visually associate a link with an area, the association might not be apparent to a screen reader. Also, screen readers have the ability to list all links on the page. If there are two links with the same label, no distinction can be made to the user.

Deactivating Adornment Images

Adornment images serve no functional purpose other than to provide visual interest. If the images have no information to convey to users and do not serve as navigation, then they should not have a label. Images used as spacers, such as invisible GIFs, should not have labels.

To deactivate the label for an image:

1. Access the Image Properties dialog box.

2. Select the Label tab.

3. Set Label Text Type to Static Text.

4. Delete any characters from the Text field, if it is present.

   It is not necessary to enter a space. Leave the Text field blank.

Maintaining Logical Tab Order

Maintaining a logical tab order on your page is critical because blind users cannot see the groupings or field proximity. Tab order is also important for sighted users because it can be confusing if the cursor moves to fields in an order different from how they appear on the screen.

Using Deferred Processing

Every time there is a trip to the server, your current page is refreshed. This "refresh" can make the screen reader lose focus of the field that the user was on, and it will start reading the page from the beginning. This includes navigation links and all other items on the page. It is difficult for users using a screen reader to find their place as well. Using deferred processing enables you to determine when the transmission to the server needs to be made.

Using Foreground and Background Colors

Text and background colors must have sufficient contrast to be viewed by someone with low vision or color-blindness. The PeopleSoft standard corporate style sheet is designed with this in mind. You might consider using the provided style sheets instead of custom ones.

Using Instructional Text

Instructional text provides a brief overview of the page and a summary of the page contents for blind users. By providing instructional text, you save users from having to hear the contents of an entire page read aloud by the screen reader. All self-service pages should contain at least a minimum of one or two lines of instructional text.

When writing instructions, labels, or any other text for transaction pages, follow these general guidelines:

• Know your audience and write to its level of expertise.

• Do not make assumptions based on your expertise.

• Avoid highly specialized technical slang that is unique to an occupational group.

• Understand the task that you are describing.

• Write clearly and concisely.

• Use the fewest words required for clarity.

• Use short sentences; avoid paragraphs.

• Choose precise, imperative verbs.

  For example, use "Complete all fields" instead of "Please fill out all the fields below."

• Do not construct sentences that merge variable information into a sentence, as these sentences are difficult to translate.

  Use "OK to delete John Smith?" instead of "OK to delete dependent John Smith?"

• Correctly reference graphical user interface (GUI) elements.

  • You click buttons, you do not click on a button.

  • You select options, check boxes, and items in list boxes.

    You do not choose them.

  • You press keyboard keys.

  • You clear options and check boxes (not uncheck, unmark, deselect, or other such variation).

    You can cancel a selection as well.

• You delete items (not remove them).

• Use written English, not verbal English.

  (The English that you speak is not necessarily the English that you write.)

• Avoid contractions:

  Poor	Better
  Won’t	Will not
  Didn’t	Did not
  Shouldn’t	Should not
  Can’t	Cannot

• Use short, simple, nonthreatening words:

  Poor	Better
  Abort	Cancel, Stop
  Execute	Complete, Done
  Implement	Do, Use, Put Into
  Invalid	Not Correct, Not Good, Not Valid
  Terminate	End, Exit

• Avoid hyphenation.

• Eliminate unnecessary words:

  Poor	Better
  in order to	to
  so that	so
  in regards to	regarding

Text for Labels

When writing labels, use the following guidelines:

• Write short, concise, yet descriptive labels.

• Do not capitalize all letters in the words included in your label; use sentence case.

• Use abbreviations only when there is limited space.

• Follow field labels with a colon (:).

• Do not use repetitive words.

  Use "Copy the overall definition for the following: Rules, Rates, Offerings" instead of "Copy the overall definition for the following: Rules definition, Rates definition, and Offerings definition."

Note. When using ampersands (&) in field labels (and hyperlinks) consider that PeopleSoft determines if a field has an access key based on whether or not the field label contains an ampersand (&). If the field label contains any ampersands, the last ampersand in the label along with the text following the last ampersand is used to create the text for the HTML and the system removes the last ampersand.

If the label contains a single ampersand (&), and the following character is not a blank space or another ampersand, the character following the ampersand will be used as an access key. Use a double ampersand (&&) so that a single '&' appears in the label as well as enabling the character immediately following the second ampersand as the access key.

For example, '&TEST' appears on the page as 'TEST' with the 'T' activated as an access key. '&&TEST appears on the page as '&TEST' with the 'T' activated as an access key.

Text for Titles

When writing text for titles, use the following guidelines:

• Write titles that are short and descriptive.

• Use verbs (for example, Create Expense Report).

• When writing titles that will appear in the grid or scroll area navigation bars, do not repeat the transaction title or the page title.

  Instead, use a similar but more descriptive phrase or a slightly longer description. For example, the title in the blue bar repeats the page title but adds more description:

General Guidelines for Instructional Text

When writing instructions, use the following guidelines:

• Do not use quotations around reference words.

• To reference a word, capitalize the first letter of the word.

  In the following example, see the instructional text with a reference to an object (Primary Phone check box):

• Use short sentences; avoid paragraphs.

  Use "The listed competencies are based on your job. Complete the information where applicable. To enter additional competencies, click Add. When completed, click Save" instead of "The following competencies listed have been populated based on your job. Please complete the information below (where applicable) for your perceived proficiency, your interest in developing this competency further, year acquired, year last used, and years of experience. If you need to add additional competencies, please click the Add button below."

• Use active voice.

  Use "Enter the part numbers" instead of "The part numbers should be entered."

Page Instructional Text

Page instructional text provides users with instructions on how to complete a task on the page. Use this text when pages have unique requirements or are particularly complex. When writing page instructional text, follow these guidelines:

• Place instructional text after level 0 identifying data.

• Set the style of the instructional text to PAPAGEINSTRUCTIONS.

• Derive instructional text from the Message Catalog.

  Use a unique message set for each product.

• Use Static Text to provide instructional text for a page.

• When you need to create a dynamic phrase, embed bind variables in a message catalog entry.

Additional Instructional Text

Additional instructional text is used within a page and it helps users understand a specific section or field on the page. Additional text can also be used as a footnote at the bottom of a section or page. Use this text when a page or sections of the page have unique requirements or are particularly complex.