Bookshelf v7.5.2: High Interactivity Versus Standard Interactivity

Siebel Tools Reference > Physical User Interface Layer >

High Interactivity Versus Standard Interactivity

Traditional Web applications follow a model whereby almost every user action results in a page refresh. Some of the user actions that can trigger a page refresh are a user changing the quantity of an item in the Siebel eSales Shopping Cart, a user inserting a new appointment in the calendar, and a user selecting a different item from a list to see its details. These frequent page refreshes not only slow down users by forcing them to wait for new pages, but also waste time as users reorient themselves with the frequently changing context caused by these page refreshes. In addition, frequent page refreshes are expensive in terms of network bandwidth utilization, as each page refresh requires the same HTML information, already displayed in the browser, to be downloaded with new data.

High interactivity solves the problem of lowered employee productivity and high bandwidth requirements by reducing the number of page refreshes.

High interactivity depends on capabilities that are only available in Internet Explorer 5.5 and higher versions, and is only used for employee applications such as Siebel Sales and Siebel Call Center. Customer applications such as Siebel eSales and Siebel eService do not use high interactivity.

Some differences between standard interactivity and high interactivity are as follows:

Support for client-side scripting. Client-side scripting is available for both types of applications. However, in high interactivity, customers have access to Siebel objects through which they can build data validation logic on the client side to reduce further the number of page refreshes needed.

Support for interactive controls. High interactivity employs specialized JavaScript controls for drop-downs, date and time, lists, and so on. These controls provide greater levels of interactivity than traditional HTML controls that appear in standard interactivity, are designed for JavaScript controls, and are different from the HTML controls based on list applets used in standard interactivity. For example, the list control supports resizing of columns, and drop-down lists support auto-completion.

Support for application-level menus. Application-level menus require support for Java applets. Because there is no support for Java applets in standard interactivity, there are no application-level menus.

Support for extensible toolbars. You can take advantage of the functionality of high interactivity by extending JavaScript toolbars and creating new ones. JavaScript toolbar objects reside in the JSSApplication hidden frame, which usually does not reload during the application life cycle. Therefore, they are not redrawn when there is a page refresh. The UI part of the JavaScript toolbar resides in a visible HTML frame (recommended to be a persistent frame that reloads infrequently) and redraws when the HTML frame reloads.

Support for Implicit save. High interactivity supports an implicit save model whereby navigating off a record causes the changes to be saved. The benefit of this model is the efficiency with which data can be entered; an explicit save operation for each record is not required to commit the changes.

Appearance of applet-level menus. In standard interactivity, the applet-level menus for Siebel applications are represented in the form of drop-down lists. These menus show up as dynamic drop-down controls in high interactivity.

Support for browser back and forward buttons. Standard interactivity supports browser forward and back buttons, which are used for navigating within an application. High interactivity uses Siebel bookmarks to support navigation that is accessible through provided controls for back and forward movement within a session and a history drop-down list.

For more information on high interactivity, its architecture, and enabling it, see Siebel Architecture (Basic Concepts).