T ES

Menu
SAP iView Guidelines
Read First 1. Introduction Intro: Views - Small, but Useful Helpers What is an iView? Identifying iViews Golden iView Rules - The iView Dos and Dont's
q q q
2. Examples for iViews Classification of iViews Alert iView Report iView Application iView Text iView Chart iView Graphic iView Generic iViews
q q q q q q q q
3. Framework and Layout iView Containers - Trays Tray Sizes and Arrangement Layout Hierarchy - Nesting Rules Layout within iViews HTMLB Library - Overview HTMLB Controls - Visual Overview Chart Types - Overview Personalizing iViews Visual Design Aspects
q q q q q q q q q
4. iView Interaction Complexity Saving Space and Reducing Complexity Navigation Scrolling Buttons Fields
q q
q q q q
file:///F|/resources/ma_guidelines_3/content.html (1 of 2) [03.12.02 10:15:44]
Menu
q q
q q q q q q
Texts, Lists, Links PortalDataViewer, HTMLB Table View, and Tables Graphics and Charts Selecting Views Filtering Data - The Shuffler Icons and Status Information Messages Help and User Support
References
file:///F|/resources/ma_guidelines_3/content.html (2 of 2) [03.12.02 10:15:44]
SAP iViews Guidelines
SAP iView Guidelines

Updated edition - May 2002 This edition of the SAP iView Guidelines comprises guidelines for the interaction design of iViews. It does not intend to replicate interaction rules found in other SAP guidelines. Instead, it typically presents only rules that are specific to iViews. Technical information, detailed information on controls, and information on visual design can be found elsewhere. Please refer to the iView Community Web pages, the Portal Development Kit (PDK) documentation, the SAP Portals HTMLB Guidelines (use of HTMLB controls), the SAP Reference Lists (terminology, status icons), and the Recommendations for Charts and Graphics in the SAP Design Guild (use of charts and graphics).
These guidelines address a diverse audience:

q
First, there are the SAP developers: They create iViews using tools and techniques provided by SAP, such as HTMLB and the SAP portal framework. These readers want to know what is available and how they can use it. Here they find the look and feel information and guidelines on how to design user-friendly iViews. Technical issues are covered by other SAP information sources for developers (see above). A second important group of readers are developers outside SAP who want to become part of the iView community and who also want to develop iViews for the SAP portal environment. These developers often cannot use the tools and techniques that SAP developers have at their disposal. These guidelines show them how iViews should look like, that is, which screen elements can be used in iViews, and how iViews should be designed using such building blocks. Thus, even though the technical basis and approach may be quite different from that of the SAP developers, these guidelines help this audience to achieve the same look and feel for iViews. There are also developers outside SAP who can use the SAP tools and techniques; for these readers most of the information applies that is relevant to SAP developers. Finally, there are developers inside SAP who want to go beyond the possibilities provided by SAP tools and techniques. These SAP developers are in a similar position as outside developers who have no connection to SAP tools. They, too, can use these guidelines as source of information on how screen elements should look like and be interacted with - irrespective of whether these are available or not.
Note: The design examples in these guidelines tell developers how iViews should be designed - they do not necessarily mean that ready-made SAP solutions already exist for these examples, although in this edition of the iView guidelines we try to stay within the available options. Disclaimer: The images presented in these guidelines are for reference only. They are not exact to the detail with respect to exact pixel sizes and spacing, RGB color values, etc. These characteristics may also change without notice, depending on the evolution
file:///F|/resources/ma_guidelines_3/read_first.html (1 of 2) [03.12.02 10:14:47]
SAP iViews Guidelines
of the HTMLB library and the SAP Portals portal environment. For exact details, please refer to the HTMLB documentation. Status This edition is based on the HTMLB library used for SAP Portals Enterprise Portal 5.0. In some cases, we provide previews of what is to be expected in Enterprise Portal 6.0 or later. The SAP iView Guidelines will be updated as necessary. Version 1.0, May 2002
top Source: SAP iView Guidelines
file:///F|/resources/ma_guidelines_3/read_first.html (2 of 2) [03.12.02 10:14:47]
Intro: iViews - Small, but Useful Helpers
Introduction | Essential Design | Important Things First! | Information about Work Context and Business-Related States | The Right Information for the Right Decision | iViews | Personalizing and Role Fit
Introduction
The challenge for the next years will be - apart from further improving and simplifying software applications - to provide and process knowledge. Computers shall not and will not make intelligent decisions on their own, but are meant to provide humans with the necessary information in an optimal fashion. The SAP portal environment with its iViews takes a first big step into this direction by providing and integrating role-specific knowledge from various information sources. iViews reside in the content area or work space of the portal and typically occupy far less screen space than usual applications. The small containers (called trays) that host iViews are collapsible and expandable. Thus, users may hide less important or currently not used iViews and show them again as needed. Vertical scrolling within the portal allows users to quickly position on a wanted iView without the need for closing other iViews. This navigation principle is efficient for and suited to Internet browsers, because users can switch between iViews without experiencing disturbing page reloads.
Essential Design
Interaction design for iViews places a high burden on application developers, because design has to focus on the essentials. This requires in-depth knowledge of a user role's needs and to set adequate priorities. Though it is often hard to reduce functionality and information to the essential, such reduction is the real advantage of iViews over conventional applications: Risking to lose additional information also emphasizes what is really important for users. This general design rule is valid for any application, but even more so for iViews. iViews are set apart from other applications by being less complex. An iView's content and "message" must be grasped at one glance. Interaction should generally be restricted to one screen only. It is not the goal of iViews to squeeze rich functionality into a small screen area. Instead, developing iViews means to create new, simple applications - applications that have more the character of information providers and that cohabitate with other, modular iViews in the SAP portal environment. If your iView takes more screen real estate than a fourth of the portal, consider either
q q
to redesign the iView so that it takes less space, or to convert your iView to a Web application (IAC = Internet Application Component) or other application type
Reducing design to the essentials has positive side effects. Fewer screen elements and fewer decorative elements reduce the complexity of the screen and help users to find relevant information faster. See How to Make iViews "Mini" and Less Complex for tips on saving space!
Important Things First!

Often valuable tools are deeply hidden within an application or not at all supported. For some work places R/3 was more of a system where users had to enter lots of data, but it was not very helpful in their daily work. iViews address this lack of user support
file:///F|/resources/ma_guidelines_3/introduction/intro.html (1 of 3) [03.12.02 10:14:49]
by directly providing useful and role-specific information on the entry screen of the SAP portal environment - instead of hiding this information deeply inside applications. They do not require users to enter even more data, but offer useful information. But how do we know which information is regarded as useful by a certain user? The answer is: Any information is useful that is connected to the goals of a task and that is suitable to support decision making. Much too often applications only copy the observed task steps, but forget to provide information that enables users to decide whether and how they will take actions in order to achieve a certain goal. Therefore, it is imperative for successfully designing applications to visit customers and to get into direct contact with end users - only this ensures that developers get a clear and correct picture of the goals and responsibilities of a user role. Based on these observations, the users' primary information needs can be easily derived.
Information about Work Context and Business-Related States

iViews are intended to provide for the users' primary information needs, for example by making a user's work context more transparent. This applies to the personal work context, which consists of an individual work supply and the status displays of processed objects. But it also applies to the business context, the status of which can be mediated by displaying relevant business figures. A user's role may seem to require to display states dynamically and in real-time. However, a closer look often reveals that many work supplies are updated only once or twice a day. For example, new availability lists for overdue goods are generated over night and then processed during the following day. Such lists need not be available in real time. Apart from such (more or less) up-to-date data, iViews may also provide access to often used static information, such as legal regulations, reference books, or guidelines.
The Right Information for the Right Decision

Apart from general state information, data that may initiate actions are important. These data may be critical messages which signal an exception that requires fast reaction. But there are also data that we use in our daily work for planning the next steps, often without even being aware of this. All routine jobs are based on a fixed mental rule set; we use these rules together with current information to plan the next steps: You know what to do next, but you also have to take current data into account in order to decide which step is the appropriate next one. If such information is missing or incomplete, it may be very laborious for users to plan the next actions. Often the level of information is inappropriate and thus causes unnecessary stress. If, for example, differences between values or data ranks comprise the relevant information, this type of information should be directly supplied to the users; the users should not be required to perform mental comparisons or to generate complex ad-hoc reports in order to find these data. A display of trends for certain business data or a statistics on unread e-mails can already be valuable information for deciding what to do next. Choosing the proper visual representation of data is important as well. Often, two design alternatives seem to be equally good choices. But this is not true for the user! For instance, a table and a chart may contain the same information. However, both presentations - though formally equivalent - may actually serve very different user goals: A chart helps to quickly find relevant features (goal "fast information overview"), while a table provides exact numbers (goal "know exact values") but makes it harder to find the relevant information. The goal of an iView should be to make every information accessible that is relevant for taking actions and that supports decision making. Developers have to rethink their applications and to put data to the front that up to now have been hidden deeply inside applications or at the bottom of long reports. Such a redirection enables users to decide first and then take actions.
It is obvious that iViews will not replace ordinary applications. But iViews should cover the users' primary information needs without forcing them to call applications. iViews are like previews on applications or collect data from predefined reports which cover 80% of the needs of a certain role.
Mini Tools
Apart from the above-mentioned information-oriented iViews, such iViews should populate the workplace that provide often used functionality like simple and easy to use tools. For example, an iView could convert currencies or units, or allow data transfers that are reduced to the very minimum, such as the booking of a routine trip. See Generic iViews and Identifying iViews for examples of such mini tools and approaches to identifying potential iViews.
Personalizing and Role Fit

Because iViews are strictly oriented to the users' needs, users must be able to adapt them to their personal preferences; also system administrators must be able to adapt iViews to the business context at hand. Often only the customers will know which iViews do make sense for certain user roles. Users themselves, too, will want to select their personal iViews from a broad set of iViews and personalize them. Like role definitions, iViews will often just be templates which have to be adapted by system administrators and end users to the business context at hand. Customizing the portal according to user roles not only includes technical issues, such as access rights, but also an analysis of the target roles for a customer based on business content and functions. Such an analysis can be supported by directly interviewing selected users that fit the role profile. See What is an iView? and Personalizing iViews for more information on adapting iViews to user roles and to the users' preferences.
What is a iView?
What is an iView?
Definition | Characteristics | Uses | Adaptation
Definition
An iView refers to any kind of application, information or service that can be visualized in a Web browser frame. iViews appear in a special container called tray, which offers a certain functionality for using and adapting the iView. iViews are self-contained Web documents that are provided via a Uniform Resource Locator (URL) managed by the SAP portal framework. The resource itself can be anywhere on the Web. Examples of iViews: Alerts, reports, e-mail/calendar, etc. Content - not just a Point of Entry An iView is not simply a point of entry or a entry mask which leads directly to a Website. That is, the iView must offer some content to users and fulfill its raison d'tre within the allotted space. Additional information may be offered as a link and take the user to the provider's Website. For example, if a user enters a word in a dictionary iView, the definition should appear inside the area of the iView. A link to usage examples, similar words, etc. could be provided which would then take the user to the provider's homepage. Added Value An iView should provide the user with some added value, such as customized pushed information, integration with different applications and systems, etc. Integration - Roles, Work Sets, and Tasks iViews on a portal page may be integrated in the sense that they share information or feed one another with information, similar to information cockpits. Such an integration further enhances the work place of a user and provides additional value; as shown below, it can be based on the concepts of user roles and worksets. The whole set of iViews provided in the SAP portal environment depends on the role of the user. Subsets of iViews may be grouped together to form a workset. A workset comprises a complete work intent within a user's role, that is, a set of tasks for fulfilling that intent. Thus, worksets are constituents of a role. Or the other way round: A user role can be regarded as a bundle of worksets, which themselves bundle certain tasks into autonomous units within a role (see figure 1).
file:///F|/resources/ma_guidelines_3/introduction/what.html (1 of 4) [03.12.02 10:14:53]
What is a iView?
Figure 1: Relation between a role, several worksets and the tasks assigned to worksets
Definition of Workset A workset is usually assigned to a job role. It may also embed other smaller worksets. Tasks are the activities that are performed in the context of a workset. A task can be more or less complex. Some tasks may require a larger set of services, while others correspond to one single interaction step. Depending on this, the workspace design will based on portal pages filled with iViews either give an overview and will provide access to related services or it will directly offer in-place actions. So far, the concept of worksets has been limited to stateless iView collection that are used to deploy and assign targeted content to portal users. In a second step, this concept can be generalized to support instantiated, state-full worksets that represent a current state of a working process. That is, iViews may no longer be stateless but communicate with each other, or depend on each other.
Characteristics
iViews have the following characteristics:
q q q q q q q q q
Stateless: Not permanently connected to the SAP System Embedded: Non-dominant, parallel to other iViews Preview: Provides preview on underlying processes, data Simple: Very limited, one-screen interaction (Palmtop-like) Essential: Includes only key functionality Direct: Provides direct access without navigation Active: Pushes information, refreshes periodically Open: Integrates third-party software Personal: Allows user to modify appearance
What is a iView?
Uses
The basic uses of iViews are to provide information and to accelerate the users' work. Below we present examples for these uses. Information The key message here is to provide data instead of asking for them.
q q q q q
Offer active information Monitor business processes Preview data and processes Display notifications for initiating task-related processes Provide fast access to often used data
Accelerating Work The key message here is to provide simple and efficient services.
q q q q
Provide direct access to simple applications Provide accelerated access to other applications Reduce information and interaction to the necessary Drag-and-Relate: Use outputs (results) as inputs via drag-and-drop between iViews and iPanel
Adaptation
iViews can be adapted to the users' role and needs on a two-level basis. Customization is typically performed by the system administrator for a user role, that is, for a set of users that fulfill the same role in a company. Personalization is carried out by the individual users - they adapt the iViews and portal pages to their personal needs. Customization What the system administrator does for the users (based on user roles):
q q q
Select iViews from a pool of iViews according to a user's role Reduce information unnecessary to a user's role(s) and goals Provide focussed information tailored to a user's role(s) and goals
Personalization What the users themselves do:

q q q
Select iViews from a pool of iViews (preselected for the role) Provide content for generic iViews Subscribe to content for iViews
Note: Currently, the personalization of an iView beyond its appearance on a portal page has to be handled by the iView itself.
What is a iView?
There is no general personalization interface available.
Identifying iViews
Identifying iViews
How Can I Identify Potential iViews? | Which is a Useful iView, Which iView Does not Make Sense?
How Can I Identify Potential iViews?

The best way to identify potential iViews is to watch users at work and to study their behavior. A user's work place tells a lot about which information and transactions a user needs on a regular basis. For example, a user may stick Post-Its along his or her monitor with the names of transactions or reports. Or he or she may stick such lists on the wall or put them elsewhere. Generic vs. Role-specific iViews Users also often use small tools, such as calculators, currency or unit converters, or reference books, such as dictionaries, address books, and phone directories. All these tools and information sources are possible candidates for iViews. Some of these tools are useful for many users; they may be offered as "generic iViews". Other tools may be specific to a certain role and thus are candidates for role-specific iViews. Examples for generic iViews: Calendar, currency converter, calculator, notepad Note: A list of possible generic iViews is presented in Generic iViews. "Helper" iViews In addition, watching the work practice may provide useful hints about which information the users needs in untypical situations in order to overcome errors or problems. Again, the tools and information sources may be candidates for iViews, even though these are rarely used. Examples for Helper iViews: Emergency phone directory, personal code storage, instructions
Which is a Useful iView, Which iView Does not Make Sense?

