Intro: iViews - Small, but Useful Helpers

Introduction

The challenge for the next years will be - apart from further improving and simplifying software applications - to provide and process knowledge. Computers shall not and will not make intelligent decisions on their own, but are meant to provide humans with the necessary information in an optimal fashion. The SAP portal environment with its iViews takes a first big step into this direction by providing and integrating role-specific knowledge from various information sources.

iViews reside in the content area or work space of the portal and typically occupy far less screen space than usual applications. The small containers (called trays) that host iViews are collapsible and expandable. Thus, users may hide less important or currently not used iViews and show them again as needed. Vertical scrolling within the portal allows users to quickly position on a wanted iView without the need for closing other iViews. This navigation principle is efficient for and suited to Internet browsers, because users can switch between iViews without experiencing disturbing page reloads.

Essential Design

Interaction design for iViews places a high burden on application developers, because design has to focus on the essentials. This requires in-depth knowledge of a user role's needs and to set adequate priorities. Though it is often hard to reduce functionality and information to the essential, such reduction is the real advantage of iViews over conventional applications: Risking to lose additional information also emphasizes what is really important for users. This general design rule is valid for any application, but even more so for iViews.

iViews are set apart from other applications by being less complex. An iView's content and "message" must be grasped at one glance. Interaction should generally be restricted to one screen only. It is not the goal of iViews to squeeze rich functionality into a small screen area. Instead, developing iViews means to create new, simple applications - applications that have more the character of information providers and that cohabitate with other, modular iViews in the SAP portal environment.

If your iView takes more screen real estate than a fourth of the portal, consider either

to redesign the iView so that it takes less space, or
to convert your iView to a Web application (IAC = Internet Application Component) or other application type

Reducing design to the essentials has positive side effects. Fewer screen elements and fewer decorative elements reduce the complexity of the screen and help users to find relevant information faster.

See How to Make iViews "Mini" and Less Complex for tips on saving space!

Important Things First!

Often valuable tools are deeply hidden within an application or not at all supported. For some work places R/3 was more of a system where users had to enter lots of data, but it was not very helpful in their daily work. iViews address this lack of user support by directly providing useful and role-specific information on the entry screen of the SAP portal environment - instead of hiding this information deeply inside applications. They do not require users to enter even more data, but offer useful information. But how do we know which information is regarded as useful by a certain user?

The answer is: Any information is useful that is connected to the goals of a task and that is suitable to support decision making. Much too often applications only copy the observed task steps, but forget to provide information that enables users to decide whether and how they will take actions in order to achieve a certain goal. Therefore, it is imperative for successfully designing applications to visit customers and to get into direct contact with end users - only this ensures that developers get a clear and correct picture of the goals and responsibilities of a user role. Based on these observations, the users' primary information needs can be easily derived.

Information about Work Context and Business-Related States

iViews are intended to provide for the users' primary information needs, for example by making a user's work context more transparent. This applies to the personal work context, which consists of an individual work supply and the status displays of processed objects. But it also applies to the business context, the status of which can be mediated by displaying relevant business figures.

A user's role may seem to require to display states dynamically and in real-time. However, a closer look often reveals that many work supplies are updated only once or twice a day. For example, new availability lists for overdue goods are generated over night and then processed during the following day. Such lists need not be available in real time.

Apart from such (more or less) up-to-date data, iViews may also provide access to often used static information, such as legal regulations, reference books, or guidelines.

The Right Information for the Right Decision

Apart from general state information, data that may initiate actions are important. These data may be critical messages which signal an exception that requires fast reaction. But there are also data that we use in our daily work for planning the next steps, often without even being aware of this. All routine jobs are based on a fixed mental rule set; we use these rules together with current information to plan the next steps: You know what to do next, but you also have to take current data into account in order to decide which step is the appropriate next one. If such information is missing or incomplete, it may be very laborious for users to plan the next actions.

Often the level of information is inappropriate and thus causes unnecessary stress. If, for example, differences between values or data ranks comprise the relevant information, this type of information should be directly supplied to the users; the users should not be required to perform mental comparisons or to generate complex ad-hoc reports in order to find these data. A display of trends for certain business data or a statistics on unread e-mails can already be valuable information for deciding what to do next.

Choosing the proper visual representation of data is important as well. Often, two design alternatives seem to be equally good choices. But this is not true for the user! For instance, a table and a chart may contain the same information. However, both presentations - though formally equivalent - may actually serve very different user goals: A chart helps to quickly find relevant features (goal "fast information overview"), while a table provides exact numbers (goal "know exact values") but makes it harder to find the relevant information.

The goal of an iView should be to make every information accessible that is relevant for taking actions and that supports decision making. Developers have to rethink their applications and to put data to the front that up to now have been hidden deeply inside applications or at the bottom of long reports. Such a redirection enables users to decide first and then take actions.

It is obvious that iViews will not replace ordinary applications. But iViews should cover the users' primary information needs without forcing them to call applications. iViews are like previews on applications or collect data from predefined reports which cover 80% of the needs of a certain role.

Mini Tools

Apart from the above-mentioned information-oriented iViews, such iViews should populate the workplace that provide often used functionality like simple and easy to use tools. For example, an iView could convert currencies or units, or allow data transfers that are reduced to the very minimum, such as the booking of a routine trip.

See Generic iViews and Identifying iViews for examples of such mini tools and approaches to identifying potential iViews.

Personalizing and Role Fit

Because iViews are strictly oriented to the users' needs, users must be able to adapt them to their personal preferences; also system administrators must be able to adapt iViews to the business context at hand. Often only the customers will know which iViews do make sense for certain user roles. Users themselves, too, will want to select their personal iViews from a broad set of iViews and personalize them.

Like role definitions, iViews will often just be templates which have to be adapted by system administrators and end users to the business context at hand. Customizing the portal according to user roles not only includes technical issues, such as access rights, but also an analysis of the target roles for a customer based on business content and functions. Such an analysis can be supported by directly interviewing selected users that fit the role profile.

See What is an iView? and Personalizing iViews for more information on adapting iViews to user roles and to the users' preferences.

top