If simply planning personalization is so involved, actually implementing it must be a nightmare, right? Fortunately WebLogic Portal 8.1 is equipped with the tools to apply personalization relatively easily. There are two primary modes of applying personalization. You can set entitlements based on roles to the fundamental portal resources, including desktops, books, pages, and portlets. More advanced personalization functionality can be achieved with content selectors and placeholders that work in conjunction with the Virtual Content Repository (VCR). Implementing a well-planned personalization model with these tools can allow you to flexibly target content based on a dynamic set of factors.
Both methods of personalization work with user profile attributes. You must first define which attributes you need to capture. Then you must define the values for the attributes for each user. The maintenance of the user profile information is facilitated by the use of groups. By assigning a set of values to the attributes of a profile that is assigned to a group, all users in that group will inherit those values on their individual profiles. By changing the profile values for a group, you can more easily maintain the profile values for many users.
The following two sections look at each of these approaches in turn.
There are two ways to leverage WebLogic Portal 8.1 functionality to deliver personalized content. One way affects the content container while the other affects the content itself. I'll begin by looking at the simpler of the two forms of applying personalization: setting entitlements to a portal resource. A portal resource is a content container such as an entire desktop, a book, a page, or a portlet. Using the WebLogic Administration portal, you can select any portal resource, the role you would like to administer for the component, and the capabilities (view, edit, remove, minimize, maximize) pertaining to the component.
Table 1: Capabilities the can be administered based on the type of portal resource
For example, if you have an Executive dashboard page that should be viewed only by members of the board, you would select the Executive dashboard page, select the "Executive" role, and select the "View" capability. You are directing the system to display the Executive dashboard only to those users who have been assigned the role of "Executive." Any user who is not assigned this role will not see the page.
Roles provide flexibility for applying personalization to portal resources, and Figure 1 provides a summary of the way in which roles can be applied.
Figure 1: Roles and their application in personalization
Roles can be assigned in three ways. You can directly assign individual users to roles. You can group users into groups and assign those groups to a role. Finally, you can create role expressions that dynamically assign roles to users based on characteristics from their user profile. For example, a role expression named "New York Senior" can be automatically assigned to all users who have the attributes of Location = New York and Age >= 65 on their user profile. By applying a view entitlement to the NY Senior Benefits portlet tied to this role, only users from New York who are at least 65 years old will see this portlet.
Portal entitlements apply to the container of the content. It is one-dimensional personalization based solely on the user. With WebLogic Portal 8.1 you can also implement two-dimensional personalization based on both user attributes and content attributes using either selectors by themselves or placeholders used in conjunction with campaigns.
Two-dimensional personalization is powerful because it displays content to users based on both who the user is and what the content is. It is achieved by using a user query that is linked to a content query to render targeted content at a specific location on a page. You can display certain types of content to certain types of users based on user properties and content properties.
Example: If user eye color = blue and size = large, display content that has type = promotion, merchandise = clothing, color = blue, and size = large. By coupling users and content based on how users and content are described, you are able to target content based on complex observations. In this case, people who are large with blue eyes are more likely to purchase blue clothing that is available in large sizes. Concurrently, the same piece of content can be used on another page that lists all blue merchandise where if user = visitor display content that has color = blue.
The user query determines who is allowed to see the content. It operates on the attributes defined in user profiles, system values (for example, HTTP session properties), and/or user events. For frequently used user attribute value combinations, you can define user segments. Referring to the example above, you can define a user segment called "Big Blue" defined by the conditions color = blue and size = large. You can then use this single segment in user queries in place of the two attribute value pairs it represents. If you update the segment definition, all user queries that refer to the segment will be affected accordingly and automatically. User segments work with content selectors and placeholders/campaigns in a manner similar to roles with role expressions working with entitlements/portal resources.
The content query determines what content to display. It operates on metadata assigned to each content file. To query content you must have it described in a well-defined manner. The VCR has the facilities to define and manage content metadata. Just as users are assigned profiles that characterize who they are, content has metadata that describes the content itself. The metadata provides the properties that can be queried. You can define custom types of content by creating sets of properties. Essentially you are creating metadata templates. When you add new content, you select the content type (that retrieves a metadata template that you created), which in turn drives which properties you must assign values for the specific piece of content. The content query operates on the metadata that has been assigned to each content file.
With users described by their user profiles and content described by its metadata, you can target certain types of content to certain types of users. If the user's properties meet the conditions set in the user query, the content that results from the linked content query is rendered on the page.
With WebLogic Portal 8.1 you can target content based on the combination of user attributes and content attributes using mechanisms that link user queries with content queries. Content selectors link a user query and a content query by default. Placeholders have only a content query, but you can associate a campaign to a placeholder to effectively link a content query with a user query. Either content selectors by themselves or placeholders with campaigns can be used to target content.
Content selectors serve as "content buckets" that are placed on a Web page at a specific location. Each selector has a user query and a content query, both of which can reflect compound conditional statements operating on multiple criteria. If the user matches the criteria as specified in the user query, all content that matches the content query will be rendered at the location in the Web page where the selector was placed.
The user query can operate off any combination of the following:
The content query can operate off any metadata assigned to content in the VCR.
In WebLogic Workshop, you can create a content selector file that couples a user query with a content query, as shown in Figure 2. In the example below, all users who have their Graphic Preference equal to "classic" on their user profile will view all content whose name contains "IRACampaign". The content selector file is placed at the desired location on the Web page. All users who meet the user query criteria will view all content that meets the content query criteria at the location on the Web page where the content selector file was placed.
Figure 2: The content selector file in WebLogic Workshop
When a Web page with a content selector is requested, the content selector first checks to see whether the user is allowed to see the selector's content. To do so, it evaluates the conditions as defined in the user query based on the properties of the user. If the user's properties match the critieria, the selector goes to the VCR to evaluate the conditions as defined in the content query. The content query is evaluated based on the content metadata defined for each content file. All content whose metadata matches the criteria is rendered on the Web page. Here is how a content selector works:
Figure 3: How content selectors work