Golden iView Rules - The iViews' Dos & Don'ts

Purpose and Basic Behavior | iView View | Data Processing | Presentation | Navigation | User Support

The following "golden rules" capture the essence of iView design.

 

Purpose and Basic Behavior

iViews

  • 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

 

iView View

iViews are not alone, but share the iView view with other iViews. Therefore:

  • Do not let your iView occupy the whole iView view; instead, make your iViews as small as possible
  • Make your iViews distinctive; users cannot find information efficiently in a uniformly looking iView view without any structure

 

Data Processing

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

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 like 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.

 

Navigation

iViews have only one screen, there are 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),
  • iViews that are based on a well-known metaphor like notebooks.

Provide easy access to more extensive data views and program capabilities.

Example: Let the users click on links to access related IACs or R/3 applications.

 

User Support

Save user preferences so that users need not repeatedly perform the same steps for choosing data when they start an iView.

Provide personalization capabilities.

Avoid error messages.

More importantly: Prevent errors! There should be no errors in iViews.

 

top top

Source:  SAP iView Guidelines for Java