Archive - Edition 3: Portals

back To Overview of Edition

Leading Article

What is a Portal?

What's in a Portal: MiniApps, Generic MiniApps

User-Centered Portal Design

Graphic Design and Branding

"Real" Portal Projects

 

Ingredients of Portals - An Overview

By Gerd Waloszek, SAP User Experience, SAP AG – May 21, 2001

Disclaimer: Please note that this edition was written in 2001. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, branding strategy, and organizational structure, may no longer be valid.

Which are the ingredients that make a portal a portal? This question has many answers - the standard, very general answer being "information, applications, and services". In the article Generic Portal Pages - What Do Most Portals Need? in this edition, the authors take a different approach and look for page types that are common to many portals, so-called generic portal pages. They identify the following groups of page types: entering/leaving a portal, organization/structure, service, and community. In this article, I take another approach: Here I am looking for portal elements or ingredients on a more granular level than just "information, applications, and services" - although these elements do also appear on my list. There is also some overlap with the categories for the generic portal pages, which comes to no surprise, as a whole page can, of course, be devoted to the purpose of a portal ingredient.

To my opinion, both this diversity and similarity of approaches clearly indicates that portals are still in their infancy and that we are far away from a well-established classification building blocks of portals. This article puts forward some suggestions of what should be included in a future portal classification. See also Portals - The All-In-One Web Supersites: Features, Functions, Definitions, Taxonomy in this edition for a definition of basic portal functionality by Ovum, an analyst and consulting company.

 

Overview

In this article, I discuss the following portal ingredients:

Element

What is it?

News

Up-to-date information from diverse areas, which change daily or even faster

Status, Trigger

System indicators, which are important for the personal work (role-specific) and may trigger certain actions

Organization

Organization of the personal electronic work space (i.e. the portal) and the own work

Actions

Actions or tasks to be performed by the portal user

Information

Data relevant for the portal user

Service

Services for the portal user, especially so-called self-services

Communication, Community

 Platforms for information exchange with other portal users

Collaboration

Tools for working together with colleagues for a specific purpose

In the following, I take a closer look at each of these elements, describe their purpose or function, the user goals with respect to these elements, as well as their characteristics and resulting design features or considerations. Because I do not want to overload this article, I usually present only a few examples.

The purpose or function of a portal ingredient is shown side-by-side with the user goals to allow for an easier comparison. Ideally, both the purpose and the user goals should coincide, but this is not always the case. For example, a news provider may, for marketing reasons, offer information that the user is not interested in. Hence, this side-by-side comparison helps to identify possible conflicts between the interests of users and portal providers.

 

News

What is it?

News are short-lived information that is typically available for only a few days or even one only. These information snippets are regarded as relevant for the person who receives them, but not as relevant that - apart from exceptions - they need to be stored for future use. There may be news archives which can be searched, and users should also have the opportunity to save news they are interested in. But these are options and typically not the focus of news.

News come in different categories, and it is important not to mix those categories. An exception to this rule may be highly relevant news, news tickers, or windows that display the most recent news. Here, news of different categories may be blended together. Typical news categories are

Purpose, Function

The purpose or function of news is to inform readers with recent and relevant information.

 

   

User Goals

News correspond to the user goals:

  • Gather relevant and up-to-date information
  • Be informed, be up-to-date
  • Get oriented

Possible conflicts: There may be different opinions between news providers and users about what both of them considers relevant. News providers may also pursue certain marketing or political goals that may not coincide with the users' interests.

Example

News MiniApps displaying news fed in by a news provider

Figure 1: News MiniApps displaying news fed in by a news provider. In the MiniApp to the left, the news are categorized and only the headlines are shown; in the MiniApp to the right the news headlines are accompanied by one or more lines of text

Characteristics

News present "new things"; they are expected to be up-to-date and to change daily or even faster (there may be longer-living news in areas where there is little change).

News are typically short and concise. The wording of the headline is especially important for catching the user's attention. News may be supplemented by long version of the news, background articles, or comments from readers.

Most important is that news can be accessed fast and effortless.

Design Features/Considerations

Here is a couple of design features derived from the characteristics of news.
News

 

Status, Trigger

What is it?

Status displays and triggers offer information about the most important or critical "indicators" for the job or task. They may or may not trigger user actions, depending of the value of the status and the responsibility of the user.

Status information and triggers may appear in different formats, for example, as:

Purpose, Function

The purpose or function of status display is to indicate the state of certain critical or relevant variables, and - in some cases - to trigger the appropriate actions.

    

User Goals

