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

Types of Navigation

Considering the two main functions of iViews, there are three basic navigation styles for an iView:

• 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

Often there are different options for switching views available. Some of these include:

• 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:

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

 top

Source:  SAP iView Guidelines