From the IBM WebSphere Developer Technical Journal.

Introduction

Targeting content and applications to the right consumer can be a complex problem. On one hand, you want to provide sufficient information and applications to the user to perform his or her tasks. On the other hand, you don't want to provide so much information that you risk information overload, which in turn limits the employee's focus and reduces productivity.

This article shows how you can use WebSphere Portal to provide a more dynamic, agile, intelligent, and context-aware user interface called a contextual portal. It uses example scenarios to illustrate how static Web sites and static portals limit productivity and how dynamic capabilities of a contextual portal overcome these user experience and productivity challenges. The contextual portal concept describes how administrators, portlet developers, and portal developers can use dynamic portal capabilities to adapt the user interface to the user's situation and context. Understanding and exploiting dynamic capabilities in WebSphere Portal can help you improve your users' experience and productivity, which raises the value of your portal site.

This article assumes a basic understanding of WebSphere Portal technology.

Back to top

What is a contextual portal?

Recognizing the value of internet technologies, companies established intranets to provide their employees with a central point of access to enterprise specific information. Initially, intranets provided the most valuable and widely used information to employees with quick and efficient information access. But the amount of information accessible quickly grew, and finding the right information became more complex and time consuming.

Many companies successfully introduced portals to manage the emerging information overload. Portals provide users with a central point of access, in a highly personalized manner. Portals let you provide information and applications based on the role of a user within the enterprise. Understanding the role of a given user and his information enables efficient targeting of the content. Today, portals are comprised of a huge amount of content, and finding and accessing the right information for a particular situation can be quite time consuming. Information overload is becoming a productivity threat again. In today's business environment, information needs for users in a given role are continually changing. Your portal needs continuous adoption of role definitions to reflect business change and to keep productivity and efficiency at a high level.

You can use WebSphere Portal to improve the continuous role adoption process by building a contextual portal. The contextual portal is a concept in which you use dynamic portal capabilities to adapt the user interface to fit a user's situation and context. A first step to ease accessing the content needed within a particular situation is to introduce filtering mechanisms to achieve personalization (Figure 1). Content is filtered by access-control rules that shrink the amount of content a user can access to the subset of the entire portal content that this specific user needs to carry out his or her daily work. Reducing the amount of content a specific user can access increases usability because the irrelevant content no longer distracts the user; the user accesses relevant content quicker.

Filtering mechanisms usually do not recognize the context in which a user is acting. These mechanisms also do not "learn" from a user's previous behavior to make assumptions about what would be meaningful to be displayed within a particular situation. Filtering rules (for example, access-control rules) are often centrally managed by an administrator. These rules do not reflect a user's behavior nor do they automatically adapt as soon as a user's behavior changes.

A contextual portal enables a further reduction of the filtered portal content to the relevant portal content. This content is selected based on the context in which a user is acting, and only the subset of content which is relevant for a particular context is provided to the user. Contextual information that is typically used for filtering includes current date, time, last actions performed, current navigational position, and awareness of other persons online.

A contextual portal can collect knowledge during a user's interaction with the portal, filter the collected knowledge, store the acquired knowledge, and finally make use of the previously acquired knowledge and context information during future sessions (Figure 2).

The contextual portal helps you support a user's typical behavior by taking into account contextual information and by learning from the user's behavior.

Back to top

Comparing today's portals with a contextual portal

Consider how a fictitious user called "Bob" might use a portal to perform his daily work. Bob works for a large travel agency chain which has agencies worldwide. He administers the Web content of some of the agencies and books flights, hotels, and cars for customers. Customers can request bookings can through mail and phone, or by directly visiting one of the agencies.

The four example scenarios in the next section demonstrate the drawbacks of today's static portals. Later in this article, you see how the same tasks can be accomplished using a contextual portal, how things differ, and how to overcome static portal drawbacks.

Back to top

Working with a static portal

Bob's company has deployed a static portal, which provides Bob with centralized access to the information and applications he needs to do his work. Bob works with the portal as follows:

• Every Monday morning Bob checks his appointments (for meetings and so on) for the upcoming week using a Calendar portlet.

• Throughout the week, Bob works on recurring tasks such as administrating the agencies' Web content and booking flights, hotels, and cars for customers.

• Bob has access to a large set of pages, but he only needs a small subset of them regularly. Each page is equipped with a primary form which Bob fills out. Bob often uses additional portlets (operation-supporting elements) to fill out the primary form.

• The forms are comprised of a large set of input fields. Into a high percentage of these fields Bob always enters the same information, which is sometimes information he previously collected from other pages and portlets.

Example 1. Static portal: Recurring information retrieval

Like many portals, the portal that Bob uses contains hundreds of pages. Because Bob sometimes backs up other colleagues, he has access to almost all of these pages, although he only needs access to a small subset of them regularly. The result is a complex hierarchical navigation through which Bob has to click over and over again.

