Personalizing iViews

Introduction | Types of Personalization | Guides for Personalize Dialogs

Important: The information in this section is highly preliminary; it will be updated as soon as possible. Until now, there doesn't exit an agreed-upon concept of personalization.

 

Introduction

The iView-View is probably the most 'private' or 'personal' view inside the Workplace framework. Hence there is a great need not only for specifying which iViews will be displayed, but also how they are shown and what their contents are. There will be only a few iViews that cannot be adapted, parameterized or customized in many ways. This section describes the concept for an end-user personalization which needs to be considerably easier than what might be done by customization.

Types of Personalization

Basically there are two types of settings to be distinguished when speaking about adapting an iView to specific needs:

  • Customizing
    Is used for pre-configuring or setting up the iView. 'Customizing' can be done in different ways, e.g. by passing parameters. Besides specifying the technical and the business background of the iView, 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.
    There is currently no specific interface for this level of customizing an iView.
  • End-User settings
    End-User settings should be as easy as possible. They 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.

Guides for Personalize Dialogs

Users need access to their personal settings with a consistent interface for all applications. Settings which are common for virtually all iViews should be provided as generic building blocks that can be blended with application-specific options. The generic blocks will always 'just be there' whenever applicable for an iView; the specific settings will be tailored for each iView and should be grouped into a set of categories as described below.

Since an iView is limited in terms of screen-space and should always retain a stable framework it is not allowed to handle the personalization of an iView inside the iView Container itself. The number of elements during the personalization can easily exceed the complexity of the iView itself. For this reason, the personalization should always be handled in a dedicated modal dialog window, which is called using a standard interface.

The Personalize Dialog

iViews will use a generic personalization dialog. The dialog will be displayed as a modal window in the center of the screen (see following picture) if the user clicks the 'Personalize' button of an iView. This button is located in the upper right-hand corner of an iView tray.

Figure 1: Appearance and size of the Settings Dialog

The standard dialog size is 450x450 pixels, the 'editable' area resulting in a size of approx. 430x350 pixel.

The dialog is modal and can be closed via an 'OK' or a 'Cancel' button, located at the lower right of the dialog. 'OK' applies all changes and closes the dialog; 'Cancel' abandons all changes and closes the dialog as well.

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

Figure 2: Personalization Dialog in detail

The following features should be available in every 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.

Interim Solution
The Dialog currently contains up to two tab-pages. The first one is used for the generic iView settings (settings that influence the appearance and behavior of the whole iView and it's tray); the second one is used for content-specific settings. This second page displays a service that is assigned in the iView catalog and is written by the iView development team.

General and iView-specific Settings

General iView settings have an influence on the appearance and function of the iView 'container'. They will appear as 'generic' tabs of 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 listview within the MiniALV) 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 MiniALV, this tab might be obsolete, since the MiniALV'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 MiniALV)

An iView can add more categories if the settings of the iView do not fall into 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.

Designing Settings Dialogs: General Rules

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

  • 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 that are semantically 'overlapping' (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 top

Source:  SAP iView Guidelines for Java