Status displays and triggers correspond to the user goals:

  • Monitor, be oriented (get overview)
  • Make decisions, initiate actions

Possible conflicts: Conflicts may arise from a inappropriate or missing customization process, conflicting displays, hidden information etc.

Examples

Alert MiniApp indicating the qualitative status of different processes

Figure 2: Example of an alert MiniApp indicating the qualitative status of different processes; a critical status value may trigger an action

Status MiniApp comparing the progress or quantitative status of different processes

Figure 3: Example of a status MiniApp comparing the progress or quantitative status of different processes

Characteristics

Alerts and status displays offer information so that it is fast and easy to grasp. They should be at the focus of the user's attention and may be connected to actions - either "hardwired" (so that the user only has to press a button or click a link) or mediated through the user (that is, the user has to know how he or she can initiate the action(s)).

There are two types of status displays:

Design Features/Considerations

Here are some design considerations for status displays:

 

Organization

What is it?

Portals offer information, applications and services in one place. Thus, they are inherently organizing tools - they aim at helping users to organize their electronic work space, their daily tasks, and their jobs as a whole. For being "organized", a portal user needs to know:

Typically, portals are organized as huge hierarchical structures with lots of cross-links; these allow for moves that do not follow the hierarchical paths. The static structure is complemented by a search feature, which lead users directly to the information or application without having to use the hierarchical navigation tools (maybe, with the intermediate step of browsing a hit list).

Thus, portal need to offer mechanisms, which allow users to access the structure and to find their way through it (navigation). Currently, a top-level two-level navigation bar is "en vogue" (see Figure 5). For large Websites and portals, however, two levels may not be sufficient, and further levels have to be introduced. Additional indexes or navigation mechanisms, such as a navigation MiniApp can be a possible solution (see Figure 6). In other cases, the general access mechanism may already be more than two levels deep (e.g. a tree).

If you take a look at the questions above, you clearly see that not all of them can be answered by just implementing a navigation mechanism. Care has to be taken, for example, in choosing the category names and in the assignment of content to categories. The search should be easy-to-use and generally available. Last, but not least, there should be means for the user to organize his or her own stuff within the confines of the portal.

Purpose, Function

The purpose or function of organizational tools is to enable users:

  • To know what is in the portal
  • T access the content of a portal (that is, allow fast and easy access to information, "alerts", applications, and services)
  • To move within the portal (navigation) (which is closely related to accessing content)

In addition, organizational tools serve for customizing and personalizing the portal.

    

User Goals

Organizational tools correspond to the user goals:

  • Let me know what's in the portal
  • Provide access to the information and actions available (design, customization)
  • Organize and administer my work place for me (design, customization)
  • Let me organize and administer my workplace (personalization, usage)

Possible conflicts: Often the portal does not come up to the user's expectations with respect to transparency and understandability, the content, and the possibility to easily access it (for example, the user may need 20 clicks to apply for a vacation or find urgently needed regulations).

Examples

Two-level navigation structure

Figure 4: A two-level navigation structure implemented as a top-level menu plus the second-level menu of the selected top menu item (click image for larger view)

Additional third and fourth menu levels

Figure 5: Additional third and fourth menu levels may be needed for a richer content areas (click image for larger view)

Further organizational tools are, for example, sitemaps,and tools for customizing and personalizing the portal (content).

Characteristics (Examples)

Here are a few examples of what can be relevant when considering the organization and structure of portals:

Design Features/Considerations (Examples)

The following design considerations refer to hierarchical content structures and tasks:

 

Actions

What is it?

Actions range from simple functions, to procedures, or more or less complex tasks that user have to perform, either on their own, or in cooperation with the system.
Tasks can be

The possible variety of tasks is too broad in scope to be covered here.

Apart from the pure "action" aspect (deciding on an action, initiating an action), there are also means to organize or structure single actions as well as sets of actions, such as checklists or workflow inboxes (see below for examples and details).

The functionality offered in portals should be tailored to the needs of the user or user's role.

Purpose, Function

The purpose or function of actions is to perform a certain task, step in a process, self-service function, critical action, decision, etc.

   

User Goals

Actions correspond to the user goals:

  • I want to do the task fast and efficiently
  • I want to do the task successfully
  • I want to perform the task error free

Possible conflicts: Conflicts may arise if the procedures are inefficient, too cumbersome, or complex, if users are unable to perform a task, or if breakdowns happen, for example, caused by system or user errors.

Examples