Typically, the navigation which provides access to these pages is assembled once, and it is static from that point in time. This leads to the problem that users that need access to "poorly positioned" content must click through a long path to navigate, and they have to do this over and over again.

It is usually not possible to completely prevent poorly positioned content in a static portal for users in small groups of roles; portals are optimized for larger groups of users in roles, and not for a specific person. So, this situation does not help Bob.

A static portal cannot accomplish the perfect arrangement for every user. There is not enough knowledge or time to optimize for all users based on their wishes and behavior -- which might also change over time.

One of Bob's tasks is to administer the Web content for the different travel agencies, and he administers the Web presence for the agency in Stuttgart, Germany. To reach the page for this particular agency he must click through a complex hierarchical navigation, as shown in Figure 3.

Example 2. Static portal: Providing information

Another part of Bob's job is to book flights, hotels, and cars for customers who make requests by phone and mail, or by visiting an agency.

The booking process requires Bob to fill out a primary form with relevant information. For example, to book a flight, he must specify:

• Departure location
• Destination airport
• Departure date
• Arrival date
• Preferred airline
• Seat class

Operation-supporting elements (portlets connected to the primary form portlet which help gather relevant input data) help Bob to fill out the primary form. They are usually placed on the same pages, probably beside the main form and are click-to-action enabled (see Resources).

In a static portal, the layout of pages is defined once and stays unchanged for some time. Users can change that page by adding new portlets to make it more useful; usually users optimize the page once, but then it stays static again. Bob uses the following additional portlets when booking a flight:

• Location picker portlet to chose an airport for departure and arrival.
• Calendar portlet to pick the date of departure and arrival.
• Flight selection portlet which displays available flights based on the information entered before.
• Customer data portlet to transfer the customers profile to the booking mask.

Placing all these additional portlets on the page just overloads it (Figure 4), and results in poor usability. Bob's screen becomes overloaded with support elements being displayed at the same time. It is more difficult to recognize which support element might be of interest within the current context when all the supporting elements are displayed, including those that do not provide any help for the current step of filling out the form.

Example 3. Static portal: Information gathering

Sometimes Bob does not use operation-supporting elements to fill out the primary form. Using them was reasonable when booking a flight, but sometimes customers visit the agency in person and want to book a flight, a hotel, and a rental car all at once. In this case, Bob must use a larger form. Because customers are always interested in detailed information about the hotel (exact location, its appearance, and so on) or car, Bob needs to access a variety of applications in the portal to provide them with this detailed information. Therefore, there is a special page for providing the customers with information about the hotel, which is equipped with various portlets that show detailed information about the location, provide detailed pictures, and so on.

Bob visits the special pages to get information about the flight, the hotel, and the car. While visiting these special purpose pages, Bob has to remember or write down the customer choices to use when he returns to the main form to complete the booking. Bob is getting less help from the system than he feels it should be providing.

Example 4. Static portal: Notifications

Occasionally, Bob has to perform exceptional tasks. For example, he sometimes attends meetings which are not held on a regular basis. For those, he has entries in his calendar. Every time Bob visits a portal page, the portal checks whether a special task is available. If a meeting starts within the next 30 minutes Bob get notified by a little alert indicator on the portal page he is currently visiting. The remainder of the upcoming meeting changes Bob's context independently of Bob's current activities. When Bob clicks on the alert, he is redirected to the corresponding calendar entry to review upcoming events.

With this approach, it might happen that Bob does not visit portal pages, but stays reading information on a given page for an extended period of time. As a result, he might not be reliably notified about upcoming events. The system only updates the display of alerts if Bob performs some action leading to a page refresh.

Back to top

Working with a contextual portal

Bob's company decides to adopt the contextual portal concept to improve user experience and productivity. With the new portal, Bob's working environment has changed. Every Monday morning after logging into the portal, Bob is automatically directed to the page containing the Calendar portlet instead of the Welcome page, in which he is not usually interested. Bob does not need to navigate to the Calendar portlet anymore.

The contextual portal automatically places links to the pages containing the portlets he often needs within easy-to-reach navigational positions. It automatically displays operation-supporting elements needed to provide data when they are needed, and on-demand, in a context-sensitive manner.

Bob can use a generic context-exchange mechanism enabling him to store information he retrieves from some portlets in order to propagate them to a target portlet; that is, he does not have to remember or write down anything anymore.

Example 1. Recurring information retrieval

Bob has access to a huge number of pages; however, he only uses a small subset on a regular basis. Currently, before the introduction of the contextual portal, he must repeatedly click through a complex hierarchical navigation each day.

Analyzing Bob's navigational behavior, and acquiring knowledge about his favorite navigation elements (the ones he visits most often) and the routes he usually takes, enables the contextual portal designers to optimize the complex hierarchical structure for Bob based on his specific needs.

