 |
|
|
Archive - Edition 1: mySAP.com Workplace and Portals
- Leading article: mySAP.com Workplace and MiniApps – Steps towards a Personalized and Efficient Electronic Work Environment
- Building Blocks of Web Portals
- How to Master Portal Design
- Portals – A Step Beyond the Desktop?
- The Right Information Right on the Spot
- SAP User Roles – A Way towards a Personalized Workplace
- Self-explanatory Web Design: How Can Portals be Designed so that they are Easy to Use and that Users Find the Information and Functionality they Need?
- WAP – Designing for Small User Interfaces
Links & More
 |
Print version |
Related Links |
|
 |
How to Master Portal Design |
Background Links |
|
 |
Recommendations for Charts and Graphics |
|
|
Efficient MiniApp Design – The Right Information Right on the Spot
By Gerd Waloszek, SAP AG, Product Design Center – 08/01/2000
Disclaimer: Please note that this edition was written in 2000. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, branding strategy, and organizational structure, may no longer be valid.
Getting at the Relevant Information | Presenting Information Effectively | The Big MiniApp Picture
MiniApps are a key element of the mySAP.com Workplace. As the building blocks of a "personal entrance" to the user's work environment, they offer user-specific information and functionality. Consequently, MiniApp design focuses on how information is presented and accessed. The key to a successful MiniApp is keeping the interaction simple - interaction design largely means reducing complexity and presenting only relevant functionality. The visual design should support this effort by structuring the information presented and directing the users' attention to what is relevant.
In this article we present an overview of MiniApp design. First we address how users access data, then we touch on issues regarding data presentation. Finally we discuss how MiniApps can be effective even when assembled with other MiniApps in a view.
Getting at the Relevant Information
Reducing to the Relevant
MiniApps present all their information in one small, visually stable screen - users cannot switch back and forth from one screen to another in a MiniApp. Typically MiniApps are used as advance-organizers that offer a highly condensed information summary or overview. Designing such MiniApps means reducing and transforming existing data into relevant information. But what is relevant? MiniApp developers have to answer this question largely before they start coding. Finding the correct answer requires a firm grasp of the subject area as well as an understanding of the users' needs and tasks - the development team has to involve users throughout the design process. Additional tweaks for relevance may be made by the system administrator as it is tailored to the user role, or by the end user in the personalization process. But these customization and personalization options also have to be designed into the MiniApp by the developer from the beginning.
Managing the Data
While data selection and browsing play a prominent role in many business applications and reporting tools, MiniApps should only require basic interaction from end users. This need for simplicity may cause some headaches for the developers if users need a lot of information to keep up-to-date or make decisions. How can the required data be handled by the system, how can it be preprocessed and presented so that it comes in chunks small enough for the user to digest?
Many developers believe they have to present data the way it is stored in the computer. This is a example of what Allan Cooper calls "bringing the implementation model to the interface." But there is no need for one-to-one mapping from an internal data structure to its presentation at the user level - the only requirements are that the presentation meet the users' expectations and that it be as simple as possible. Here are two approaches to meet this goal:
- Simplify the internal hierarchical data structures and transform them into flat lists or lists with one category level only
- Replace logic-based queries with filters that use attributes like date, time period, country, region, processed by, etc.
The shuffler promoted by Allan Cooper combines these approaches to create simple, natural-language queries (see figure 1). Other design solutions do not aim so much at similarity to natural language; however, they do occupy less screen space and are easier to implement and translate into foreign languages.
Figure 1: A shuffler based on two attributes, data type and year
Accessing the Data
Navigation and Presentation
Different data structures and thus different presentations imply different models of navigation. Hierarchies tend to introduce a lot of up-and-down navigation, that is, movements between screens that display the nodes of the hierarchy. Linear lists typically require extensive scrolling. Clusters resulting from attribute filters like the shuffler present an intermediate level of complexity that fits medium-size data sets. The filters partition the data set into views, which the user can usually browse easily with little or no scrolling. Such views may, for example, show the sales figures for different regions in the US.
Inspecting different data views with the shuffler or a similar device keeps the screen layout stable because only the contents of the table change. Users do not become disoriented and often do not even perceive the view changes as "navigation." Given these advantages, no other way of displaying new information within MiniApps should be offered. Scrolling tables is tolerable but should be limited to a few pages only.
External Navigation: Easy Access to the Data "Behind" the MiniApp
Many MiniApps are just previews. Users need easy access to the data behind the "indicators." The data in the MiniApp should link the users directly and instantly to the report or application that "shows the whole truth." This is the only navigation permissible between a MiniApp and related applications. There is also no navigation from one MiniApp to another.
Minimizing Interaction: Saving Preferred Views, Pushing Data
Having the system remember what is relevant for users and starting-up MiniApps with predefined "favorite views" can further simplify interaction. Push mechanisms can be used to automatically provide users with data and thus minimize the extent to which they have to request information themselves.
Presenting Information Effectively
Having decided which data to offer and how users access it, the next question is how the data can be presented for efficient usage. To achieve this goal, information design has to satisfy the requirements of
- Contents and tasks - the primary determinants when choosing a method of presentation
- Human information processing and perception capabilities, which often act as design constraints
- Visual experience mediated through the layout and visual design
The visual design has to convey attractiveness and "style" - to stimulate motivation, provide a pleasing environment for the users, and transmit professionalism.
Many SAP developers come from a text-only tradition and now have to learn how to use graphics properly, when to use text and when graphics, and how both can be combined for maximum effect. No wonder that most of the first SAP MiniApps contained tables - tables are compact, generic and easy to design. Using charts or graphics is much harder; it requires knowledge and experience, as well as assistance from graphic designers. Graphics are also by no means a "revolution" in data presentation - they are just the beginning of exploring alternative methods of presentation, for example, animated and interactive charts and graphics.
Charts
Whenever possible, developers should use charts instead of tables in MiniApps, especially if users need to orient themselves quickly. If users want to know exact numbers, these should be included in the chart. If more or all numbers are needed for the task, the MiniApp should offer alternative chart and table views.
Choosing the Right Chart for the Task
Tasks imply typical questions; presentations should help users to easily answer these questions. Here are some examples of tasks and suitable charts:
- Ranking (e.g. top ten): Who are our biggest suppliers?
Preferred chart: Ordered horizontal or vertical bar chart (figure 2) - Percentage (e.g. whole to part relations): What's our current market
share?
Preferred chart: Pie chart (figure 3) - Absolute Values (comparisons): How effective have our cost saving
measures been over the past 6 months? How much have we saved each month?
Tip: Add values to chart elements or use a table
Figure 2: Ordering a bar chart easily reveals the ranking (right)
Figure 3: The pie chart easily reveals that parties 1 and 5 together have the majority in parliament and can form a government
Problems with Charts
While charts may convey information very effectively, improper usage can cause problems:
- Distortions: 3D effects and perspectives make charts hard to read and can lead to misinterpretations of the data (optical illusions); they also consume more space than 2D charts (screen space is a scarce resource in MiniApps)
- Color blindness (over 8% of the population): Do not rely on color coding alone. Use additional attributes like lightness or shape to distinguish chart elements.
- Monochrome color palettes: People have difficulty comparing monochrome colors in a legend to the colors in a chart. This is especially true if there are more bars than colors available in the palette (e.g. there are only 8 colors in the palette, but you have 11 bars), and colors have to be repeated, or if the legend is far removed from the chart.
Text Design
In the past, text design for SAP applications was easy - there was just one type of text. As a result, most screens looked unstructured, and text information was also scarce. Such screens do not "speak" to the users to explain their purpose. With the advent of web applications, however, users have different expectations of how screens should look: web applications tend to look more like news sites on the Internet - comprising a mixture of interaction elements, text information, and graphics. Such a layout requires text styles which structure textual information, emphasize important things, and let less important things blend into the background. Using styles, developers can achieve a proper balance between important and less important information, something impossible to achieve in classical GUI applications.
- Headings of different levels allow users to scan a MiniApp for relevant information.
- Standard text offers the necessary information in a readable format.
- Small text presents additional information like legends, hints, or notes; these are included on the screen so users don't have to navigate unnecessarily or overload their short-term memory. (Information would only be only sequentially available, e.g. either the chart or the legend, but not both at the same time.)
The Big MiniApp Picture
Typically, the various bits of information provided by MiniApps are presented as previews or summaries. Thus, MiniApps have much in common with the instruments in the cockpit of an airplane or the dashboard of a car. This implies two aspects of MiniApp design: the design of the information within a single MiniApp, and - equally important - the design of the MiniApp view in the mySAP.com Workplace as a whole. Up to now, we focused on designing single MiniApps. Now we are putting those pieces together and looking at the assemblage of MiniApps, i.e. the MiniApp view.
Optimizing the View
Developers control the design of their MiniApps, but the MiniApp view is beyond their control. It is customized for the user role by the administrator and personalized by the end users. However, it would be a mistake for the developer to conclude that he should focus on his own MiniApps and not bother with the MiniApp view at all. For the MiniApp view to be effective, users must perceive it as a coherent whole, but each MiniApp must also be distinguishable from its fellow MiniApps.
MiniApps that all Look Alike Hide Important Information
The MiniALV (for the uninitiated, ALV stands for ABAP List Viewer), one of the first available MiniApp controls, provides a simple interface for tabular data. Not surprisingly, most of the new MiniApps contained a table based on the MiniALV. While in individual cases there may be compelling reasons to use a table view, for the Workplace as a whole this is a disaster in terms of effective presentation of information. As tables all look pretty much the same, the points of visual reference available to users looking for information are drastically reduced.
Figure 4: A worst-case scenario - all MiniApps use tables and look alike...
How to, and not to, Make a MiniApp "Stand Out"
While developers do not have the power to design the MiniApp view, they can at least make their own MiniApps distinctive so that they "stand out." The easiest way to make a MiniApp stand out is to let it take up the whole MiniApp view. Of course, this is a "selfish" solution and not the best way to make a MiniApp distinguish itself. A better way is to use the most effective method of presentation for the information at hand.
Personalizing the MiniApp View
Even the most effective design does not help much if all MiniApps in a MiniApp view look the same - we mentioned this problem for tables already. Thus, while a MiniApp using graphics or charts has a good chance of "standing out," its advantage diminishes if all the MiniApps in that view use graphics and charts as well, especially if the layouts are similar. As a developer, you can offer alternative presentations; as a system administrator, you can layout the MiniApp view so that users have a good starting point. But users should be allowed to arrange their own MiniApps and select their preferred view and thus create an "information center" that fits their personal needs.
Multiple Views
Some users may need a lot of MiniApps, depending on the tasks included in their roles and on their personal information needs. For example, alert and monitoring MiniApps provide a quick overview when the user starts his or her system, and then may not look at them again that day. For her day-to-day job, a user may work with a set of MiniApps for handling goods entries, and then another set for ordering goods. At noon she scans news MiniApps with weather reports, sports results and stock exchange rates. Scrolling a huge MiniApp view containing all these MiniApps is surely not a good idea. It even contradicts the MiniApp concept, because there is no point in scrolling down a page to find important system indicators, alerts or information.
Therefore, multiple MiniApp views are a must for the mySAP.com Workplace. Each view should be easily accessible, make sense to the user, and provide clusters of related information. MiniApps may even appear redundantly in different views, if this helps users work more efficiently. Multiple MiniApp views should be pre-structured by the system administrator according to the users' roles. But again, the final arrangement and fine-tuning of the views should be left to the end user.