Examples for simple actions are "print a document", "send an e-mail"; examples for simple tasks are "goods entry", "order processing", or "editing/entering of master data." Figure 6 and 7 show examples of how actions can be organized:

Workflow inbox

Figure 6: A workflow inbox can be used to organize and trigger single actions

       

Checklist

Figure 7: Use a check list to organize and trigger a set of related actions

Characteristics

As tasks can vary from simple actions to complex procedures, I confine myself to listing some useful characteristics for classifying tasks.

Parallel vs. Sequential Tasks

It is useful to distinguish between the following task types:

One-step actions require a simple user action, such as clicking a button or hyperlink, pressing a function key, or selecting a menu item.

Procedural tasks consist of several steps, which are performed one at a time. Here, we can distinguish between tasks requiring a strict sequence of steps (sequential tasks) - these typically involve dependencies between steps -, and tasks with an arbitrary sequence of steps (random order tasks). In both cases, users may either have to go through all steps, or through only some steps.

Parallel tasks typically involve monitoring activities, or monitoring combined with actions.

Elementary vs. Compound or Complex Tasks

Actions or tasks can also be classified along the complexity dimension. Elementary actions or tasks, such as "display", "search", or "edit" can be combined into more complex procedures and tasks.

Organizing Actions or Tasks

Possible tools for organizing tasks are:

Device

Can be Used for

Toolbar (Button List, Link List)
  • Often-used actions
  • The most important actions
  • Favorite actions (personalized by the user)

Checklist
  • One multiple-step task, where each step corresponds to a checkmark
  • Sets of coherent tasks, where each task corresponds to a checkmark

Workflow Inbox
  • Incoming actions, which have to be prioritized and processed in a certain order

Design Features/Considerations

Depending on their characteristics, tasks have to be designed very differently. Here are a few proposals:

Task Type

Features

Design Proposal

Sequential Task

Strict sequence of steps, typically each step obligatory (this is, however, not reqired)

Wizard

Random Order Task

Set of actions, all or only a selection of the steps has to be performed

Checklist

Task Stack

Incoming tasks have to be prioritized and processed

Workflow inbox

Monitoring Task

A set of indicators has to be observed and, possibly an adequate action taken

Cockpit, list, graph, diagram

One-Step Task

The user has to initiate one action only; if the action is critical, respective warnings or measures to prevent inadvertent initiation should be offered

Button, link, F key, menu item

 

Information

What is it?

Information refers to data that are relevant for the portal user. These data may be

The information offered in the portal should provide the knowledge needed by the user for performing his or her tasks or job successfully. It should not lead to information overflow on the user's side, but should be well structured and tailored to the user's needs (or the needs of his or her role).

Purpose, Function

The purpose or function of information is to supply users with the necessary knowledge needed for performing their tasks or jobs successfully.

    

User Goals

Information offerings correspond to the user goals:

  • Get information, be oriented
  • Education
  • Performance/work support

Possible conflicts: Conflicts may arise if the offered information is incomplete, misleading or inadequate, also if needed information is missing or inaccessible.

Examples

Text-based information

 

        Text-based information accompanied by an illustration

Figure 8 and 9: Information is typically text-based and often accompanied by illustrations

Characteristics (Examples)

Information sources are typically text-based and may contain larger amounts of text (note, however, that users do not like to read longer text passages online). Often, online text is prepared in a "book-like" manner and does not adhere to the guidelines recommended for online documentation.

Graphics and photos may complement the textual information, but usually do not constitute the main information; the same applies to animation and videos.

Design Features/Considerations (Examples)

Text has to be prepared in a way that supports online reading; it should not just be "books online." Text should have a simple structure - simpler than printed text. Text passages should not be too long and should have frequent headings to allow for easy scanning. Important key words can be emphasized (e.g. by using bold face) to further foster text scanning.

Often it is better to offer documentation "stand-alone" in separate windows (see Figure 10), especially if it comes with its own navigation index. Separate windows allow users to have the information in parallel to the pages that the information refers to or is connected to.

If information refers to tasks that are performed with portal-based applications, it ca n be displayed in a separate window

Figure 10: If information, such as laws and regulations, refers to tasks that are performed with portal-based applications, it makes sense to display the information in a separate window, allowing users to read the text in parallel to the application screen

 

Service

What is it?

The term "service" denotes service offerings, which are relevant to the user, typically to his or her role as an employee. To a large part, these services are so-called self-service applications, such as applying for a vacation, or ordering office supplies. In the past, these services have been performed by secretaries or service departments. Therefore, online services should try hard to offer the same or even more comfort and ease-of-use.