The designers consider these options to optimize Bob's user interface:

1. Manual restructuring: Gather statistics to reflect Bob's navigation behavior. Administrators use these statistics to reorder navigational elements, optimizing the structure based on actual usage.

2. Application of business rules: Use business rules to influence what is and is not displayed as part of the navigation.

3. Quicklinks portlet: Add this portlet to display Bob's favorite links.

4. Quicklinks navigation: Bob's favorite links display below a dedicated node within the site navigation.

5. Automatic restructuring: Change or restructure the site navigation based on Bob's behavior during run time.

Various evaluation strategies are described in Resources publications [Ram00], [Jia02] and [ADW01], plus WebSphere Portal provides page and portlet usage statistics. (See the Site analysis section of the WebSphere Portal Information Center, also in Resources.)

The Quicklinks portlet (Figure 5) or the Quicklinks node (Figure 6) parts of the portal's navigation provide Bob with direct access to his favorite pages. What is presented changes dynamically as Bob's navigation behavior changes. A click on a link directs him to the corresponding page.

The Quicklinks example portlet uses portal usage statistics provided by WebSphere Portal site analyzer log files. It provides integrated support for WebSphere Portal enabled for analytics of portal usage. (See the Site analysis section of the WebSphere Portal Information Center, in Resources.)

Example 2. Contextual portal: Providing information

Bob uses operation-supporting elements (additional portlets) to fill out forms. The number of supporting elements that Bob uses to fill out the customer vacation form is more than can be included in a useable way on a single page. In the contextual portal, operation-supporting elements (which could be pages as well as portlets) display dynamically and are based on the context in which Bob is acting.

A context change can be implied as Bob navigates within the primary form. As soon as he selects an input field, the context changes. The operation-supporting element that is useful for the current context displays to help him complete that field; other supportive elements disappear.

Operation-supporting elements which display on demand, dynamically, during run time, in a context-sensitive manner have several advantages:

• Usability is increased tremendously as the layout is clearer (no overloading). The user is not distracted by operation-supporting elements that are currently not applicable; he or she immediately recognizes which support element to use because it is the only one being displayed.

• The resulting page layout in a contextual portal is more concise. It enables the user to more easily focus on what is important, instead of being distracted by extraneous information.

Figures 7 and 8 illustrate the improved interface.

Enabling context sensitive support elements

A dynamic user interface (UI) is a componentized UI in which components display and disappear based on some dynamic behavior. Dynamic UI application programming interfaces enable you to add transient pages and portlets to the portal user interface. Transient pages are created based on the definition of an existing page and are then added to the navigation along with contextual information. Transient portlets are based on portlet definitions; transient portlets can be added to transient pages. A portlet can launch a dynamic UI using the Dynamic UI Manager API, which is part of the Dynamic UI Management feature introduced in WebSphere Portal V5.1.0.1. Because of its dynamic nature, the interface is not persisted in the portal database, and has a maximum lifetime of the user's session with the portal. The interface can be closed prior to the end of the session either programmatically or by the user.

In the scenario above, Dynamic UI management is used to add and remove portlets on a dynamic page on demand.

(See the Dynamic user interfaces section in the WebSphere Portal Information Center, in Resources.)

Example 3. Contextual portal: Information gathering

Bob sometimes accumulates data from different applications (pages) and then transfers the data into the primary form.

The following sample context-exchange solution (which could be implemented as a portlet) shows how to store and retrieve context-related information for consumption by other applications (such as data entry forms).

Bob could collect and store all necessary information for feeding to the main form (on the target page) within the context-exchange portlet. As he visits the various portal pages which provide him with necessary information, context-related data items are stored within the context-exchange portlet. The accumulated data is then automatically propagated into the primary form. This process is illustrated in Figure 9. You can use WebSphere Portal cooperative portlet capabilities to store data in the context-exchange portlet and to propagate the data into the primary form.

Context-exchange portlets can support multiple independent sets of accumulated data. For example, Bob could start accumulating data for one customer who requests a booking by fax. Then, suppose a customer walks into the agency where Bob is working and requests another booking; that customer's request is temporarily a higher priority. Bob can pause his work for the first (faxing) customer to help this customer who is requesting a booking in person. Then, after completing the booking for the customer that visited the agency, Bob could continue with the booking process for the customer that booked by fax. So, the context-exchange portlet can help employees who work in environments where they are often distracted from their usual workflow.

The context-exchange portlet can be pre-populated with default information based on the context in which Bob started to work. Such information could, for example, be taken from Bob's user profile (his name, e-mail addresss, postal address, and so on).

The context-exchange portlet can be displayed on-demand as an additional dynamic portlet and closed when not needed anymore.

Figures 10, 11, and 12 illustrate the scenario where Bob collects data to book a flight, hotel, and car from different pages, store the data in a silo of the context-exchange portlet, and then propagates the collected data to the primary form (on the target page).

