Navigation

Introduction | Types of Navigation | Guides 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 serve as small tools for a limited scope of functions, like 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.
• Movements to modal dialogs for secondary information or for value selection (value help).

Types of Navigation

Considering these two functionalities, there are three basic ways of navigation 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 get different views on the iView content. 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 an 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 avoid complex inside navigation. If inside navigation is a necessity then take the following elaborations into consideration:

Guides 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 like a tabstrip to switch between views, and this tabstrip always remains a stable and unchanged component. This enhances perceived stability.

Never exchange the whole content of an iView, forcing the user to 'go back' to the original content.

Using Navigation Controls

In many cases there are different alternatives that are suitable for the purpose of view-switching. Some of these include:

• Tabstrips
• Link lists
• Dropdown listboxes

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 listbox 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 only sees one entry at a time. This increases the effort for navigating through the choices. On the other hand, dropdown-listboxes are the least limited by 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

A more detailed discussion of views and switching between views can be found in chapter Selecting Views.

 top

Source:  SAP iView Guidelines for Java