Golden iView Rules - The iView Dos & Don'ts

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

iViews are not alone but share a portal page with other iViews. Therefore:

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

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

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

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),
- iViews that are based on a well-known metaphor like notebooks.
- 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.

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