Useful iViews Any information or transaction that is used on a regular basis or that must be easily accessible in problem situations is a potentially useful iView. In addition, there are many pieces of information that users need every morning when they start work, every evening when they quit work, or in certain recurring situations. Examples: Recurring tasks, startup tasks, finishing tasks, birthday reminder Useless iViews iViews that provide information or functionality that is only rarely used do not make sense.
file:///F|/resources/ma_guidelines_3/introduction/identify.html (1 of 2) [03.12.02 10:14:52]
Identifying iViews
Example: There is no point in creating an iView that is used for customizing a function once because the user needs such an iView only once and then never again.
file:///F|/resources/ma_guidelines_3/introduction/identify.html (2 of 2) [03.12.02 10:14:52]
Golden iView Rules - The iView Dos & Don'ts
Purpose and Basic Behavior | iViews on a Portal Page | Data Processing | Presentation | Navigation | User Support The following "golden rules" capture the essence of iView design.
Purpose and Basic Behavior

iViews...
q q q
Provide previews of processes or data Have a very limited, one-screen interaction model and include only key functionality Provide direct access to data or functionality without navigation
iViews on a Portal Page

iViews are not alone but share a portal page with other iViews. Therefore:
q
Make your iViews as small as possible (but care for the correct iView sizes); do not let your iView occupy the whole portal page Make your iViews distinctive; users cannot find information efficiently in a uniformly looking iView view without any structure
Data Processing
q q q q
Do the primary data selection beforehand Let users apply filters to this "preselected" information to display only the most important bits Offer filters based on attributes (shuffler) instead of selections based on logical operators Break down hierarchical data structures and present items as lists; do not create hierarchical categories where users have to navigate through the category levels
Presentation
q q q q
Use charts or graphics instead of text if these convey information faster and more efficiently to the users Add text to graphics or charts where explanations or exact values are necessary Use text attributes, such as headings or small text to structure textual information If an iView does not yet contain any information (e.g. a list of events iView that has not yet been personalized), use the free space to provide some short explanatory text Use space economically
file:///F|/resources/ma_guidelines_3/introduction/goldenrules.html (1 of 2) [03.12.02 10:15:00]
Navigation
q
iViews typically have only one screen, there should be no screen changes. Exceptions Views that provide a stable frame of reference (e.g. switching views with a shuffler or tabstrip-like mechanism, although tabstrips are not recommended: see Complexity), r iViews that are based on a well-known metaphor like notebooks. r iViews that provide results of a process, such as search (if the result list is small) Provide easy access to more extensive data views and program capabilities. Example: Let the users click on links to access related Web (IACs) or R/3 applications.
r
User Support
q q q q
Save user preferences so that users need not repeatedly perform the same steps for choosing data when they start an iView Provide personalization capabilities (see Personalizing iViews and What is an iView? for details and current restrictions) Avoid error messages More importantly: Prevent errors! There should be no errors in iViews
file:///F|/resources/ma_guidelines_3/introduction/goldenrules.html (2 of 2) [03.12.02 10:15:00]
Classification of iViews
Classification Based on Typical Usage | Classification Based on Interface Elements iViews may cover a wide range of applications. To structure the manifold potential types of iViews, this page attempts to classify iViews according to two different criteria: (1) the typical usage scenarios, and (2) the dominant interface element. The following pages present examples for iViews based on the dominant interface element; these are the alert, report, application, text, chart and graphic iView. Further you can classify Views with respect to whether they are specific to a certain task or user role, or whether they are general in scope and may be used in a variety of contexts and roles. The latter class is called generic iViews. See page Generic iViews for an overview of potential generic iViews.
Classification Based on Typical Usage

The following classification and list of examples of iViews is based on typical uses. Reports
q q q q q q
Reports (tables, graphs) Ad hoc queries Quick directories Top ten Monitors (real-time reports) Cockpits (multiple connected graphs and tables)
Information
q q q q q q
Messages (transient) Communication (permanent) Workflow inbox Notifications News, information Advertisements
Containers
q q q q q q
Links as short cuts MyObjects Favorites ToDo On-Hold Shared team folders
Applications
q q q q q q
Simple data entry apps Previews of full apps Wizards Remote control for devices Time management Tools
file:///F|/resources/ma_guidelines_3/examples/classification.html (1 of 2) [03.12.02 10:15:10]
q
Toys
Interfaces to Third-Party Applications or ERP Systems

q q q
Siebel Oracle etc.
Classification Based on Interface Elements

The following iView classification is based on the dominant interface element that an iView contains:
q q q q q q
Alert: Contains status information, e.g. status icons Report: Contains a report (typically a table) or report result (typically a table or chart) Application: Contains form elements, such as fields, selection elements, and buttons Text: Contains larger pieces of text (possibly with graphics and links) Chart: Contains a chart Graphics: Contains an image, diagram, sketch, photo, or other graphical element
We use this classification for the iView examples on the following pages because from an interface and visual design point of view the interface elements are the relevant features of an iView.
file:///F|/resources/ma_guidelines_3/examples/classification.html (2 of 2) [03.12.02 10:15:10]
Alert iView
Alert iView
Example | Use | Look
Example
Figure 1: Table-based alert iView
Use
An alert iView notifies users of certain critical events. Typically, alert iViews use status icons or graphics in order to attract attention and guide it to the relevant information. Note: See Icons and Status Information for details on status information. See SAP Reference Lists in the SAP Design Guild for a complete list of status icons..
Look
The alert information should comprise the main part of the iView. Typically, alerts are arranged in tables, but this need not be the case. Alert information can also
q q
be arranged in a form-like manner use graphics or charts
If there exists a related Web application (IAC), place a right-aligned button below the table to allow users to call the application.
file:///F|/resources/ma_guidelines_3/examples/alert_ma.html (1 of 2) [03.12.02 10:14:58]
Report iView
Report iView
Example
Figure 1: A report iView displaying a table.
Use
A report iView displays a report, typically as a table, or report results; these may also be a table or a chart (see Chart iView).
Look
The table should comprise the main part of the iView. Order of Screen Elements
q
q q
A filter of shuffler can be placed above the table, if data can be selected from several sets or if the amount of data has to be reduced. Then follows the table. Place pushbuttons related to the table below the table and left align them.
r If there exists an alternative chart view, a button below the table allows to toggle between table view and chart view. Place pushbuttons related to the whole iView in the lower left corner. If space is at a premium these buttons may reside in the same row as table-related buttons (see Buttons for details). r If there exists a related Web application (IAC), a button in this group should allow the users to call the application. If there is an emphasized button, it is the leftmost button of the respective button group (table-related or iView-related). There must not be more than one emphasized button!
Initial Size and Appearance
file:///F|/resources/ma_guidelines_3/examples/report_ma.html (1 of 2) [03.12.02 10:14:59]
Report iView
Empty tables are not displayed in iViews. In addition, no space is reserved for the table or for a sentence, such as "No entries found". Exception: There is one exception to this rule: Tables where users can immediately enter data should appear in the intended size and with empty lines. Automatically Generated Tables Tables that are generated automatically by the portal framework may have a different look and behavior than the table view and the portal data viewer.
file:///F|/resources/ma_guidelines_3/examples/report_ma.html (2 of 2) [03.12.02 10:14:59]
Application iView
Application iView
Example
Figure 1: The measurement converter is an example for an application iView
Use
An application iView is a small and very simple application where users may have minimal editing facilities. Typically, such applications are small tools that enhance the users' working environment. Note: See Classification of iViews and Generic iViews for examples of application iViews.
Look
An application iView typically contains form elements, such as fields, selection elements (checkboxes, radiobuttons, dropdown lists, ...) and buttons, that is, it may have a "forms-like" look. Order of Screen Elements
q q q
Start with header data, if there are such general data. Then follows the forms-like part of the iView. Place pushbuttons related to the whole iView in the lower left corner. If space is at a premium these buttons may reside in the same row as table-related buttons (or other buttons relating to elements of an iView) (see Buttons for details).
r
If there exists a related Web application (IAC), a button in this group should allow the users to call the application.
file:///F|/resources/ma_guidelines_3/examples/app_ma.html (1 of 2) [03.12.02 10:15:10]
Application iView
q
If there is an emphasized button, it is the leftmost button of the respective button group (object-related or iView-related). There must not be more than one emphasized button!
file:///F|/resources/ma_guidelines_3/examples/app_ma.html (2 of 2) [03.12.02 10:15:10]
Text iView
Text iView
Example
Figure 1: An iView displaying text information with different attributes
Use
A text iView displays primarily text information. The text can be structured by using different text attributes (see example above) separating elements like white space and lines (horizontally and vertically)
q q
Text information may contain links that open other applications or Websites within the portal or in separate windows. Text may also be accompanied by graphics, such as photos or charts.
Look
file:///F|/resources/ma_guidelines_3/examples/text_ma.html (1 of 2) [03.12.02 10:15:11]
Text iView
The text should comprise the main part of the iView. Text may also be accompanied by graphics like photos or charts, but the text should remain the dominant element. Typically text iViews do not have buttons.
file:///F|/resources/ma_guidelines_3/examples/text_ma.html (2 of 2) [03.12.02 10:15:11]
Chart iView
Chart iView
Example | Use | Look | Functionality | Legend
Example: Horizontal Bar Chart Table
Figure 1: A horizontal bar chart table; for exact comparisons, the values have been added to the chart.
Use
A chart iView displays data that are relevant for the user in a graphical representation so that the characteristics of the data and their relations are easy to capture for the user. In cases where it is important for users to know the exact values behind the data, an alternate view may present the data in a table as numbers or texts. A button should allow users to toggle between the diagram and the table view. If more data is needed, the iView should call a related Web application (IAC) that displays the data in a larger table or diagram. Note: For an overview of the charts types that are available in HTMLB, see Chart Types - Overview in section Layout and Framework. For more information on charts and their uses see Graphics and Charts in section iView Interaction. For background information on charts see Recommendations for Charts and Graphics in the SAP Design Guild which discusses the use and design of charts at length.
Look
The chart should comprise the main part of the iView.
file:///F|/resources/ma_guidelines_3/examples/chart_ma.html (1 of 2) [03.12.02 10:15:12]
Chart iView
Order of Screen Elements

q
q q q
A filter of shuffler can be placed above the chart, if data can be selected from several sets or if the amount of data has to be reduced. Then follows the chart. Place legends or other text right to the image or below it, depending on the format of the chart. Place pushbuttons for chart-related functionality and status information (e.g. zoom factor) below the chart and left align them.
r If there exists an alternative table view, a button below the table allows to toggle between diagram and table view. Place pushbuttons related to the whole iView in the lower left corner. If space is at a premium these buttons may reside in the same row as chart-related buttons (see Buttons for details). r If there exists a related Web application (IAC), a button in this group should allow the users to call the application. If there is an emphasized button, it is the leftmost button of the respective button group (chart-related or iView-related). There must not be more than one emphasized button in an iView.
Functionality
Typical functionality, which charts may offer, are:
q q
Switch between chart view and table view Zooming and panning
Legend
Place a legend right to the chart or below the diagram to explain used colors or symbols. For HTMLB charts, the legend is generated automatically and can be hidden or displayed in four possible locations. However, place the legend to the right (preferable) or below the chart.
file:///F|/resources/ma_guidelines_3/examples/chart_ma.html (2 of 2) [03.12.02 10:15:12]
Graphic iView
Graphic iView
Example | Use | Functions | Look | Storage | Copyright
Example
Figure 1: A photo may help to recognize colleagues more easily
Use
A graphic iView displays a graphical image. This may be a photo, a diagram, or even a sketch. The graphic may also be animated or a video (movie). The graphic should contain the main message of the iView. Text may accompany and explain this message. In iViews graphics should not be used just to illustrate textual information. Note: For more information on graphics see Graphics and Charts; for additional background information see Recommendations for Charts and Graphics in the SAP Design Guild. Examples
q
q q
Photos: Employees (address book of a company), buildings (for brokers), objects for auctions, archives, museums (e.g. plants, animals, furniture, ...) Diagrams: Floor plans (where can I find my colleagues?), street maps, maps, instructional diagrams Sketches: Sketches can be used for fast communication of ideas between colleagues (picture scrapbook), sketches can serve as "raw" or preliminary diagrams or as replacement for diagrams
file:///F|/resources/ma_guidelines_3/examples/graphic_ma.html (1 of 4) [03.12.02 10:15:15]
Graphic iView
q q q
Animated Graphics: For explaining procedures, for fun applications Decorative Images: Postcards to send to colleagues per e-mail (for birthday greetings or just for fun) Cartoons: For fun applications
Functions
For images that are larger than the visible area, provide the following functions. Place the buttons for these functions below the image (see Look). Zooming
q q
Zoom in: Zooms into the image in predefined steps (magnifies centered) Zoom out: Zooms out of the image in predefined steps (shows larger section)
Show the zoom factor! Changing the Visible Section of an Image Changing the visible section of an image with scrollbars is cumbersome. Better offer the possibility to move the image section manually by grabbing it with the mouse (the cursor should turn into a hand over the image). Provide a toggle button for turning "grab" mode on and off. Reset to Default View If zoom or move functionality is provided, also offer a function Reset to default view.
Look
The graphic should comprise the main part of the iView. Order of Screen Elements
q
q q q
A filter or shuffler can be placed above the graphic, if graphics and data can be selected from several sets or if the amount of data has to be reduced. Then follows the graphic. Place legends or other text right to the image or below it, depending on the format of the image. Place pushbuttons for image-related functionality and status information (e.g. zoom factor) below the image and left align them. Place pushbuttons related to the whole iView in the lower left corner. If space is at a premium these buttons may reside in the same row as image-related buttons (see Buttons and figure 2 below for details).
r If there exists a related Web application (IAC), a button in this group should allow the users to call the application. If there is an emphasized button, it is the leftmost button of the respective button group (image-related or iView-related). There must not be more than one emphasized button in an iView.
Examples Photo
Graphic iView
See example above. Diagram
Figure 2: A floor plan may be useful in many occasions

Sketch
Figure 3: A sketch may be effective for fast communication between colleagues

Animated Graphics, Video, or Movie
Graphic iView
Figure 4: Animated GIFs or Flash-Movies can explain procedures or be just fun to watch
Storage (preliminary)
Currently, the technical storage of images that appear in iViews is not handled by the portal framework in a well-defined way. Therefore, make sure that images are stored properly and take part in the distribution process of the portal. Otherwise, your iView would appear in the portal without images.
Copyright (preliminary)
When using graphics from external sources, make sure that copyright issues are settled. Some sources provide images for free, other sources provide the images for free but require a copyright notice, while most commercial sources require a license fee.
Generic iViews
Generic iViews
Collaborative iViews | Commerce iViews | Communicative iViews | Helper iViews | News, External Information iViews | Personal iViews | Search iViews | Self Service iViews | Travel iViews | iViews Accessing Other ERP Systems | Partner Program iViews While most iViews are tailored to the needs of a certain user role, generic iViews may be useful for many roles, or even any user. Typically, users can extend their role-specific set or sets of iViews through such generic iViews. Below we present a classification of generic iViews with potential examples.
Collaborative iViews
q q q q
Collaboration scenarios, Team rooms Chat and shared applications Forum and discussion boards Instant messenger
Commerce iViews
q q
Internet store Home banking
Communicative iViews
q q q q q q
Lotus mail inbox, calendar, address book, contacts, etc. Outlook mail inbox, calendar, address book, contacts (no desktop installation necessary) - Web client, SSO, Outlook today E-mail: Yahoo, Hotmail, ... Bulletin board Telephone book (Web service: US, Germany, ...) SMS, support of mobile devices
file:///F|/resources/ma_guidelines_3/EXAMPLES/gen_app_ma.html (1 of 4) [03.12.02 10:14:52]
Generic iViews
Figure 1: A communicative iView (Workflow inbox)
Helper iViews / Productivity Tools

q q q q q q q q q q
Calculator (specific calculator) Files (my documents, virtual storage on the Internet) Information (notification, web content tracker, package locator) Language (orthography check, translation) Tools (display graphics from clipboard) Navigation (launch collection) System control (macro recorder, frequently used apps) Tasks (my tasks, my projects, Outlook / Lotus tasks) Text (Post-Its) Time (timer clock)
Generic iViews
Figure 2: Dictionary / Thesaurus iView
News, External Information iViews

q q q q q
Analyst news, Market news, Industry news Competitor news, Company news, Enterprise information Stock charts, Stock portfolio Access to specific external information (FASB and GAAP information, accounting standards, international trade, ...) General news, Sports news
Personal iViews
q q q q
Fun, e.g. comic iView Games Photo album Postcard iView (greetings, congratulations, ...)
Search iViews
q q q
Web search, Specialized search engines (e.g. scientific) Address search, ZIP code search, e-mail address search Company information search
Figure 3: A search iView
Generic iViews
Self Service iViews

q q q
Who's Who Leave request Time management
Travel iViews
q q q q q
Weather report Route planner Travel planning: Flight, hotel, car Traffic information Regional information, City information
Figure 4: A weather report iView
iViews Accessing Other ERP systems

q q
Siebel Oracle
Partner Program iViews

q q
ICC Workplace Partner Program: Software Partners, Content Partners New Content Partnership Program Types: Community Member, Approved Community Member
iView Containers - Trays
Introduction | What is a Tray? | Tray Functionality | Tray Types
Introduction
An iView consists of two parts: The actual application written by a development team and a framework or container encapsulating the application. This framework is implemented through a design element called tray which serves as a container for iViews. While the application implements most of the functionality and the behavior experienced by the user, the tray delivers interfaces to common functions used by nearly all iViews. These functions comprise an hide/show mechanism and the ability to personalize an iView. The tray is responsible for displaying the appropriate user interface elements, while the application delivers the content via standardized interfaces.
What is a Tray?
A tray is part of the portal framework. It serves exclusively as a container for iViews. A tray consists of a header bar and a content area (see figure 1). A status area may be offered in the future.
Figure 1: The iView tray (shown in "simple" tray design) The header bar (see figure 1) contains the iView title (left) and small icons (right) for accessing standard tray functionality. See Tray Functionality below for the functions. Trays are available in four different designs (see figure 2). The different designs are distinguished by the color of the content area, and by whether the content area has a border or not. For details see Tray Types below.
file:///F|/resources/ma_guidelines_3/LAYOUT/framework.html (1 of 5) [03.12.02 10:14:58]
Figure 2: A portal page showing all four tray designs
Tray Functionality
The tray provides the following functions (see figure 1 above and 3 below).
Expand, close/open, refresh, edit, remove
Figure 3: The tray functions

Personalize (Edit)
The edit icon (
) opens a dialog or personalize page that allows users to change the characteristics of an iView according to their needs.
Note: Currently, the personalization of an iView has to be handled by the iView itself. There is no general personalization interface available. See Personalizing iViews for preliminary proposals for personalization dialogs. Toggle Open/Close (Restore/Collapse)
The tray has a toggle button that allows users to open (collapse) and close (restore) an iView. An open iView's header shows the "close" icon ( When the button is pressed, the iView is reduced to its header, and the toggle button shows the "open" icon ( Expand (Open in a New Window) ).
).
The expand icon ( Remove
) opens an iView in a new window. The original copy remains on the portal page.
If the user clicks the "remove" icon ( the "Personalize Page" page. Refresh
) the iView disappears from the portal page. The user can show the iView again by adding it to the page on
The "refresh" icon ( ) refreshes an iView. Depending on the functionality behind it, a simple browser refresh or a more complex refresh handled by the application may be carried out. Complex Refresh Some iViews will contain data that is changing over time. Examples are stock quotes or inbox items. Depending on the character of the iView, knowing exactly how old or recent the displayed information is can be crucial to overall usability of the application. Besides knowing about the"age" of a piece of information it will in some cases be necessary to update the content of an iView as required. The intervals for the updating or "refresh" procedure can vary from once a day to every minute, from automatic to manual refresh. Setting this parameter will be handled via a Refresh button or personalized settings. Note: Until now, there is no solution for automatically providing the refresh button in the tray. It must be placed within the iView manually and should be the rightmost button of the row which also contains iView's emphasized button (if there is any), i.e. usually at the bottom of the iView. Provide a hint on how old the information displayed in the iView is - don't just enter the last screen refresh date, but when the last query was conducted (if appropriate). Further information: For information on messages in iViews see Messages; for error handling, error prevention and user support see Help and User Support.
Tray Types
Currently (ERP 5.0), there are four tray types available:
q q q q
The form tray: a tray well suited to host forms The border tray: a tray for complex content The borderless tray: a simple tray The text tray: a tray for texts
These tray types differ from each other on the following three dimensions:
q q q
header bar color, background color, and border color
Having a variety of tray designs at your disposal reduces the danger that a portal page has a monotonous visual appearance and helps users in differentiating iViews from each another. Each of the trays comes with a name referring to its proposed content; we also provide the value that has to be assigned to the attribute design. The trays are presented here in order of their importance. The Form Tray The form tray (design = FORM) has a colored header bar, no outside border, and a light colored background color for the content. Use it whenever an iView's content consists of form elements, such as an entry field, a dropdown list box, checkboxes, or radio buttons: White input fields can be clearly distinguished from the slightly colored background of this tray type. Grouping of the elements sets them apart from the colored background.
Figure 3: The form tray

The Border Tray The border tray (design = BORDER) has a colored header bar, an outside border, and no background color for the content. A collection of different elements is hardly recognized as a group. If such elements belong together they need a frame. Use this design to group such element collections and still retain a decent grouping.
Figure 4: The border tray

The Borderless Tray The borderless tray (design = BORDERLESS) is the simplest tray type; it has a colored header bar, no outside border, and no background color for the content. Use this tray type for clearly shaped elements, e.g. link lists, that do not need an additional frame to group them. This design makes for a very light appearance of a portal page.
Figure 5: The borderless tray

The Text Tray The text tray (design = TEXT) has a light colored header bar, no outside border, and a light colored background for the content (the same color as the header bar when the iView is in the open state). The slightly colored background makes text easier to read than a pure white background. This tray type is well suited to large amounts of body text, as they appear in news or articles.
Figure 6: The text tray
Tray Sizes and Arrangement
Tray Sizes | Placement | Spacing
Tray Sizes
Trays are the containers in which iViews appear. The tray is part of the portal framework, not part of the iView (more information on trays is available in iView Containers - Trays). Currently, there exist two tray versions: (1) the tray provided by the SAP Portal portal framework, and (2) the HTMLB tray. Both trays differ with respect to the functionality that they offer in the tray header (see iView Containers - Trays for details). Note: Trays are reserved for use in iViews. They are not allowed for Web applications (IACs) or other application types. Classes The restriction of iView classes to three increases their reuse value and maximizes the flexibility for both 1024 x 768 and 800 x 600 monitor resolutions. The iView sizes are optimized for a screen resolution of 1024 x 768. In full-screen modus, there is no wasted space or horizontal scrolling if the iViews are exactly the recommended size. At a resolution of 800 x 600 there are a few pixels of extra space. Trays come in different sizes, such as narrow, medium and wide iViews; below we present the different sizes that have been defined for use in the SAP portal environment.
Figure 1: Different types of trays, depending on the overall page layout

Despite the fact that we suggest the content not exceed a certain width in pixels, you as a developer should not define the width of your iView in pixels. The width of your iView content should be set to 100%.
file:///F|/resources/ma_guidelines_3/LAYOUT/tray_frame.html (1 of 4) [03.12.02 10:15:01]
Figure 2: iView sizes should be set to 100%

Arrangement in Columns iViews of the same width should be organized into columns on a portal page. That is to say, narrow iViews appear only below other narrow iViews, medium iViews appear only below other medium iViews, etc. This arrangement of iViews into columns produces a harmonious effect and an organized appearance, helping the user to concentrate on the task at hand and not on unraveling a puzzle on the page. Cockpits, however, must not follow this rule.
Figure 3: Usage of different iView classes with respect to column layout of portal pages
Figure 4 (below) shows two schematic example pages, one negative (left), and one positive example (right) :
No
Yes
Figure 4: iViews must be organized in columns

For possible column arrangements see the following paragraph. Column Arrangements There are four kinds of columns: the full-size column is for Web applications (IACs), not for iViews; the narrow column is optimized for narrow iViews; the medium column is optimized for Medium iViews; the wide column is optimized for Wide iViews. The following are the available standard templates using these column types (see figure 5):
Figure 5: Templates for a screen resolution of 1024*768 (also usable for 800*600)
Placement
The initial tray position on a portal page cannot be determined by the developer but is set by the system administrator for a certain user role. Therefore, iView developers typically do not know, where their iViews will appear on a portal page. In addition, users may personalize their pages and change the position of iViews or remove them from the page.
Spacing
Spacing between Trays The spacing between trays on a portal page is handled by the portal framework. Spacing between Tray Border and iView Content The exact spacing between the tray border and the actual content of an iView is determined by the portal framework and should not be changed by the iView developer (currently, this spacing is 10 pixels). Spacing within iViews For the rules regarding the spacing within iViews see page Layout within iViews.
Layout Hierarchy - Nesting Rules
From Containers to the Layout Hierarchy - A Little Theory | Layout Hierarchy for iViews | Table Overview of the Layout Hierarchy | General Nesting Rules This page describes the layout hierarchy for iViews; this hierarchy defines the options for nesting of iView elements. Thus, this page tells designers, which screen element including containers can be placed into which container. The layout hierarchy is the basis for establishing textual layout rules for iViews. The main goal of such rules is to prevent overly complex and visually cluttered pages caused by excessive nesting. Note: These rules do not comprise the spacing between and within elements.
From Containers to the Layout Hierarchy - A Little Theory

iView elements can either be containers or non-containers. Containers can contain other elements; non-containers not. The layout hierarchy described below basically deals with container elements, that is, with elements that can contain other elements including other containers. Application Containers - Trays At the root of the layout hierarchy there is a "root" container that contains the application. For iViews the application container is the tray. From an iView's point of view the tray is all it knows about - at least from a design perspective.
file:///F|/resources/ma_guidelines_3/layout/layout_hierarchy.html (1 of 6) [03.12.02 10:15:27]
Figure 1: The tray is exclusively used as an iView container

Container Controls Inside iViews Inside an iView, the following container controls define its layout hierarchy:
q q q
Tabstrips Groups Subgroups (group of simple elements with or without heading not included in a group control)
Figure 2a-c: Examples for containers within iViews - the HTMLB tabstrip (top) and the HTMLB group box in two different versions (bottom)
A Matter of Interpretation - Linear Sequences vs. Sequences of Containers From a technical point of view, not all of these containers are "real" containers. For example, subgroups are groups of simple iView elements that may be introduced by a heading. They are typically separated from the remainder of the iView by whitespace or separator lines.
Figure 3: Simple groups are elements, which are introduced by a header; they are separated from each other and from other elements by whitespace
From a layout point of view, however, it is easier to view areas and subgroups as "real" containers. This does not make any difference for the layout process. The advantage of regarding these elements as real containers is that the layout can be expressed in a hierarchical or tree-like fashion, which makes it easy to gain an overview of the iView structure. Non-containers While containers create the "skeleton" of a page, non-containers are the "flesh" of a page. These elements are fields, buttons, selection elements, text units, tables, and images or charts. As these elements differ in complexity, nesting rules ensure that a page cannot become too complex. For example, tables are similar in complexity to groups and tabstrips. Therefore, they are placed on the same level in the layout hierarchy as these containers. A rule that takes this aspect into account might state that tables may not be placed inside groups or tabstrips.
Figure 4: Even though a table is a complex control, from a layout point of view it is a "non-container" because it does not contain other controls
Separators Separators, such as lines or whitespace set elements or containers apart. They are therefore difficult to integrate into a hierarchical model of a page layout. They can be viewed as "concluding elements" or "borders" of containers. Creating the Layout Hierarchy The layout hierarchy is created by placing containers and simple elements on a page. The rules presented below govern how page elements can be combined, either by sequencing them vertically or horizontally, or by nesting.
Containers may contain containers (nodes), simple elements (leaves), or both. In addition, non-containers may reside on the same hierarchy level as containers. However, they are "end nodes" and do not continue the layout hierarchy. Example: A table may reside on the same level as a group or a tabstrip. The layout rules presented below specify:
q q q q q
Which containers may contain which other container(s) including itself The specific conditions for the nesting, for example, alone or together with other elements How many levels deep the nesting may be Which simple elements may be placed into which container and the specific conditions for this Which containers and which simple elements are on the same hierarchy level
Layout Hierarchy for iViews

Depending on the container elements used, different application types can have different layout hierarchies. In the case of the portal environment, there are Web applications (IACs) and iViews. Both application types use different containers, serve different purposes, and therefore differ in complexity with respect to the layout. Here we restrict ourselves to iViews. iView Layout Hierarchy
q
Tray = iView container - may contain: r Tabstrip - may contain: s Group (if it is not the only element) s Subgroup s Table, Image, Chart (if it is not the only element) s Simple elements s Separators r Group - may contain: s Group (if it is not the only element, different group types only) s Subgroup s Table, Image, Chart (if it is not the only element) s Simple elements (form elements, text, ...) s Separators r Subgroup - may contain: s Simple elements s Separators r Table, Image, Chart r Simple elements r Separators
Generally, there should not be more than one level of nesting within iViews. Also, you should note that tabstrips may not be nested. Simple elements are: input fields, selection elements, text, buttons, ... Note: A similar tree can be created for a real iView based on the elements used.
Table Overview of the Layout Hierarchy for iViews