Other services are directly connected to the portal itself, such as personalizing the portal look and content (which may also be subsumed under the "organization" label).

Purpose, Function

The purpose or function of services is to offer employees certain administrative or personal services.

    

User Goals

Services correspond to the user goals:

  • Let me do this fast and easily, e.g. apply for vacations, enter personal data, enter banking data, order office supply, ...
  • If I have to do it on my own, the online service has at least to run smoothly

Possible conflicts: Conflicts may arise if the service applications are inefficient, cumbersome to use, or too complex to be easily understood. Conflicts may also arise if users are unable to perform a service task, or if breakdowns happen caused by, for example, system problems or user errors.

Example

Employee self-service application for creating a new bank account

Figure 11: Employee self-service application for creating a new bank account

Characteristics

Design Features/Considerations (Examples)

Here are a few recommendations for achieving the goal of simple and easy-to-use service applications:

 

Communication, Community

What is it?

These terms refer to tools supporting the communication between portal users and the building of online communities. The information exchange with other portal users may take place within a company or even across company boarders (on the basis of shared interests).

Purpose, Function

The purpose or function of tools for supporting communication and community life is to offer a platform for information exchange between portal users.

    

User Goals

Tools for supporting communication and community life correspond to the user goals:

  • Exchange information with others
  • Ask questions (and get answers)
  • Answer questions (from others)

Possible conflicts: There may be conflicts between company and personal goals for information exchange. For example, a company may want to restrict the communication according to certain policies.

Examples

Discussion board

Figure 12: The SAP Design Guild forum is an example of a discussion board

Other examples for communication platforms are mailing lists, chat rooms, and team places.

Characteristics (Examples)

Examples for communication tools or platforms are:

Platform

Explanation, Characteristics

Shared Document

A document that is edited and added to by several people

Often simple text documents suffice for the purpose

Mailing List

Mails are sent to a list server from where the mails are resent to the members of the mailing list

Typically mails are checked and edited by an editor before redistribution

Often mails are relatively long - people express their opinions here;
in other lists, the focus is on technical issues

Discussion Board

Contributors send mails to the board and ask questions or reply to existing mails; the mails are organized in threads according to topics

Typically an editor watches the discussion board, but rarely edits or deletes contributions

Contrary to the chat room, a discussion board is an "off-line" discussion

Although these boards are often about technical issues or hobbies, flaming (picking other participants' opinions or devices) is a frequent phenomenon and problem

Chat Room

Forum for "online" communication; in some chat rooms people take on roles and/or appear as "avatars" (artificial characters)

Chat rooms are often devoted to "borderline" communities; on the other hand, they can also be a very efficient communication medium for technical or organizational issues

As the list shows, communication platforms may be moderated (e.g. mailing lists, discussion boards) or unmoderated (discussion boards, chat rooms).

Communication platforms support the building of online communities, which typically center around certain shared interests, be they work-related or private.

Design Features/Considerations (Example)

As an example, here is a design consideration regarding discussion boards.

Question

In some discussion boards the messages in a thread are arranged in one list on a long scrollable page, whereas other discussion boards present one message per screen. What is better?

Answer

Interaction is much faster and easier, if the messages are arranged on one page because

Problem: The first loading of the list may take very long if the list is long (often way beyond 100 KB).

 

Collaboration

What is it?

Collaboration means to work together with colleagues for a special purpose. People can collaborate:

Purpose, Function

The purpose or function of collaboration tools is to enable different users to work on the same process or document.

    

User Goals

Collaboration tools correspond to the user goals:

  • Let's work together smoothly
  • Let me perform my step(s) fast and easily
  • I want to know what the state of the object/process is
  • I want to know when it is my turn

Possible conflicts: Conflicts may arise, if the status of the shared documents or processes is intransparent to the participants.

Examples

Workflow inbox

Figure 13: A workflow inbox can be the personal entry point for collaboration on the basis of stepwise processes

Characteristics (Examples)

Collaboration tools or platforms may include:

Therefore, the characteristics of and requirements for collaboration tools may be very different.

Design Features/Considerations (Examples)

As an example, here are some design considerations connected to the user goals:

 

Conclusion

This concludes my list of portal ingredients. It is a very preliminary list, but, to my opinion it shows the way to go. Portal guidelines should include such lists or similar ones

This will be even more important in the future. Then, portals will no longer be built from scratch. Instead, they will be assembled from already existing components. These components cannot be simply merged together. They have to be adapted to the portal - to its look and feel (e.g. to the branding), as well as to the needs of the respective users or user roles.

 

top top