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!

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.

top