The following table present a more detailed description of the layout hierarchy for iViews. Red cells explicitly prohibit certain ways of nesting controls. Yellow cells indicate cases where elements can be placed into other elements with only certain restrictions. (See also the reasoning behind these rules; these are captured in general nesting rules)
Element below can be placed within Container to the right
Container
iView (Tray)
Tabstrip
Group
Subgroup
Tabstrip
yes: together with other elements no: as single element
no
no *
no
Group
yes
possible - but use with care! one level at maximum use different types for the nesting
no
Subgroup
yes
yes
yes
no
Table
yes
no *
no
Text Area, Graphic
yes
yes
yes
no
Separator (White Space, Line)
yes
yes
yes
no
Heading
yes: for subgroup, text area, graphic
yes: subgroup, text area, graphic
yes: subgroup, text area, graphic
yes (as heading for the subgroup)
Field, Selection yes Element, Icon, Button
yes
yes
yes
Table 1: Layout hierarchy for iViews

Legend
q q
*) As iViews are simple applications, tabstrips and table views should not be placed into group controls. Red cells: Nesting forbidden

q q
Yellow cells: Nesting allowed under certain conditions only Where a "no" is shown in bold, it indicates a common error, such as nested tabstrips.
General Nesting Rules

The following nesting rules are derived from the table overviews above and arranged according to design rationales, such as avoiding too much framing and avoiding redundant headers. Avoid Redundant Headers The nesting rules defined for the layout hierarchy strive for avoiding redundant headings. Thus, do not place: Singular group boxes into tabstrips Singular tables with a table heading within group boxes
q q
Avoid Too Much Framing (Visual Complexity) Too many frames and borders make iViews visually complex and waste screen space. Thus, do not place: Singular tables with a table header within group controls use a table heading instead Singular tabstrips within group controls Group boxes within group boxes use sub groups with text headers and separators instead (not forbidden but should be used with care try to use different types for the nesting) Tabstrips within tabstrips nesting tabstrips is a perfect way of information hiding
q q q
Specific Nesting Rules Relations between Controls Specific nesting rules care for the relation between controls - in short, they describe what can be placed inside a container control. You can extract the specific nesting rules for controls from the table overview above. In addition, we provide explicit rules for specific controls in Layout within iViews.
Layout within iViews
General Considerations | Rules for Specific Controls This page present layout rules for iViews. We start with general considerations about spacing and grouping of elements within iViews. Then follow rules for complex controls, such as tabstrips, group boxes, tables, and trees.
General Considerations
General Rules for Separating and Grouping Screen Elements To separate and group screen elements within an iView, rely on the Gestalt Laws. The most prominent one, the Law of the "good Gestalt", states that the human brain always tries to organize the perceived elements into sensible structures. Following the Law of Proximity, items that are spatially near to each other are seen as belonging together - no group boxes needed! Use white space for structuring information in iViews: Field groups, tables or compound elements like the shuffler should be separated from other elements by empty lines. Example: Separate a shuffler by an empty line from the table below it. Whenever possible, use empty lines instead of group boxes for clustering screen elements. Empty lines use less space and are visually less complex than group boxes (group boxes also currently interfere with the tray design). Exception: When using narrow iViews of low height, there is little room left for the content. In this case, try to design the iView without separating elements, that is, without empty lines. Make sure that the layout does not become confusing! Hint: Empty lines or columns can be realized by using a grid layout. Grid layouts can be nested. Spacing Within iViews For the exact spacing values within iViews, refer to the SAP Portals HTMLB Guidelines. However, application developers usually do not have to care about spacing values in pixels because they can use layout controls provided by HTMLB, which care for the correct spacing. Such layout controls are the grid layout and the flow layout; other controls may follow in the future. Application developers only need to consult the SAP Portals HTMLB Guidelines if these controls are not at their disposal and as long as these controls do not work as intended (in the latter case we also recommend not to set the spacing manually). For developers who cannot use the HTMLB library, we provide the spacing rules in short. Please, refer to the SAP Portals HTMLB Guidelines for details and changed. Overview of the Spacing Rules Within iViews
q
Spacing between tray and content: r Offset between tray border/header and content: 10 pixels Spacing between grouped controls: r Spacing between primary and secondary groups: 10 pixels r Spacing between group controls with header and border: 10 pixels r Offset within groups, i.e. between group border and content: 5 pixels r Spacing within groups: 10 pixels between title and content, 10 pixels between content and buttons
file:///F|/resources/ma_guidelines_3/LAYOUT/layout.html (1 of 6) [03.12.02 10:15:24]

r Spacing between soft groups: 15 pixels horizontally, 30 pixels vertically Spacing between single controls: r
r r
Vertical spacing between single elements: 5 pixels for fields and dropdown list boxes, 8 pixels for checkboxes and radio buttons Horizontal spacing between multiple columns: 15 pixels Horizontal spacing between label and input element, width of label column: Width of widest label plus an offset of 8 to 22 pixels Spacing between selection element and label: 8 pixels for checkboxes and radio buttons
Starting Point for Placing Screen Elements Start adding elements to an iView in its upper left corner. Do not insert spaces or other spacing elements manually - the correct distance to the iView frame will be created automatically when the iView appears in the portal. What if there is no Content Yet? Sometimes, an iView does not yet contain any information, for example if a "My Events" iView has not yet been personalized. Instead of just presenting the empty iView, use the opportunity to provide some text that explains the iView and its functions. This way no space is wasted and the user is given hints on how to operate the iView.
Rules for Specific Controls

Simple Form Elements Simple form elements, such as fields, labels, selection elements (radio buttons and checkboxes), can be easily arranged in a tabular fashion using the grid layout. As grid layouts can be nested, one grid layout may be used for the global arrangement of the groups, while inner grid layouts care for the arrangement of the different field groups. See the SAP Portals HTMLB Guidelines for instructions on how to use the grid layout for forms. Tabstrips Tabstrips may be used in iViews, for example to display different views. However, restrict their use to cases where the views look very differently (e.g. tables of different width) and where other presentations would cause an unstable environment.
Figure 1: Tabstrip with table inside

Tabs may contain dynamic information so that users get a quick overview and are informed about important data, events or changes within the views. Nesting Rules
q q
Tabstrips may contain tables or group boxes. Tabstrips may not be nested! This is "information hiding."
For views and alternatives to tabstrips that consume less space, see Selecting Views. Group Boxes Group boxes may be used in iViews, but only if there are no other methods available for separating fields or information. We rather recommend considering using white space for grouping/separating elements. Alternatives to Group Boxes As alternatives to group boxes
q q
Separate groups by white space or lines Label groups with simple headings (possibly in combination with separators)
Group Box Types HTMLB offers several group box types with different looks. The type is determined by the attribute design. The primary (figure 2a, design = PRIMARYCOLOR) and secondary groups (figure 2b, design = SECONDARYCOLOR) allow to visualize groups through a simple, flat background color. Both are suitable for textual content. Controls with a white background color, such as input fields and checkboxes, stand out well on both group designs.
Figure 2a-b: Primary and secondary group Header group 1 (figure 2c, design = SECONDARYBOXCOLOR ) is best suited for forms; its light body background color lets white input fields stand out well. Header group 2 (figure 2d, design = SECONDARYBOX) has a white body background color, which makes it unsuitable for forms. Textual content and lists work best with this group style.
Figure 2c-d: Header group 1 and 2 The group box design (figure 2e, design = SAPCOLOR) has a transparent body background. Because of its border and header bar, it has a quite dominant appearance.
Figure 2e: Group box (with header and frame)

Header The group boxes have headers to describe their content (set it by using the attribute title). Phrase header titles either as object descriptions (e.g. "Address Data"), or as instructions (e.g. "Enter Address Data"). Nesting Rules
q
Do not nest group boxes. Exception: You may nest different group box types - but use this option with care. Group boxes should not contain: Tables Tabstrips r Trees Combination of Tray Types with Group Box Types: Currently, there are no specific rules as to which tray type should be combined with which group box type. Nevertheless, there does exist a rule of thumb: Always arrange group boxes from dark to light - if you have to use group boxes within trays, place lighter group boxes within darker trays.
r r
Tables Tables are "high-level" screen elements that present simple elements, such as fields, texts, or dropdown list boxes in a "grid" arrangement. For details on the use of tables, take a look at PortalDataViewer and Tables.
Figure 3: Table
Nesting Rules
q q
You can place tables inside tabstrips (see figure 1 above) Do not place tables inside group boxes.
Trees Trees are like tables "high level" screen elements. You should avoid using trees in iViews, especially trees with more than 2-3 levels. Consider using dropdown lists, the shuffler (filter) or tabstrips in combination with tables in order to select partial data sets. This leads to a far less complex user interface than large trees that have to be scrolled or paged through.
Figure 4: Tree
Nesting Rules
q q
You can place trees inside tabstrips Do not place trees inside group boxes.
Images, Graphics, Charts

Images, graphics, charts etc. are on the same level as tables or trees. Therefore, the same nesting rules apply. For details on the use of graphics and charts, see Graphics and Charts.
HTMLB Library - Overview
The Layout and Invisible Controls | The Visible Controls | Accessibility The HTMLB library is one, we present a short overview of the controls provided by this library. For detailed information, see the SAP Portals HTMLB Guidelines. We also shortly address accessibility issues with respect to using the HTMLB library.
The Layout and Invisible Controls

Invisible controls are needed to create the framework for an iView's content (not the tray framework that contains the iView). For example, the page control creates an HTML page framework for the iView that includes everything else; form elements, on the other hand, have to be included in a form control. Layout controls, such as the grid layout, help to arrange (visible) controls within an iView's content area. Technical (Framework) Controls The following controls are needed for technical reasons in order to create an iView:
q
Page, Document, Content, Form
Layout Controls The following controls can be used to create a layout for an iView.
q
Flow Layout, Grid Layout
While the flow layout is used for arranging elements one after the other (with wrapping), the grid layout creates a grid structure that is useful for designing forms. Layout controls can be nested to allow for more complex layouts. Note: For details see the SAP Portals HTMLB Guidelines.
The Visible Controls

The HTMLB library provides the following controls for use in the content area of an iView: Form Elements
q
Input Field, Label, Button
Selection
q
Radio Button (Group), Checkbox (Group), Dropdown List Box, List Box
Lists, Tables, Trees
file:///F|/resources/ma_guidelines_3/LAYOUT/htlmb.html (1 of 3) [03.12.02 10:15:32]

q
Item List, Table View, Tree View
Containers
q
Group Box, Tabstrip
Text and Links

q
Text View, Text Edit, Link, Breadcrumb
Other Elements
q
File Upload, Date Navigator, Chart, Image
See page HTMLB Controls - Visual Overview for a list of images showing the most of the HTMLB controls in alphabetical order (excluding the group "other elements"). See Chart Types - Overview for an overview of the chart types that are available im HTMLB. Note: For details see the SAP Portals HTMLB Guidelines.
Accessibility
Developers who use the HTMLB library as a technical basis for creating iViews can mostly rely on the accessibility services that are already provided by HTMLB. Note: For details see the SAP Portals HTMLB Guidelines. Descriptions The central HTMLB rendering engine already provides general descriptions for HTMLB controls, such as the type, the state, and on-screen text. Therefore, application developers only have to complement descriptions in case that users need more specific descriptions or instructions. The descriptions written by the application developers are added to the default descriptions that are provided by the central rendering mechanism. Examples
q q
A button description has to be extended if a button opens a new window. In general, a description has to be extended if a button introduces an interaction that cannot be recognized by a blind user.
Accessibility Flag Also note that the resulting description that is sent to the users depends on the state of the accessibility flag:
q q
If the accessibility flag is set, the default description is extended by the description that the application developer provided. If the flag is not set only the description that the application developer provided is sent to the user.
Keyboard Accessibility Keyboard access is handled by the HTMLB framework. All HTMLB controls that have to be accessed by the keyboard are automatically included in the tab chain (also called accessibility hierarchy).
Application developers using the HTMLB library cannot add elements to the tab chain themselves in order to make them keyboard accessible. As they cannot set HTML attributes directly, they do not have access to the tabIndex attribute of elements that determines, whether controls are included in the tab chain or not. Input Elements and Corresponding Labels Input elements, such as checkboxes, dropdown list boxes, input fields, radio buttons, and text edit controls need to be connected to a label, so that screen readers recognize the association of the label with the input element. Use the HTMLB label control for this purpose. The connection between a label and its corresponding input element also simplifies the interaction with the element when using the keyboard or mouse.
HTMLB Controls - Visual Overview
Overview List | Notes This page presents images of most of the controls contained in the HTMLB library. For detailed information with respect to usage guidelines and Control API, please refer to the SAP Portals HTMLB Guidelines. Note: For charts offered in HTMLB, see Chart Types - Overview.
Overview List
Below is a list of HTMLB controls and their look.
HTMLB Control Breadcrumb
Look
Button
file:///F|/resources/ma_guidelines_3/LAYOUT/htlmb_list.html (1 of 6) [03.12.02 10:15:34]
Checkbox
Dropdown List Box
Group
Primary and secondary group
Header group 1 and 2
Group box (with header and frame)
Input Field
Item List
Ordered and unordered item list
Label
Link
List Box
Radio Button
Table View
Tabstrip
Text Edit
Text View
Tree
Notes
The figures are given for reference only. They show the current state of the HTMLB controls (ERP 5.0) but changes to the controls may be introduced without further notice. Please, refer to the HTMLB documentation (PDK, Portal Development Kit) and the SAP Portals HTMLB Guidelines for details and the current state of the library.
Chart Types - Overview
Introduction | Types
Introduction
HTMLB provides an easy to use interface for implementing charts in iViews or Web applications (IACs). The following chart types are available:
q q q q q q
Area charts: standard, stacked, 3D, 3D stacked Bar charts (horizontal bars): standard, stacked, 3D, 3D stacked Column charts (vertical bars): standard, stacked, 3D, 3D stacked Line charts: standard, 3D Pie charts: standard, 3D, extruded, extruded 3D, split Special charts: pyramid, bitmap, trend
Below we present examples that demonstrate the look of these chart types. For details on the chart types see the SAP Portals HTMLB Guidelines. For information of the usage of the different chart types see Recommendations for Charts and Graphics in the SAP Design Guild. For information on the usage of charts in iViews see Graphics and Charts in section iView Interaction. Note: The actual charts may differ from the charts shown here, depending on the version of the HTMLB charts. Moreover, additional chart types may be available in the future.
Types
HTMLB charts types are selected using the attribute chartType. Below you find an overview of the available chart types and the respective values for attribute chartType.
Area Charts
Area chart (chartType = AREA)
3D Area chart (chartType = AREA_3D)
file:///F|/resources/ma_guidelines_3/LAYOUT/chart_types.html (1 of 4) [03.12.02 10:15:21]
Stacked area chart (chartType = AREA_STACKED)
Stacked 3D area chart (chartType = AREA_STACKED_3D)
Bar Charts
Bar chart (chartType = BARS)
3D bar chart (chartType = BARS_3D)
Stacked bar chart (chartType = BARS_STACKED)
Stacked 3D bar chart (chartType = BARS_STACKED_3D)
Column Charts
Column chart (chartType = COLUMNS)
3D column chart (chartType = COLUMNS_3D)
Stacked column chart (chartType = COLUMNS_STACKED)
Stacked 3D column chart (chartType = COLUMNS_STACKED_3D)
Line Charts
Line chart (chartType = LINES)
3D line chart (chartType = LINES_3D)
Pie Charts
3D pie chart (chartType = PIE_3D) Pie chart (chartType = PIE)
Extruded pie chart (chartType = PIE_EX) Extruded 3D pie chart (chartType = PIE_EX_3D)
Split pie chart (chartType = PIE_SPLIT)
Special Charts
Pyramid chart (chartType = PYRAMID) Bitmap chart (chartType = BITMAP) arbitrary bitmap
Trend chart (chartType = TREND)
Figure 1: Overview of the available chart types in HTMLB
Personalizing iViews
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 enduser tools); this activity is beyond the scope of these guidelines. General Rules
q
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
file:///F|/resources/ma_guidelines_3/LAYOUT/personalization.html (1 of 5) [03.12.02 10:14:55]
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:
q q
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:
q
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:
q
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 preselections 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)
q
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:
q
q q
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 subgroupings on this tab. Provide a short key sentence for any (sub)group of settings, explaining what the settings are intended to do.
Visual Design Aspects
Visual Design Aspects
Central CSS-based Rendering | Portal Themes and Style Editor This page discusses the visual aspects of iViews that are developed using the HTMLB library and the SAP portal framework. Especially, it discusses the central, CSS-based rendering mechanism, visual design options for application developers, portal themes, and the Style Editor tool for adaptations beyond the simple switching of themes.
Central CSS-based Rendering

Developers using the HTMLB library for creating iViews have only a very limited influence on the visual design and appearance of their iViews and the controls within. This is due to the fact that HTMLB uses a central rendering engine that handles all visual aspects of controls. The rendering engine takes a CSS-based approach, that is, most visual characteristics of the controls are defined through style sheet parameters that are beyond the access of application developers. Application developers create iViews using the Control API provided by HTMLB. The control's attributes allow developers to change the look and behavior of controls within a certain restricted range of options. For example, an attribute design may allow developers to choose the control type, such as a certain group box or button type. Further attributes may allow to set the width or height of controls, a stripe-pattern in table views etc. Application developers may change the look of certain controls by adding HTML code of their own. However, this approach is discouraged because it defies any changes of the overall visual design. As the visual design is defined in style sheets, the visual design may be changed by modifying or exchanging the respective style sheets. This is supported by the fact that the current rendering engine does not use any imagery at all - apart from a few icons for tray headers etc.
Portal Themes and Style Editor

For the SAP portal framework, several ready-to-use portal designs have been defined, including a high-constrast design for visually impaired users. A new portal design can easily be created by copying and then adapting one of the preconfigured designs. This can be done using the Style Editor, a tool provided by the portal framework. In addition, the Style Editor allows to change numerous parameters for each control without requiring system administrators to do any manual changes to the style sheets. For more information on the Style Editor and the Style Editor parameters for each HTMLB control, please consult the SAP Portals HTMLB Guidelines. For more information on the Style Editor and the Style Editor parameters for each HTMLB control, please consult the SAP Portals HTMLB Guidelines.
file:///F|/resources/ma_guidelines_3/LAYOUT/visual.html (1 of 2) [03.12.02 10:15:35]
Complexity
Complexity
Introduction | Screen Elements to Avoid or to Use with Care | Functional Complexity
Introduction
iViews should be simple and reveal their information contents instantly to their users. If an iView tends to become complex, consider changing it into a Web application (IAC) - it is no longer a "real" iView. See also Saving Space and Reducing Complexity for practical hints.
Screen Elements to Avoid or to Use with Care

Avoiding complexity starts with making the screen look as simple and "clean" as possible. Therefore, avoid the following more complex screen elements or at least use them with care. Trees Trees contain complex information and are cumbersome to use. If possible, trees should be not be used and other alternatives considered. Trees with hierarchies more than twqo to three levels deep should be avoided altogether. Note that if the number of tree elements is small - which should be the case in iViews - hierarchies can be flattened to lists, and the items may follow some other ordering like by alphabet or relevance Tabstrips Tabstrips for selecting views should only be used if other alternatives lead to an unstable interface that might confuse users: They appear rather massive, and they take a lot of screen real estate. Furthermore tabstrips should only be used for tasks without a prescribed order of steps as they communicate freedom of choice of interaction sequence. Group Boxes Group boxes should only be used if other ways of separating information or field groups do not suffice. Group boxes look similar to the tray container and may clutter the interface visually. Preferably use white space or vertical dividing lines to group elements, relying on the Gestalt laws. Do not nest group boxes; groups within groups boxes should be separated by lines or white space (see Layout). Tables Tables are relatively complex screen elements that lead developers to squeezing in lots of information. Keep tables small with respect to the number of columns and rows!
file:///F|/resources/ma_guidelines_3/interaction/complexity.html (1 of 2) [03.12.02 10:15:07]
Complexity
For long tables consider effective filtering methods like the shuffler: These tools effect that only a few rows are displayed and that users need not scroll, or need to scroll only a little bit. Consider alternative presentations like charts or graphs as well - they may reveal relevant information faster. Do not include more than one table in an iView. Exception: Comparisons between data or assignment of data to sets (double table design).
Functional Complexity
There are iViews that offer a lot of functionality; but actually these are "ordinary" applications packaged as iViews. Such applications are not iViews. Typically, iViews are not full-fledged applications. They should only have basic functionality, which can be accomplished in a few steps and without any instructions. If your application tries to accomplish more than this, make it an IAC or an R/3 application. The following hints help you to reduce or constrain an iView's functionality. One Application - One Purpose This simple rule is valid for any application, but it should be mandatory for iViews. iViews which try to serve different purposes are inherently complex and thus more difficult to understand. Thus they are not real iViews. Try to divide up the functionality into several iViews serving one purpose each. Avoid Optional Functionality iViews should also offer the necessary functionality only. Reserve optional functionality to larger and more complex applications like IACs. Do not Offer Redundant Access Mechanisms to Functionality In usual applications there are often quite a few access mechanisms to an application's functionality: menus, pushbuttons, function keys, keyboard shortcuts, accelerator keys, etc. For iViews just use the basic mechanisms like pushbuttons and keyboard shortcuts.
file:///F|/resources/ma_guidelines_3/interaction/complexity.html (2 of 2) [03.12.02 10:15:07]
Saving Space and Reducing Complexity
Why Mini? | How to Make an iView "Mini" and Less Complex
Why "Mini"?
An iView is "Mini" An iView should indeed be "mini", that is, as small as possible. Apart from size this requirement has implications for functionality, screen design and effect on other iViews as well. Being "Mini" has positive side effects:
q
Fewer screen elements and fewer decorative elements reduce the complexity of the screen and help users to find relevant information faster - provided that the iView indeed offers relevant information. Fewer screen elements allow the iView to be smaller and thus leave more room for other iViews.
See How to Make iViews "Mini" and Less Complex for tips on saving space below. Don't Be "Selfish" - Your iView Is Not Alone iViews that occupy half or more of the portal page do not deserve the attribute "mini." iViews have to be developed with the requirement in mind that they reside together with other iViews on a portal page. An iView that takes over most of a portal page shows "selfish" behavior - it does not take into account that users need and want to see other information as well.
How to Make iViews "Mini" and Less Complex

Here are some hints on how you can reduce screen complexity and save screen space. Reduce Functionality iViews should only contain basic functionality that can be evoked with quite a few pushbuttons. Reduce Number of Screen Elements Reduce the number of fields and table columns to the absolute necessary. Also use mechanism like filters (shuffler) to reduce the number of table rows (see Reduce Data Complexity below). Reduce Data Complexity
q
q q
Reduce the number of fields and table elements (columns, rows) Example: Use filters (shuffler) to reduce the number of table rows Reduce hierarchies to 2-3 levels. This makes even more sense if the number of tree elements is reduced, e.g. by filters Use alternative presentations like charts or graphics (see below) instead of tables
Avoid Unnecessary Framing of Screen Elements

file:///F|/resources/ma_guidelines_3/interaction/space.html (1 of 3) [03.12.02 10:14:50]
Avoid group boxes:

q q q q
Use headers or text labels to describe field groups. Do not put tables or tabstrips inside group boxes. Do not nest group boxes. Use white space or a vertical separator line instead to group items.
Avoid tabstrips:
q
Use lists of hypertext links, dropdown list boxes or buttons instead for selecting views (for more information see Selecting Views)
Avoid trees:
q
Use tables in conjunction with mechanisms for view selection (dropdown list box, tabstrip) or filtering (shuffler).
More Ways to Save Space...

q q q
Put labels above entry fields. Concatenate labels with read-only fields to one label or omit the label if the meaning of the field is evident. Avoid unnecessary white space (but use it wisely for item grouping - rely on the Law of Proximity)
Note: When rearranging fields take care that accessibility issues are observed. Example
Figure 1: Labels above fields, concatenated labels and fields or no labels at all can help to save screen space.
Use Graphics instead of Texts and Tables
This suggestion builds on human's ability to interpret images faster than text; graphics also may save space compared to equivalent text information, if used properly. If Using Graphics Show the Essential Information Only Graphics may show irrelevant information, may show too much detail, or may be too large.
Too Large Because of Irrelevant Information
Graphics may be too large, because they show too much of the surrounding or context of the relevant information. Example: If you want to show the sales in region Europe, do not show a world map; if sales in Germany are of interest, do not show a map of Europe; if sales in Bavaria are relevant, do not show a map of Germany. Example: Photos, drawings or diagrams can often be cropped to a section without losing information; as a positive side effect, the section shown can have a larger magnification, thus showing more details.
Too Large Because of Too Much Detail
A drawing, diagram or photo needs a certain size to show details. Often, however, the details are irrelevant, and a smaller, more schematic graphic would fulfill the purpose much better. Example: Use simple schematic drawings instead of photos or detailed graphics; e.g. a map of Germany can be very crude, if the purpose of the map is only to indicate "Germany".
Simply Too Large...
Often images are simply too large, because nobody cares about image size...
Navigation
Navigation (Preliminary)
Introduction | Types of Navigation | Guidelines for Inside Navigation
Introduction
As stated before, iViews should be as simple as possible. They usually provide information, either as a complete source, but more often as a preview to more and enhanced content. On the other hand, iViews can also serve as small tools for a limited scope of functions, such as a small currency calculator. An iView typically should neither allow nor need navigation. The following exceptions should be used with care: Changing views inside the iView without losing the context (tabstrip, view selection via dropdown lists, shuffler etc.). Scrolling between pages where the context is kept and where the navigation fits a metaphor like a notebook, a book, etc. Change between a search form and the search result (hit list); the same applies to iViews that adhere to a similar interaction paradigm (before - after). Movements to modal dialogs for secondary information or for value selection (value help).
q q q
Types of Navigation
Considering the two main functions of iViews, there are three basic navigation styles for an iView:
q
No navigation at all: The iView essentially remains constant, only the content changes. True for iViews such as a calculator, where the users' actions yield a changing content, but the fields themselves remain the same. Inside navigation: The iView allows the user to access different views in the iView's content area. Commonly, tabstrips or similar controls are used to switch from one view to another. Outside navigation: If an iView is a preview to a more complex transaction or a Web application (IAC), links inside the iView can be used to switch to this larger transaction.
As a general rule of thumb, the complexity of an iView should be kept to a minimum. It should provide information at a glance and do without complex inside navigation. If inside navigation is a necessity then consult the following guidelines.
Guidelines for Inside Navigation

Sometimes an iView needs to incorporate a set of different views. In this case, it is important to always keep a stable "framework" while exchanging the content. "Framework" means that an iView uses a control, such as a tabstrip, to switch between views, and this tabstrip always remains a stable and unchanged component. This enhances perceived stability. Note: Never exchange the whole content of an iView, forcing the user to "go back" to the original content. Using Navigation Controls
file:///F|/resources/ma_guidelines_3/interaction/navigation.html (1 of 2) [03.12.02 10:15:36]
Navigation
Often there are different options for switching views available. Some of these include:
q q q
Tabstrips Link lists Dropdown list boxes
Each of these alternatives has certain advantages and some tradeoffs. Here are some rules of thumb: A tabstrip has the advantage of instantly making all possible choices visible to the user (which is only true as long as all tabs fit into the width of the tabstrip). The user is provided with a table context which makes navigation quite easy and straightforward. A drawback, however, is that tabstrips have a quite "massive" appearance, thus adding some screen clutter to an iView which should be as simple and light as possible. Also, depending on the width of an iView, the number of tabs that fit into the iView can be quite limited, forcing you to stack the tabs (which is not recommended). A link list works mostly in the same way as the tabstrip. It provides an overview of the choices and has a simple interaction model. Since links are separate controls, the layout is not limited to a single row as with the tabstrip: If there are more choices than fit into one row, these controls could be laid out in two or more rows (although it is very questionable if more than one row makes sense in an iView - in case you find yourself with two or more rows of links, think about whether your application still fulfills the iView standards. Also see Saving Space and Reducing Complexity). The dropdown list box employs a different interaction model. It only display the current choice (view) while all other views are displayed on demand in a single list. The selection of a new view is either triggered directly by selecting an item, or by adding a Go button to the right of the list. A major drawback of this solution is the fact that the user sees only one entry at a time. This increases the effort for navigating through the choices. On the other hand, dropdown list boxes are the least limited design option with respect to horizontal spacing and the number of choices. This alternative can be recommended in situations where:
q q q
The number of views is larger or The number of entries in the list (views) can vary or The text of each of the entries can be long or undetermined
Note: See a more detailed discussion of views and switching between views in Selecting Views.
file:///F|/resources/ma_guidelines_3/interaction/navigation.html (2 of 2) [03.12.02 10:15:36]
Scrolling
Scrolling
Scrolling Rules | Applications with Different Amounts of Data
Scrolling Rules
The following table summarizes the scrolling rules for iViews and tables within iViews:
Vertical Scrolling iViews iViews should not scroll vertically Tables Tables may currently only be scrolled pagewise using scroll buttons Set the size of tables so that they fit inside the iView. So, the iView itself need not be scrolled in order to see tabular information.
Horizontal Scrolling iViews do not scroll horizontally There is no horizontal scrolling in iView tables
Table 1: Scrolling rules for iViews and tables within iViews
Applications with Different Amounts of Data

As stated above, avoid horizontal as well as vertical scrolling of the iView content. Therefore, take care that the iView content really fits within the defined size. Views in General What can be done if an iView has to display different amounts of data and where some views might not fit the given iView size? Layouts with several collapsible elements one below the other seem to be a solution to this problem, but should not be used, because they change the size of the iView content and may not fit this size if all elements are expanded. As an alternative you may use a link list (see views), a shuffler (dropdown list box), or a tabstrip (in personalization dialogs; see views) to display different views. Note, however, that these design solutions only show one view at a time. Tables For tables that may contain different numbers of items a problem arises if the number of items is smaller than the number of table rows. In this case, do not create a smaller table with only as many rows as items are present. Fill the table with empty lines instead, so that the overall table size remains stable over different views.
file:///F|/resources/ma_guidelines_3/interaction/scrolling.html (1 of 2) [03.12.02 10:15:36]
Buttons
Buttons
General Statements on Buttons and Links | Placement of Buttons | Standard Buttons vs. Emphasized Buttons | Go Button in Shuffler and Data Selections
General Statements on Buttons and Links

Use buttons only for few and very important functions in an iView. As buttons are visually dominant and rows of buttons hardly appear attractive, links should be favored to buttons. Links can also be used for calling functions - they are not restricted to navigational purposes. They must not be used for the final action in an iView; because of their optical weight and their visual dominance, buttons qualify for this purpose. See Links vs. Buttons on page Texts, Lists, Links for a more detailed discussion of using links vs. buttons). The word(s) on a button or a link begin with a capital letter (exception: when a link is embedded within normal text). Pressing the Enter key activates the default function (mostly, but not necessarily, identical to the emphasized button's function). Use three dots or the ellipsis character ("...") on buttons, but not on links, to indicate that the command needs further information to execute. Usually the user is presented a dialog to fill in the missing information. Choose the button's function description carefully; try to be as explicit as possible (while keeping in mind the limited space inside an iView). For complex interactions, use verb-noun combinations, e.g. "Search Database". If the context is clear, i.e. if the action can only be applied to one object, it is sufficient to use a single verb as the button's label ("Search"). For shufflers and comparable elements, you can also use a simple "Go" (see below).
Placement of Buttons
file:///F|/resources/ma_guidelines_3/interaction/buttons.html (1 of 5) [03.12.02 10:15:18]
Buttons
Figure 1: Placement of buttons in an iView; iView-related buttons can be placed in the same row as the graphic-related buttons, if space is sparse. There is only one emphasized button in an iView
Buttons Related to Objects Place buttons or links related to objects like fields, field groups dropdown lists etc. next to the object and to the right of them. Example: The Go button of the shuffler is located right to the filter elements. Buttons for Tables, Charts and Graphics (Complex Objects) Place buttons or links related to tables, charts, or graphics, that is complex objects, left aligned below the table. Place the default button (emphasized) to the left, if there is one. Buttons Related to the iView as a Whole Place buttons related to the iView as a whole to the bottom left of the iView. If there are object-related (table-related or chart/graphics-related) buttons, you may place these buttons into the same row. Use the following order in this case:
q q q
iView-related buttons, separating space, object-related buttons
Buttons
See figure 1 for this a demonstration of this solution. Reasoning: Placing object-related and iView-related buttons into one row is allowed because vertical space is at a premium in iViews. Emphasized Button If the emphasized button (see below) is a member of a button group, it is the leftmost button in this group (not shown).
Standard Buttons vs. Emphasized Buttons

By default iViews use "standard" pushbuttons. In addition, there is an "emphasized" button available, which is visually more dominant.
Figure 2: Standard button (bottom) vs. emphasized button (top)

An emphasized button indicates an action that is performed with high probability, is of high importance, or has significant (yet nondestructive) consequences.
q q q
It is the emphasized button through which the central action in an iView is activated.
Buttons
The concept of an emphasized button has been developed for Web applications (IACs). For iViews the following changes or restrictions have been put forward: Emphasized buttons should be used only sparsely. At maximum one button in an iView should be emphasized. If there are only subordinate functions (table functions, preferences) in an iView, no button should be emphasized. If there is only one button in an iView, it should be emphasized, if the corresponding action fulfills the above-mentioned criteria, that is, if the action is of high importance or has significant consequences. Pressing the Enter key should activate the emphasized button's function.
q q q q
Example: The Go button in a shuffler has to be emphasized if it is important, even if it is the only button in an iView. Do not use emphasized buttons for the following functions: Personalize (this function is offered in the tray title) Refresh
q q
Button in Shuffler and Data Selections

The button in shufflers for starting the data filtering process is labeled Go (Starten in German).
Buttons
Figure 3: The button in the shuffler is labeled Go
Fields
Fields
Labels and Help Texts | Read-Only Fields | Input Fields | Alignment | Saving Space
Labels and Help Texts

Please note: The iView Guidelines differ from the IAC Guidelines with respect to the usage of field labels and inspection texts. In iViews inspection texts are not used; use help texts instead. Labels are simple text elements that can be used for descriptive texts within an iView. Labels can wrap and spread over multiple lines. Field labels are labels describing read-only fields, input/output fields or selection elements like dropdown list boxes. Field labels in front of input fields are underlined to indicate the connection between label and field; if the field labels have to be set above the input field (e.g. in narrow iViews), use a smaller font and don't underline the label. The field labels should be as descriptive as possible; e.g. in an iView on searching in a search engine, "Search in" would be a nice label; if a category has to be chosen "Select category" is rather descriptive.
Help texts are special labels that are set behind or, if space is limited, below and left aligned with read-only or input/output fields; they give advice (e.g. examples) on what kind of data to enter into a field, if necessary. Please use only two or three words as possible examples.
Small field labels and help texts can be combined as well:
Sometimes - mainly for seldomly used applications - it may be useful to provide an enriched field label, using a short sentence, thus giving easy access to the functionality:
Note: See Text, Lists, Links for predefined text styles for labels and headers. Accessibility Ensure that screen readers will identify the connection between a field and its corresponding label. When using the HTMLB library use the label control for labels. When using plain HTML use the HTML label element for labels (see the code example below). The connection between a label and the corresponding field (or other screen element) is established with the "for" statement.
file:///F|/resources/ma_guidelines_3/interaction/fields.html (1 of 5) [03.12.02 10:15:38]
Fields
Example
<label for="fd1" title="Input field Search" accesskey="S"> <u>S</u>earch</label> <input type="text" name="textfield1" id="fd1" title="Input field Search">
Code 1: HTML code for a simple input field with shortcut for the label
Read-Only Fields
Read-only fields are fields where data have been entered either by the user or the system, but which in the current context cannot be changed. Typically read-only fields describe attributes of objects. An inspection text behind the field may explain the meaning of the field value.
Input Fields
Input fields come in several variants:
q q q q
Input/Output Field: Fields where users can enter or edit data. Required Field: Users cannot leave these fields empty; they are required to enter a value. Field with Dropdown List Box: Here users can select or change predefined values; they cannot enter values manually. Dropdown List Box with Button: This is an extension of the dropdown list box with label; an event is fired as soon as a new value is being selected; in this case no button is needed. Alternatively, an additional button initiates an action after a value has been selected; depending on the context, it is set to "emphasized" or not. Input Field with Button: This is a combination of an input field, usually with a label, and a pushbutton. The pushbutton is used to initiate an action after a value has been supplied; depending on the context (i.e. if it is important or not), the button is set to "emphasized" or not. Example: A search field can be implemented as an input field with "emphasized" "go" button. There is more information on pushbuttons and the difference between emphasized vs. non-emphasized buttons.
Examples Input/Output Field
Required Field
Fields
Field with Dropdown List Box
Input Field with Button
Alignment
Basically the rules for alignment and arrangement of fields apply as they are laid down in the SAP Style Guide. We summarize: Fields are triples consisting of
q q q
a label, a read-only field, input/output field or dropdown list box, and an optional help text.
Labels and fields are left-justified and aligned below each other; help texts should be put behind the input field or, if space is insufficient, directly underneath the input field, left aligned with its left border. If there is no space to put the label to the left of the input field, put it above (see above). Text (labels without corresponding fields) is usually left-aligned. There are four possibilies of arranging field labels and help texts in relation to the input field:
help text
Orientation
vertical (behind)
horizontal (underneath)
vertical (in front)
Standard (wide): field label + takes only one line - is rather wide
can be used, but: - takes two lines - is of medium width
Fields
horizontal (above)
Standard (narrow): not recommended - rather take the upper right one. (If you have got the space to write the help text behind the input field, it's preferable to put the label in front and the help text underneath - the label is more important and should be more prominent.) + is rather narrow - takes three lines
Figure 1: Possible combinations of label and help text position in relation to the input field.
There can be cases when "primary" and "secondary" field labels can be used, the primary ("valid thru" in the example below) indicating the meaning of the group of fields, the secondary ("Month" and "Year") giving information on what to enter into the fields directly associated.
Saving Space
If space matters,
q q
place the labels above the fields and omit the help texts (labels put above fields are set in small type and are not underlined) combine labels with read-only fields to one label or omit the label if the meaning of the field is evident. Example: "Phone: +496227-12345678" Example: "Germany"
Fields
Figure 2: Saving space with field names and read-only fields.
Texts, Links, Lists
Texts, Lists, Links
Using Text in iViews | Lists | Links
Using Text in iViews

iViews can contain textual information (see example). Use the HTMLB text view control to present text in different styles. For details on the text view control see the SAP Portals HTMLB Guidelines. Note: The text View control must not be used to create a label for input fields; use the HTMLB label control instead. Use The text in the control is restricted to a single font, size and style unless manually set with HTML commands. The text size can be set using different styles (see Text Styles below) Also note that if you occupy a certain area on the screen for a text view control you should reserve enough space for the translation to other languages. Text in other languages may use up to 30% more space than needed in English. Text Styles The text view control offers several text styles, which are set by the attribute design (values STANDARD, EMPHASIZED, REFERENCE, LEGEND, HEADER1, HEADER2, HEADER3).
Text Style
Use used to display body text used to display emphasized text e.g. phrases, single terms; not to be used for complete text areas; text size "Standard" Style for Text Used as a Reference; text size "Standard" used to display a legend or small-size help text; text size -2 in comparison to "Standard" used to display a headline or page title; text size +4 in comparison to "Standard"
used to display a page subtitle; text size +2 used to display a subtitle; text size "Standard"
Table 1: Text styles offered for the text view control and their use
file:///F|/resources/ma_guidelines_3/interaction/links.html (1 of 4) [03.12.02 10:15:06]
Texts, Links, Lists
Lists
Lists are an alternative to the PortalDataViewer or other types of tables (e.g. the HTMLB table view). Use lists whenever you want to present a list of items in an unobtrusive way, where reading is the primary usage and where there is - apart from hyperlinks - no interaction on the list elements. Note: Use the HTMLB item list control for implementing lists if possible; there is an ordered and an unordered item list available. See the SAP Portals HTMLB Guidelines for details. Lists have the following characteristics:
q q q q
q q
List items are read-only. List items may contain links. Lists do not scroll. Therefore make sure that all list items fit the iView! Lists consist of one column only; for multiple columns include the lists in an HTML table with one row and several columns (23). Lists may be ordered (numbers) or unordered (bullets). Lists may be nested; do not use more than 2-3 levels!
Examples Below you find an example for an ordered and an unordered list implemented as HTMLB controls. Ordered List Unordered List
Figure 2: Ordered (left) and unordered list (right)
Links
A link (hyperlink, hypertext link) is a word, text phrase, image, image section, or icon that transfers the user to a different page or
Texts, Links, Lists
section on the same page. Links point to one specific target (there exist linking services on the Web, which provide users with a selection of targets). Note: Use the HTMLB link control for implementing links if possible. For details see the SAP Portals HTMLB Guidelines. Visual Design of Links Currently, links are not underlined, but show a hovering effect with underlining when the mouse is moved over the link. In the future, different link types may be offered, such with underlined text and such, where text is not underlined. Reasoning: Within longer text passages, links are hard to find if they are not underlined. Link lists, on the other hand are hard to read if all links are underlined. In addition, users should be able to override the link settings according to their personal preferences and needs. Long Text Links Format only a characteristic part of the text passage as link which clearly describes the target of the link; if one word suffices, use just one word. Avoid underlining more than one line. Link Types Although there is only one link type from a technical point of view, we must make a distinction between the various kinds of links. This helps to establish usage rules for links and to make a distinction between buttons and links. Based on what purpose the links serve, we can establish five different types of content area links: view switch, toggle, drill-down, function, and navigation.
q
View Switch Links View switch links are similar in function to toggle links, but are different in that they are always visible. The view switch links are an alternative to the tabstrip control (see Selecting Views for details). This type of link is similar to the navigation link. As opposed to navigation links, view switch links all refer to the same context and must be persistent in all the views. The currently selected view should not be presented as a link, but as bold text. View switch links should be separated from one another by a vertical line ("|"). Toggle Links Toggle links are used when there are two alternative views of the current data. Toggle links are always pairs of links, but only one is visible at a time. Drill-Down Links A drill-down link allows a user to see more detailed or specific information. For example, in the overview of an address book, the contact names are drill-down links that allow the user to access details on that person. Function Links A function link allows the user to carry out an action. Although in general buttons should be reserved for functions (see Links vs. Buttons for more information), there may be cases where a link would be preferable or where the distinction between a function and a link to another view might be very blurry. Navigation Links Many times, there will be navigation within an iView or application which is independent of the main navigation of the portal. End users might not even perceive these links as "navigation" per se. Navigation links allow users to move backwards or forwards though a data set or process.
Links vs. Buttons In general, use links to indicate navigation to another HTML page or to a different view of the current information as well as to link to further or more detailed information. Links commonly appear within the context of the application (within trees, tables or text).
Texts, Links, Lists
Use buttons to indicate that a function can be carried out (save, print, close, delete, etc.) or that a process can be started (subscribe, etc.). Buttons generally appear at the bottom left of a grouped area to indicate a function that can either be performed on selected items (if checkboxes appear as well) or that apply to the whole screen (see Buttons for details on button placement).
Figure 3: Example of an iView where links and buttons are both used
PortalDataViewer, HTMLB Table View, and Tables
When to Use the PortalDataViewer and the HTMLB Table View | Building Blocks and Content Distribution | Paging in Tables | Sorting Columns | Links Inside a Table | Displaying Status Information | Implementing Tables This chapter deals essentially with the PortalDataViewer (the former PortalALV) and the ways of using it in the best possible way. However, the PortalDataViewer is only one specific instance of a table. Consequently, many of the issues discussed here are also valid for non-ALV based tables. With respect to presentation, the PortalDataViewer is based on the HTMLB table view. The table view can also be used in iViews. However, it does not offer all the services provided by the PortalDataViewer.
When to Use the PortalDataViewer and the HTMLB Table View

The PortalDataViewer The PortalDataViewer (PDV) is a tool, which can be used to present tabular data in in the SAP Enterprise Portal 5.0. Main focus has been set to the presentation of data coming from SAP backend systems. The PDV offers generic functionality for user interaction and reduces programming efforts for iViews significantly. It is even possible to create iViews without any programming just by providing the appropriate properties in a profile (see Implementing the PortalDataViewer). Do not use the PortalDataViewer if
q
q q
There are only a few sets of data which could easily be displayed in a textual form (e.g. an inbox overview like: three new work items and two unread mails) or as a simple list (see Texts, Links, Lists) Values have to be sorted, filtered or processed using complex criteria or methods There are alternative forms of presentation that are more suitable for the content (e.g. displaying numbers as graphics or charts)
Although the PortalDataViewer can be used for many purposes and it is definitely convenient to "include PortalDataViewer" and get a complete iView for free, there is often a better design solution available. The HTMLB Table View The HTMLB table view can also be used for displaying tabular data. It has the same look as the PDV (apart from the icon on the top right) but does not offer the respective services. It is useful for simpler applications that do not need PDV's services. See the SAP Portals HTMLB Guidelines for details on the table view.
Building Blocks and Content Distribution

Both, the PortalDataViewer (figure 1) and the HTMLB table view (figure 2) consist of four different areas in which information can be displayed (the HTMLB table view does not have the icon at the right edge of the title bar):
q q q q
The blue table header The column headers The actual "table" or data area A status line for displaying scroll buttons (if applicable)
file:///F|/resources/ma_guidelines_3/interaction/portalalv.html (1 of 6) [03.12.02 10:15:31]
Figure 1: A PortalDataViewer
Figure 2: An HTMLB table view

Each of these areas serves a different purpose. While the usage of column headers and the data area is quite clear, it requires a bit more explanation to specify which kind of information should be displayed in the table header or in the status line. The title area can be used for A description of the table content if the table is not the only "grouping" element inside the iView. Dynamic content like the number of retrieved results
q q
The title should not be used

q q
If the table is the major element of an iView and the title would essentially repeat the title of the iView itself. If the title contains no text and would be an empty element
If there is no reasonable title for a table, omit the title element. The status line of the table is used for the paging buttons plus a display of the current page or data set (this has be defined in detail).
Paging in Tables
The PortalDataViewer as well as the HTMLB table view provide currently only one approach for scrolling through lists of data. The current solution "pages" through a list, i.e. a new "page" of data is displayed by clicking one of the buttons in the status-line of a table (see figure 3).
Figure 3: Table with paging buttons
Sorting, Calculating Totals, and even more

The user can personalize the table layout by:

q q q q q q
changing the order of the columns hiding some columns sorting by one or more fields calculating totals, averages, maxima, minima or setting a counter calculating subtotals for the sort fields choosing a background design or the number of displayed rows per page
The starting point is the "standard" layout defined by the application. However, if this possibility is not desired (from the application point of view), it can be switched off (even parts of the settings, e.g. only hiding of columns might be suppressed). These personalization settings are be persisted in the PCD (can be disabled).
Links Inside a Table

If links are used inside a table to jump to different locations (e.g. a related IAC), make sure to provide only one jump target. It may be technically possible to provide a different link with a different target for every column, but iViews should be kept as simple and concise as possible. If you provide a link inside a table, make sure there is only one column that contains this link. Links with the same location in different columns should be avoided in the same way as links with multiple locations. The link should always be represented as a text link. Having a link location on an icon always results in a large probability of not finding the links at all. Icons inside the table are status icons and should not be used for any kind of interaction.
Displaying Status Information

When using status icons in a table, make sure the status is always displayed in the first column (see Figure 4). This is especially important if the status of an element is the primary information in a table (e.g. critical process steps) and the user should be able to quickly perceive the different "groups" of statuses. An exception to this rule are items, which may contain more than one status, and the status overview merely is an additional information and not the primary "sort" criterion. Make sure the title for a status contains a title that describes the meaning of the status icons (e.g. "Read" or "Project Status"). Chapter Icons and Status Information provides detailed information on this topic. You can find a list of status icons in the SAP Reference Lists in the SAP Design Guild.
Figure 4: A table displaying status information in the first column
Implementing Tables
Implementing the PortalDataViewer The main part of the PDV is implemented as a portal service. This service itself uses other services of the portal like HTMLB or JCO. The Portal Content Directory (PCD) serves as the persistence layer for the PDV properties, especially for the PDV personalization data. The PDV service has two kinds of "clients": specific application iViews and the generic PDV iView. The generic PDV iView covers the "simple" cases, where parameters are sufficient to define the access to a data source. By this, no programming on the middleware is necessary. However, a data source might be a complex program in a SAP system. Application iViews can use the PDV as a programming API. By this, the application inherits the PDV functionality and can focus on application specific programming (additional interactions and business logic). When should I use Portal Data Viewer?
q q q
Is a table the main part of your iView (either only a table or a table together with other elements)? Do you want to use HTMLB for Java in your iView? Do you want to offer interactive functionality (sorting, summing, configuration, and personalization of the table layout) for this table?
If your answer to these questions is "yes", your iView may be a candidate for a Portal Data Viewer (PDV) application. Especially, if you are dealing with table content coming from SAP systems, the PDV maybe the tool of your choice.
Implementing the HTMLB Table View For details on implementing tables using the HTMLB table view see the SAP Portals HTMLB Guidelines.
Graphics and Charts
Graphics and Charts
Using Graphics - When and How | Using Charts - Overview | Advanced Charts | Chart vs. Table | Chart and Table Alternatively While most developers are experienced with designing forms, the correct and efficient use of graphics and charts is less well known.
Using Graphics - When and How

Here, we present some tips and tricks for using graphics. When
q
Use graphics instead of text when they easily and effectively convey information. Example: A floor plan is more efficient for describing the structure of a building than a text description. Use graphics when they need less space than equivalent textual information. Example: The description of a procedure may be much longer than an equivalent diagram. Use graphics for decoration or fun, but only if it is appropriate for an application. Do not decorate applications just because you think it looks nice.
How
q q
Align graphics so that their main contents points towards the text, not away from it. Crop graphics to the relevant section; make them as small as possible and avoid irrelevant and distracting elements. Example: Do not show a US map if you want to illustrate data in Michigan - use a Michigan map instead. Use high quality graphics. Example: Do not draw graphics by yourself, involve graphic designers. Care for the corrects format of the graphics. Example: Use JPEG for photos, images with many colors and gradations; use GIF for diagrams, images with text and/or straight lines and images with (less than) 256 colors. Typically screen dumps work better in GIF format.
For more information on graphic iViews see Graphic iViews; for additional background information see the Recommendations for Charts and Graphics in the SAP Design Guild.
Using Charts - Overview

Charts present numerical relations in an "analog" fashion. For example, absolute numbers can be represented as bars of different lengths, while percentages are typically represented as different angles. A variety of charts types has been developed that serve different purposes and exemplify different types of relations. The following table explains the chart types that are available in HTMLB and their usage.
Chart Type
Typical Applications
Variants, Remarks
file:///F|/resources/ma_guidelines_3/interaction/graphics.html (1 of 4) [03.12.02 10:15:04]
Graphics and Charts
Area
Cumulated totals (numbers or percentages) over time
Percentage, Cumulative
Column/Bar
Observations over time or under different conditions; data sets must be small
Vertical (columns), horizontal (bars); multiple columns/bars, columns/bars centered at zero
Segmented Column/Bar Proportional relationships over time
May be scaled to 100%
Line, Curve
Trends, functional relations
Data point connected by lines or higher order curves
Pie
Proportional relationships at a point in time
Segments may be pulled out of the the pie for emphasis (exploded pie chart)
Table 1: Chart types and their applications and variants

Note: There are chart types that may better fit the intended purpose than the available ones. For the design of chart iViews see Chart iViews. For more information of the uses, advantages and disadvantages of different diagram types see Recommendations for Charts and Graphics in the SAP Design Guild.
Advanced Charts
Above we described basic chart types. Charts can be made even more informative if used in new ways or combinations. For example, you can combine a map with pie charts or bar charts to present the geographical distribution of certain variables.
Graphics and Charts
Figure 1: A geo chart showing the distribution of two variables in Northern Germany
Note: Often these charts have to be "handcrafted" and can be used as static images only.
Chart vs. Table

Charts should be preferred to tables whenever it is important for the users to quickly and easily recognize characteristics of data. Scanning data in tables takes longer, and important data are easily overlooked in tables. Therefore it is also important not to use chart types that are fancy, but that distort relations between data, like 3D charts. Such charts should be used with care only, and the data should be accompanied by numbers in order to avoid misinterpretations. This is especially important if time pressure or high risk are involved.
Chart and Table Alternatively

In cases where charts help to easily grasp the essence of the data but where also exact values are needed, you may consider to provide both a chart view and a table view. Start with the chart view and offer a button (below the chart or table) for toggling between the views:
Graphics and Charts
Figure 2: The chart view
Figure 3: The alternative table view (with additional status column)

Note: Typically, status columns are arranged to the left of the table; this example deviates from this rule in order to keep the layout stable. In other cases there will be less similarity between the table view and the chart view (here a bar chart table).
Selecting Views
Selecting Views
Why Views? | Table Views and Form-Like Views | Choosing Controls for Switching Views | Views in Tabstrips | Dropdown List Box for View Selection | Link List for View Selection
Why Views?
If the amount of data is large, the data have to be split into several groups, called views. A view presents a meaningful (sub)set of data. For iViews collecting data into views is even more important than for regular applications, because space is at a premium and splitting has to be used with a smaller amount of data than usual.
Table Views and Form-Like Views

Large data sets are typically displayed as tables or trees (to be avoided in iViews), while singular data are displayed as fields which may be clustered into meaningful fields groups. Tables: Scrolling vs. Views and Filters The same data might either be put into a long table or tree that has to be scrolled or into a set of views. While scrolling provides a more sequential access, views lead to a more random-like access (of course, in both cases some parallel viewing and some sequential scrolling is involved). In iViews tables typically have only few lines (typically 5-10). As a consequence, more scrolling is required than in regular applications. Therefore, in iViews data should either be 1. clustered into views (with less scrolling), or 2. filtered to reduce the quantity of presented data. Here we deal with views only. For using filters see Filtering Data - The Shuffler. Forms: Views - Dependencies Collecting data into views requires that the data views be independent from each other. This is the case with tabular data, but should also be the case if interface elements like the tabstrip or dropdown lists, link lists etc. are used for view selection (see below). In the R/3 system forms-like data views often are not independent from each other; in spite of this, often the tabstrip is used to access the data views. For iViews, which are by definition simple applications, dependent data views are not allowed. Whenever there need to be dependent data views, use other interface options like wizards or screen changes - and do not implement this application as an iView.
Choosing Controls for Switching Views

There are several design options available for switching views in iViews - each has its own advantages and disadvantages:
file:///F|/resources/ma_guidelines_3/interaction/views.html (1 of 5) [03.12.02 10:15:29]
Selecting Views
q q q
link lists tabstrip dropdown list box
The link list uses very little space and is rather Web-like; unfortunately it is only suited for displaying a limited number of items. Furthermore, link lists can seem visible unstable, especially if the views look very differently. Due to their nature and associations users can have with links (i.e. when clicking on a link one will be sent to another object or another page), link lists should be used for switching to views of different objects. The tabstrip has the advantage that users can see all alternatives at any time (provided that the tabs fit into the width of the tabstrip; otherwise it should not be used at all). Thus users have a stable context and can navigate easily between the views, provided the views are not interdependent or have to be walked through in a fixed sequence. Tabstrips should best be used for applications or for screens on which to change an object's attributes (i.e. application-like screens, such as an Options dialog). Use dropdown list boxes if users have to switch between larger numbers of views, the number of views may change dynamically the labels for the views are very long
q q q
On the negative side, users only see the name of the current view. Also selecting a view take more interaction steps than for the other design options. Dropdown lists should only be used if the number of option is too high to display them as a link list. The table below summarizes the pros and cons of the different design options. Then the design options are discussed in detail. Overview of the Design Options for Views Design Option Pros Cons Remarks Recommended for...
Tabstrip
Easy to understand, keeps screen visually stable, all view names visible
Uses much space (borders), visually complex and massive
Use it if the views are visually so different that other choices would result in an unstable environment
Personalization popups or Options dialog in applications
Dropdown List Box Needs the least space of all alternatives, allows more views than tabstrip
Visually unstable if views look very differently, only the name of the current view is visible
Use it to switch between Shuffler or shuffler-like views, if more situations (search and select alternatives do exist and categories) to save space; also use it to maintain similarity to shuffler
Selecting Views
Link List
Needs less space than tabstrip, allows more views than tabstrip, all view names are visible. Web-like
Visually unstable if views look very differently; don't automatically provide feedback as for the selected view
Typically used on Websites. Put above elements in the iView if intended for switching views. Remember giving feedback, e.g.: View 1 | View 2 | View 3
Switching views to show other objects
Table 1: Design options for views and their pros and cons
Link List for View Selection

In the case of only a small number of views, a link list can be arranged on top of the view. Like the dropdown list box version, this design option needs less space than a tabstrip. Furthermore, it is perceived as "Web-like".
Figure 1: A simple link list can serve for switching views
Views in Tabstrips
Tabstrips are the current "state-of-the-art" control for displaying views, but there are some problems with using tabstrips:
q
q q
The number of views is limited by the space for the tabs. -> Do not nest tabstrips to overcome this limitation - that is "information hiding"! Tabstrips indicate to the user that views can be accessed in any order; if this is not the case, avoid tabstrips. Tabstrips provide a rather "massive" appearance.
Even though space is limited in the tab area, the tab area should not be scrolled.
Selecting Views
Figure 2: Tabstrips used to switch views
Dropdown List Box for View Selection

A dropdown list box at the top of a screen area can also be used to access views; basically, there are the same limitations as with tabstrips. Here are some of the advantages and problems of this solution:
q q q
Consumes less space (no borders). The label can be used as instruction. More views are possible, because space does not limit the number of views; however, the list should not be longer than about 12 items. The user cannot immediately see, which views are available (the user has to click the dropdown list box).
Note: The view should be activated after the user has pressed a "Go" button. This prevents users from selecting views inadvertently. It is also consistent with the shuffler.
Figure 3: A dropdown list box can also be used for switching form-like views
Filtering Data - The Shuffler
What is a Shuffler, What are the Benefits? | Selecting Views vs. Filtering | Variants of the Shuffler
What is a Shuffler, What are the Benefits?

A shuffler is a method to easily set criteria for filtering a larger data set, in order to get simplified and reduced views of the data. It mimics natural language statements for phrasing the query, but can also be used with query statements consisting of words only. The query statement is typically assembled by combining static texts with dynamic elements like dropdown lists, edit fields and selection elements. Example
Figure 1: Example for a simple shuffler

Benefits of the Shuffler
file:///F|/resources/ma_guidelines_3/interaction/shuffler.html (1 of 5) [03.12.02 10:15:03]
Easy query:
q q
Predefined natural language options instead of SQL Implicit online instruction about what is shown on the screen
Comparison to tree:
q q q q
Clear visualization of selection statements and results Better suited for non-hierarchical data Interactive change of grouping (category) Group by role, group by system, group by type of activity
Selecting Views vs. Filtering

In the simplest case, a shuffler may consist of a label with a dropdown list box for selecting the filter criteria. This design is identical to the case where a dropdown list box is used for selecting views. However, we will restrict the term "shuffler" to the device that filters data which is covered here. For more information on how to use dropdown list boxes for view selection, and what the alternatives are, see Selecting Views. In the following we discuss the differences between views and shufflers and provide criteria for when to use the shuffler and when not. Why Change Views?
q q
To interactively browse a data set To have multiple views of one coherent theme: r Same object: Show members, rooms, tasks of one cost center r Same object class: Select one customer r Same task: Toggle between information which is important for shipping international To stack screens r Toggle between different screen layouts (detail, overview)
When to Shuffle? Use the shuffler to

q q q
q q q
Select predefined report variants Visualize data structures that are non-hierarchical but rather attribute-based -> Shuffler filters by attribute Reduce complexity of trees Example: Instead of listing all cost centers with sub-nodes for DMs, PMs, Developers (tree) present flat list of cost centers and select DM, PM, or Developer by a shuffler statement (e.g. "Show all DMs") Offer interactive filtering and sorting of data Use attribute-based filter statements with predefined set of meaningful operands Change sorting or grouping based on attributes
When Not to Shuffle? Tabstrips can be an alternative if: Different screen layouts are stacked (overview detail)

q q q
Choices are very limited and of a fixed number Switches are frequent Readability of choices is important
Radiobuttons can be an alternative if: Only 2-3 choices are to be made, and embedded screens already include tabs A less dominant layout is preferable Longer text labels are needed
q q q
For more information on view selection and which alternatives exist see Selecting Views. Examples for Changing Views in iViews Toggle between different visualizations of the same data
q q
Change from bar-chart to pie-chart Change column layout of a table
Change between different layouts of screens, for example, change between:

q q q
Overview and details Simple and extended version Attribute categories of one object
Examples for Using the Shuffler in iViews

q
To offer a collection of predefined reports Example: Different Top Ten reports about cost centers Filter different line items based on attribute-based filters Example: view subset of inbox items Example: view all orders older than 123 Change sorting order Example: show all transfers sorted by receiver Select different objects of one object class Example: show cost center XYZ
Variants of the Shuffler

Shufflers can create whole sentences with variable components. Example: Show me all <cancelled> orders <of last year> This variant, however, cannot easily be translated into other languages. In addition, the shuffler query statements tend to become rather long, which is a problem for iViews. A shorter formulation of the query using a label and an accompanying selection element is better suited to iViews. Example: Display <cancelled orders> The following table provides a more formal approach to assembling shuffler query statements.
Table: Assembling Shuffler Query Statements Queries for one object class WHERE Object <LogOper Attribute>
SHOW <Object Attribute>
All Emails
Unread Emails
Today's unread Emails
All unread Emails
Queries across classes WHERE <Object LogOper Attribute>
SHOW <Object Attribute>
All Emails
Unread Emails
New Workflow Items
All Alerts
WHERE clauses WHERE <Object> <LogOper Attribute>
SHOW <Class>
<Attribute>
Emails that are unread
Emails that have attachments
Workflow items with Prio 1
Workflow items with Prio 2 or lower
Complex Queries WHERE <Object> <LogOper Attribute> AND <Object> <LogOper Attribute>
SHOW <Object>
<Attrib1>
<Attrib2>
Emails that are unread and from this week
Filter & Sort WHERE <Object> <LogOper Attribute> Grouped By < Attribute>
SHOW <Object> <Attrib1> grouped by <Attrib2>
Orders of Customer XYZ
grouped by Date
Icons and Status Information
Icons | Status Information on the Screen | Status Information in Tables
Icons
Icons are not used in iViews, except for displaying status information. That is, there are no function icons on buttons or tabs.
Status Information on the Screen

Icons can be used to display status information on the screen. Examples: Alerts, warnings, errors, etc. can be presented as icons, if it is important that users quickly find information. Note: See SAP Reference Lists in the SAP Design Guild for a complete overview of status icons and rules for selecting them. Note: In the future, a restricted set of status icons that are specifically designed for iViews and Web applications may be offered.
Status Information in Tables

Icons can be used to display important status information in tables. There should only be one such column with status icons (exception see below). Left-Aligned Status Information (Primary Importance) The status column should be the first column in the table, except There is a column with checkboxes for selecting rows, or There is a different view on the same data set and it is important to keep the context stable
q q
In these cases the status column comes second.
file:///F|/resources/ma_guidelines_3/interaction/icons.html (1 of 3) [03.12.02 10:15:17]
Figure 1: Status icons are typically displayed in the first column of a table
Right-Aligned Status Information (Secondary Importance, Multiple Status Displays) Display in the right section of the table in the following cases:
q
There is a need for displaying more than one status icon; such icons may, for example, convey data accumulated over several objects like statistics The status information is of secondary importance (e.g. "note exists")
Figure 2: Status icons in the right section of a table display statistics about object sets or data of secondary importance.
Column Headers for Status Columns
If status icons are used in tables, the column header should be meaningful so that users easily understand the purpose and meanings of the icons. The status column should only be labeled "status" if a more specific label cannot be found or if such a label would be far too long. Example: A task list contains a column that indicates whether a task has already been finished or not. If the column header would read "Status", it would be unclear to users whether the task is unfinished, critical or cannot be processed, because such a distinction cannot be made from the status icons alone. It is better to use specific labels like "Finished", which correctly describe the type of the status; now general status icons can be used, because they only modify the meaning of the label but need not carry meanings themselves.
Messages
Messages
Usage | Types | Error Handling in Tables
Usage
System Messages Typically an iViews should not issue system messages. Success Messages In some cases we recommend giving feedback on a user's successfully completed action:
q q
Critical business applications (e.g. "Your order has been taken") Actions having an effect that the user cannot see directly (e.g. adding an item to one's favorites list, which is displayed on another page, or saving preferences)
Error Messages An iView should be programmed so that error messages do not occur. Therefore, consider to prevent errors so that your iView does not need error messages at all, before putting effort into error messages and asking how they should look like, where they should appear, and what the wording should be. See Help and User Support for hints and examples on error prevention. Location Messages may refer to an iView as a whole or to a specific element in an iView. Depending on the case, messages are placed differently:
q
Messages Referring to an iView as a Whole If messages cannot be avoided, display system and error messages that refer to the iView as a whole above the iView content; they are set off the header bar and the following content by five pixels each (see Figure 1a-b). Messages Referring to a Specific iView Element Place messages referring to one element of an iView (e.g. one field of a form) directly above this element with an offset of five pixels.
Future Development After validation of a field, the error message will appear in a line directly below the field. As this change in layout can be performed locally, there will be no major screen flicker. iViews: In addition, iViews (trays) will have a status bar where a general error message will appear. This status bar may also display warnings and success messages (an icon will indicate the type of the message). The location of the status bar can be either below the title bar or at the bottom of the tray (open). The status bar may be hidden by the application. Avoid Popups!
file:///F|/resources/ma_guidelines_3/interaction/messages.html (1 of 3) [03.12.02 10:15:08]
Messages
Popups interrupt the users' work flow and thus annoy them. Exception: You may use popups for severe errors like aborts that need direct user intervention.
Types
There are two message types
q q
Critical: Error messages, warnings, alerts Uncritical: System messages, success messages (see above), status messages etc.
Figure 1a-b: Critical (left) and uncritical (right) messages referring to the iView as a whole
Both message types are visually distinct:
q
Critical messages are displayed in white bold type on a red background stretching across the width of the iView. The message text is displayed left-aligned. Uncritical messages are printed on the iView in black bold type.
Note: The visual attributes may change in the near future.
Error Handling in Tables

Errors can appear in table views for different reasons. For example, a user may enter invalid data, or certain items from a set cannot be posted. These cases have to be handled differently. Input Errors If a user enters invalid data, highlight the erroneous fields and scroll the table to the first field where an error occurred.
Messages
If an error message is needed, place it below the table view or - if possible - in a table row directly below the row where the error(s) occurred. Future Development Table views will have a status bar, where the error message will appear. Place the cursor into the error field and scroll the table to make the field visible in case it is hidden from view. If there is more than one error field, display the message for the first error field, place the cursor into that field and scroll the table to make it visible if necessary. If the cursor is placed into a subsequent error field, display the message for the respective field. If an error is corrected move the cursor to the subsequent error field if there is one and display the respective error message. If the focus is outside the table view, display the first error message again. iViews: In addition the planned status bar of an iView (tray) may display a general error message. Posting Errors Posting errors often do not require to cancel the whole posting process. It is only necessary to correct and re-post those items that were erroneous. Therefore, redisplay the table view with the erroneous items only and provide the user with a possibility to correct the items. Place an error message above the table. Future Development Place the error message inside the status bar of the table view.
Help and User Support
Explaining Texts | How to Make an iView Self-Explaining | Field Help | Value Help | Error Handling | Error Prevention
Explaining Texts
Typically, iViews should not have explaining texts on the screen. There may be exceptions, where elements, such as special fields or status displays, alert or error indicators, need explanation.
How to Make an iView Self-Explaining

iViews can be made self-explaining by using the following elements to include instructions or explanations:
q q q q q
iView title Group box headers Group headers Table or tree headers Charts or graphics, if used properly
Note: If these measures do not suffice, that is if your iView needs documentation, ask yourself whether it is really an iView! Either simplify your iView or make it a Web applicatio (IAC).
Field Help
Currently there is no field help (explanation of the meaning of a field) in iViews.
Value Help
Value help can also be provided by using dropdown list boxes instead of input/output fields, provided the number of possible values is small enough (typically less than 20 items).
file:///F|/resources/ma_guidelines_3/interaction/help.html (1 of 3) [03.12.02 10:15:09]
Figure 1: Value help provided by a dropdown list box
Error Handling
Beside help, error handling is an important aspect of user support. Error handling can help users to overcome problem situations and to continue their work. Typically error handling is done by sending error messages that note the error, explain the reason for the error and - ideally provide hints how to remedy the error situation. Currently, there is no approved error handling strategy for iViews. See Messages for details. Error Prevention Comes First! However, before handling errors, you should first ask how errors can be prevented. See the paragraph below for a discussion of error prevention.
Error Prevention
iViews have little space for error messages, especially for messages that explain causes or provide hints for error recovery. This problem is counterbalanced by the fact that iViews typically have little functionality and that thus errors are less probable. This, however, is not a satisfying answer to the problem of error handling. Therefore, the route to go is: Design iViews so that errors cannot occur. Preventing errors - instead of remedying them - has the following benefits:
q q q q
Users cannot come into error situations - many users have problems with recovering from errors. The users' work is not interrupted by error messages. Users are not confused or puzzled by (often cryptic) error messages. There is no need for a screen area that display errors.
Often it needs some rethinking and the giving up "old habits" to find design solutions that prevent errors instead of sending an error message after an error has occurred.
Do Not Let Users "Pay" for System Weaknesses Many systems work the way that they need help from the users, not the other way round as it should be. For example, often users are required to enter data in a certain format, because the system otherwise cannot recognize the input as valid data. As a consequence, an error handling procedure is needed, because users make errors. Sometimes the system is even "nicer" to the users and also provides online instructions for them. So they can read how they should enter the data. Actually, even this does not help much - users still make errors and developers complain about their "stupid" users. Actually, this way of thinking is on the wrong track! It is not the users who are the problem and who are too "stupid" to read the instructions and enter the data correctly - it is the system that requires users to act in a "system-friendly" way. If there would be - in our example - an "intelligent" input field that prevented users from entering invalid data, there would neither be a need for an onscreen instruction nor for an error handling procedure. In the following we provide some ideas and examples that may stimulate your imagination when looking for ways how errors can be prevented. Prevent Wrong or Invalid Inputs
q q
Numeric fields: Prevent users from entering letters by parsing the input string. Date and time fields: Provide "intelligent" date and time fields that are preformatted, or provide selection controls instead of input fields (dropdown lists, spin buttons, calendar controls). Currency fields: Use preformatted fields.
Prevent Invalid Actions

q q
Disable pushbuttons that cannot be used in the current context. Do not offer functionality that is not needed.
Do Not Make the Interface Lie

q
Do not use screen elements where uses expect to use them in any order, if there are dependencies or if a certain sequence of steps has to be followed. Example: Do not use tabstrips for views that depend on each other and cannot be viewed at random. At best, do not force users to perform steps in a fixed sequence.
Do Not Obscure the Screen and its Purpose Often important information is hidden while unimportant information dominates the screen. In other cases users simply have no clue what a screen's purpose is. Thus, provide the necessary information and arrange it so that relevant things are recognized first - this way users realize what to do on a screen and how.
References
References
The following references can be consulted for detailed and related information on iViews and the SAP portal environment:
q q q q q q q
SAP Reference Lists (in the SAP Design Guild) SAP Portals HTMLB Guidelines (in the SAP Design Guild) Recommendations for Charts and Graphics (in the SAP Design Guild) Portal Development Kit (PDK) iView Community Website SAP Portals iView Studio SAP Portals Help Portal
Source: SAP iView Guidelines
file:///F|/resources/ma_guidelines_3/references.html [03.12.02 10:15:39]

T ES

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

T ES

Caricato da

Copyright:

Formati disponibili

Menu

SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/content.html (1 of 2) [03.12.02 10:15:44]

file:///F|/resources/ma_guidelines_3/content.html (2 of 2) [03.12.02 10:15:44]

SAP iViews Guidelines

SAP iView Guidelines

These guidelines address a diverse audience:

SAP iViews Guidelines

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/read_first.html (2 of 2) [03.12.02 10:14:47]

Intro: iViews - Small, but Useful Helpers

Intro: iViews - Small, but Useful Helpers

Important Things First!

Intro: iViews - Small, but Useful Helpers

Information about Work Context and Business-Related States

The Right Information for the Right Decision

file:///F|/resources/ma_guidelines_3/introduction/intro.html (2 of 3) [03.12.02 10:14:49]

Intro: iViews - Small, but Useful Helpers

Personalizing and Role Fit

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/introduction/intro.html (3 of 3) [03.12.02 10:14:49]

Definition | Characteristics | Uses | Adaptation

file:///F|/resources/ma_guidelines_3/introduction/what.html (1 of 4) [03.12.02 10:14:53]

file:///F|/resources/ma_guidelines_3/introduction/what.html (2 of 4) [03.12.02 10:14:53]

Personalization What the users themselves do:

file:///F|/resources/ma_guidelines_3/introduction/what.html (3 of 4) [03.12.02 10:14:53]

There is no general personalization interface available.

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/introduction/what.html (4 of 4) [03.12.02 10:14:53]

How Can I Identify Potential iViews?

Which is a Useful iView, Which iView Does not Make Sense?

file:///F|/resources/ma_guidelines_3/introduction/identify.html (1 of 2) [03.12.02 10:14:52]

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/introduction/identify.html (2 of 2) [03.12.02 10:14:52]

Golden iView Rules - The iView Dos & Don'ts

Golden iView Rules - The iView Dos & Don'ts

Purpose and Basic Behavior

iViews on a Portal Page

file:///F|/resources/ma_guidelines_3/introduction/goldenrules.html (1 of 2) [03.12.02 10:15:00]

Golden iView Rules - The iView Dos & Don'ts

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/introduction/goldenrules.html (2 of 2) [03.12.02 10:15:00]

Classification Based on Typical Usage

file:///F|/resources/ma_guidelines_3/examples/classification.html (1 of 2) [03.12.02 10:15:10]

Interfaces to Third-Party Applications or ERP Systems

Siebel Oracle etc.

Classification Based on Interface Elements

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/examples/classification.html (2 of 2) [03.12.02 10:15:10]

Example | Use | Look

Figure 1: Table-based alert iView

be arranged in a form-like manner use graphics or charts

file:///F|/resources/ma_guidelines_3/examples/alert_ma.html (1 of 2) [03.12.02 10:14:58]

Example | Use | Look

Figure 1: A report iView displaying a table.

Initial Size and Appearance

file:///F|/resources/ma_guidelines_3/examples/report_ma.html (1 of 2) [03.12.02 10:14:59]

top Source: SAP iView Guidelines

file:///F|/resources/ma_guidelines_3/examples/report_ma.html (2 of 2) [03.12.02 10:14:59]

Example | Use | Look

Figure 1: The measurement converter is an example for an application iView

file:///F|/resources/ma_guidelines_3/examples/app_ma.html (1 of 2) [03.12.02 10:15:10]

top Source: SAP iView Guidelines