Personalizing iViews (Preliminary)

Introduction | Types of Personalization | Guidelines for Personalization Dialogs

Introduction

This page describes a concept of how iViews can be adapted to users' needs in a portal environment.

Important: The following information is highly preliminary; it will be updated as soon as possible. Currently, an agreed-upon universal personalization concept does not exist.

Note: The images are proposals, not finalized designs.

Types of Personalization

Basically, there are two types of adapting an iView to role- and user-specific needs, customization and personalization.

Customization

Customization is performed by the system-administrator and used for pre-configuring or setting up iViews and their appearance on a portal page. Besides specifying the technical and the business background of iViews, customizing can also affect the user interface (e.g. presetting display attributes) and can be used to specify the extent of personalization the user is allowed to do.

Customizing an iView is performed using administrator tools delivered with the portal framework; such tools are not within the scope of these guidelines.

Personalization

Personalization is performed by the user. In its simplest form, users can decide for a predefined set of iViews (predefined according to their role), whether and where they want to display an iView on a portal page. Further end-user settings should be as easy as possible and will mostly relate to a limited set of display options (such as "display status bar") or per-application settings (such as "refresh-cycle"). In a limited way, they can also contain an adoption of the interface itself and the data to be displayed.

Typically, the selection of iViews to display in a portal page is performed using tools provided with the portal environment. The personalization if iViews themselves is handled in a dialog window, which is called by clicking the "Edit" icons in the tray header.

Below, we propose preliminary guidelines for the design of personalization dialogs.

Guidelines for Personalization Dialogs

The following rules refer to dialogs for personalizing iViews. The rationale behind the rules is that users need access to their personal settings through an interface that is consistent over all iViews.

Note: Determining the display status of of iViews and their position on a page is handled by the portal framework (either via administrator tools or via end-user tools); this activity is beyond the scope of these guidelines.

General Rules

Group Settings - Form General and iView-specific Groups
Provide settings that are common to virtually all iViews as generic building blocks, which can be blended with application-specific options. The generic blocks will always appear, whenever applicable for an iView. The specific settings will be tailored to each iView. Group them into a set of categories as described below.
Handle Personalization Outside the iView
As iViews are small and should always retain a stable appearance, do not handle the personalization inside the iView itself. The number of screen elements for the personalization can easily exceed the complexity of the iView itself. Therefore, call a dedicated modal dialog window for this purpose.

The Personalization Dialog

In the future, iViews may use a generic personalization dialog. It should be displayed as a modal dialog box in the center of the screen (see following picture) and appear, when the user clicks the "Edit" icon in the title bar of the iView tray header. The dialog window can be closed via an OK or a Cancel button, located at the bottom right of the window. OK applies all changes and closes the dialog, whereas Cancel undoes all changes and closes the dialog as well.

Figure 1: Portal with a dialog for personalizing an iView

The dialog itself consists of a tabstrip that contains some generic tab-pages and some additional tabs that can be added by the iView.

Figure 2: Personalization dialog in detail (proposal)

The following features should be available in every personalization dialog and the corresponding tab pages:

A title stating clearly from which iView the dialog was launched. The text should be in the form of "Personal setting for <Title of iView>".
A short text for describing the page's content. This element should be positioned at the top of each tab-page. It should give the user an overview of the possible settings, since the description on the tab itself might not be sufficient.
Section headings. These elements can be used instead of using group boxes to separate subgroups of related settings.

Note that figure 2 is a proposal, not a definite design.

General and iView-specific Settings

General iView settings have an influence on the appearance and function of the iView tray. They will appear as "generic" tabs in the personalization dialog. The major categories are:

Refresh
Specifies whether the iView is refreshed automatically (and in which interval) or manually. This tab will appear in the personalize dialog if the iView can in principle be refreshed. If there is no need to refresh the iView, the tab is omitted.
Settings
Settings include: Display of a status bar, handling of alert- and ready-messages or appearance at startup (collapsed/expanded).

iView-specific settings can relate to the appearance of the iView's content, both in terms of display options (detail- or list view within the PortalDataViewer) and settings that determine the selection and display of data. Examples for these specific settings are:

Content
Should be the name of the tab containing the "semantic" settings for the business content, i.e. a range of values to be displayed or any kind of pre-selections which are not frequently changed and thus are not handled by a shuffler.

Figure 3: Sample content for the settings page (from a Search iView)

Display
The Display tab contains settings for the representation of the data, i.e. whether data is to be displayed as a table, as text or as a graphic. When using a PortalDataViewer, this tab might be obsolete, since the PortalDataViewer's display options are handled on a separate tab (see figure 5).

Figure 4: Sample content for the display page (from a Search iView)

Figure 5: Sample content for the display page (from an iView using a PortalDataViewer)

An iView can add more categories if the settings of the iView do not fall within the proposed classification. However, keep in mind that the dialog should be as simple as possible. There should be no more than six tabs in the dialog; rather than having a STSS (single-tab-single-setting) approach, try to have a more general category on the tab and do sub-groupings on this tab page.

Designing iView-specific Categories Beyond the Predefined Ones

While the predefined categories will probably be a fixed template, the iView-specific categories have to be designed by the iView developers. Here are some general guidelines:

Stick to the proposed naming conventions for the tabs (see above). It is always a good practice to make dialogs with the same intention behave and look similarly
When defining new categories, choose the names carefully. Avoid labels with overlapping meanings (such as View and Display)
Do not use a tab as a group box, i.e. do not take the STSS-approach (see above). Try to use a more general category and do reasonable sub-groupings on this tab.
Provide a short key sentence for any (sub)group of settings, explaining what the settings are intended to do.

top