Example 4. Contextual portal: Notifications

The contextual portal provides the user with information he really needs within the context in which he is currently acting. It does not distract the user with unnecessary information.

You can use standard Web programming techniques to inform users about special tasks and events. For example, you could implement portlets which exchange data using Click-to-Action, cooperative portlet, or other PropertyBroker techniques. So, you could inform Bob about an upcoming meeting, even if he is not currently working with the portal (for example, he could be reading a comprehensive review of a new hotel on a portal page).

Figure 13 shows that as soon as certain events arrive, an alert is blended into the theme. The user does not need to click anywhere or to perform any action at all; these alerts just appear when they arrive dynamically (a push-model). In the sample, Bob is informed about an upcoming appointment. For example, suppose the alert is based on Bob's calendar entries. When Bob clicks on the alert, he sees the corresponding entry for his calendar in a portlet so that he can check the details.

You can enable such alerts to dynamically appear (without forcing the user to perform any action) using AJAX (Asynchronous JavaScript™ and XML). Data is pulled from the browser client asynchronously (using a JavaScript call), without blocking or reloading the currently displayed browser page. The data is inserted into the currently displayed page through JavaScript DOM manipulations applied to the currently displayed HTML markup.

Back to top

Conclusion

Using dynamic capabilities of WebSphere Portal within portal components and portlets to transform a static portal into a contextual portal improves user productivity and user experience. The contextual portal supports recurring user behavior by taking contextual information into account or by learning from a user or user group's previous behavior.

The four sample scenarios in this articles illustrated potential enhancements to static portals and demonstrated how the contextual portal can improve user productivity. The contextual portal eases navigating through large and complex navigation hierarchies, optimizes the use of operation-supporting elements, helps you provide concise layouts which increase usability, facilitates the exchange of context (data) between applications, and enables you to inform users about context changes at nearly any time. Contextual portals help enterprises exploit additional benefits achieved by providing centralized access to information and applications that go beyond a static role-based user experience.

Back to top

Authors' note

For added optional benefit, screen cam recordings illustrating a sample implementation of the scenarios described in this article are available for you to download. If you wish to play these recordings, you will need to have the basic Camtasia Player downloaded and installed on your local machine.

Back to top

Downloads

Description	Name	Size	Download method
Demo in AVI format, requires Camtasia Player	scenario1.zip	7.2 MB	FTP|HTTP
Demo in AVI format, requires Camtasia Player	scenario2.zip	5.5 MB	FTP|HTTP
Demo in AVI format, requires Camtasia Player	scenario3.zip	9.3 MB	FTP|HTTP
Demo in AVI format, requires Camtasia Player	scenario4.zip	1.3 MB	FTP|HTTP

Information about download methods

Resources

• Participate in the discussion forum.
  
  
• WebSphere Portal Documentation Library and Information Centers (all versions)
  
  
• Wikipedia: Web analytics
  
  
• Wikipedia: Web log analysis software
  
  
• Wikipedia: AJAX (programming)
  
  
• WebSphere Portal Information Center: Dynamic user interfaces
  
  
• WebSphere Portal Information Center: Site analysis
  
  
• WebSphere Potral Information Center: Overview of cooperative portlets
  
  
• [Ram01] Ramesh R. Sarukkai. Link prediction and path analysis using Markov chains. In proceedings of the 9th international World Wide Web conference on Computer networks : the international journal of computer and telecommunications networking, pages 377_386, Amsterdam, The Netherlands, 2000. North-Holland Publishing Co.
  
  
• [Jia02] Jianhan Zhu and Jun Hong and John G. Hughes. Using Markov Chains for Link Prediction in Adaptive Web Sites. In Soft-Ware, pages 60_73, 2002
  
  

About the authors

Stefan Liesche is a Certified Senior IT Architect in the IBM Development Laboratory in Boeblingen, Germany. He has 11 years of experience in the software development field. He holds a master of science degree in computer science from University of Hildesheim, Germany. He joined IBM in 1998 as part of the services group where his speciality was designing large-scale end-to-end e-business solutions for complex environments. Stefan has been working with IBM WebSphere Portal for years. He first worked on the construction of large-scale portal solutions before joining the WebSphere Portal development architecture team. He is the Lead Architect of Workplace and Portal Foundation.

Andreas Nauerz Andreas Nauerz works as Software Engineer in the IBM Laboratories at Boeblingen, Germany. His current work areas include Business Process Integration and Dynamic UI Management. He studied Computer Science at the University of Cooperative Education of Mannheim, the University of Staffordshire, the University of Saarbruecken, and the University of Hagen, respectively.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• What is a contextual portal?
• Comparing today's portals with a contextual portal
• Working with a static portal
• Working with a contextual portal
• Conclusion
• Authors' note
• Downloads
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers