This chapter is from the book
This chapter is from the book
This chapter is from the book
Portal Design
The most important functions of a Web portal are to aggregate content from several sources and to personalize the presentation for each user or user role. Our example portal for the catalog exchange service is called MyCat. This portal allows users to personalize their selection from a variety of content sources, including a category browser, product search, current promotional discounts, and so on. Each user can choose which sources to display, where to display them on the screen, and what colors to use for text and background.
A Web page as viewed in a browser is often the result of combining the output from several server-side components. Each component, or portlet, is responsible for producing a part of that page and is dedicated to one of the aggregated content sources. In the simplest architecture, one component might be responsible for the heading and menus, another for the footer, and a third for the main body of the page content. A page, however, can be decomposed into any number of regions, and a component can be assigned to produce the content within each region. A portal server provides a framework for configuring (and reconfiguring) the regions, including their size, relative location, presentation style (often called "skin"), and assignment of a component that will produce each region's content.
This architecture and terminology is used by the open source Apache portal server named Jetspeed.2 The Jetspeed server is used in Chapter 11 to illustrate portal design and especially to describe XML to HTML transformation using XSLT. A sample screen shot of Jetspeed used to present our demonstration MyCat portal is shown in Figure 5-3.
){kind=link}
Figure 5-3 MyCat portal screen in CatX application
The Jetspeed portal framework controls the overall screen configuration in this example. Each sub-pane is produced by a separate portlet, and each portlet draws its content from one or more XML documents, which are combined and formatted by an XSLT stylesheet. The requirements for each of these functions is summarized by the following use case descriptions.
Design Portlet
A portlet's design determines the content and appearance of one region within the portal screen. The following design questions must be answered.
What is the source of content data (for example, file name, URL, database)?
How frequently will the data be refreshed?
What is the source data format (for example, XML, HTML, comma-delimited text)?
If the source is XML, what vocabulary schema defines its structure?
What kind of filtering is required to personalize content for the current user?
What content language is required for the current user?
How will the data be presented? What is the layout structure, color, font, and style?
How much space is required for its presentation?
What interactive controls are required (for example, edit, search, submit)?
Let's narrow our focus to one of the portlets shown in the MyCat portal. Figure 5-4 shows the product display portlet that presents the details about one product selected from the catalog. As shown previously, the XML document used to produce this portlet was authored in XMetaL.
){kind=link}
A portlet is not required to include the title bar and control buttons as shown in this example; these design decisions were made as part of this use case. This portlet could also be displayed with a plain border or with no border or title at all. These simple configuration choices are available in the Jetspeed portal framework and in most other portal server products.
As you'll see in later chapters, the CatML catalog vocabulary includes links to other product detail resources in addition to the description shown in this portlet. The Edit button should allow users to customize their presentation either to include more detail or exclude the description as desired. The other control button allows users to display this portlet as full screen.
In the prototype application underlying this portal, portlet content is read from a file named Products.xml that contains data structured according to the CatML vocabulary. One of the elements in this XML document contains a URL reference to the product image, so the image file may be co-located on the same server or retrieved directly from the vendor's site. Given this information we need to design the content template for this portlet's presentation and select an approach for transforming the XML data into HTML. These decisions are the result of the next two use cases. You can trace these dependencies in Figure 5-1 where the Design Portlet use case includes Design Content Template.
){kind=link}
Figure 5-4 Product display portlet
Design Content Template
A content template determines the structure of data presented in an individual portlet. In the spirit of proper use case specification, I make no assertions about how the content template is implemented; a use case only specifies the goal that must be achieved and a course of action that is followed when an actor invokes the use case. The primary goal in this case is to specify which product data items should be displayed and how those data should be positioned within the portlet. In the example shown in Figure 5-4, the CatML elements for product name, sku, list price, description, photo URL, and supplier are positioned within a simple two-column table structure for presentation.
There are many alternative choices available for implementing a content template, although some of these choices may be restricted or determined by your particular portal framework. Some portal server products are based on JavaServer Pages (JSP) and Enterprise JavaBeans (EJB) for their portlet implementation; others might depend on Active Server Pages (ASP). The Apache Jetspeed portal has a flexible architecture that could include the results of a JSP within the portlet content, or the content may be produced by a completely custom Java class implementation. However, for flexible rapid development, a Jetspeed portlet may use an XSLT stylesheet to both structure its content and to transform the XML data into that that structure. The next use case is optional but may be included to implement the content template and/or specify the XML data mapping.
Create Stylesheet
The stylesheet accepts XML data as input, then filters, reorders, summarizes, and presents the data as required to populate the content template. But the final presentation style applied to that data is partly determined by the user's device that displays this portlet. You could extend the use case diagram shown in Figure 5-1 to include several specializations of the Create Stylesheet use case. Similar to the way that Create Content has two sub-use cases that describe requirements for specialized types of content, you could define additional use cases for Create HTML Stylesheet, Create WML Stylesheet, and so on. Each would address the unique requirements of those presentation formats.
A portlet is not necessarily limited to a single stylesheet. Rather, a portlet is often designed with a set of alternative stylesheets, where each is specialized to a particular client application, such as Microsoft Internet Explorer or Netscape Mozilla, or to a type of device, such as a desktop PC, mobile phone, or PDA. The portal server dynamically selects an appropriate stylesheet for each portlet when a user's browser requests the portal Web page to be displayed.
The UML activity diagram shown in Figure 5-5 illustrates the decisions required to select a stylesheet for a user's device. The first decision uses information provided in the HTTP header to determine the user agent type and version, then the flow branches one of three ways. The HTTP header information also declares which MIME types are accepted by that user agent, thus determining whether a mobile device can accept advanced stylesheets using WML Script. The Wireless Markup Language (WML) has been standardized as part of the Wireless Application Protocol (WAP).3 WML documents are similar to HTML documents, but the markup language is specialized for the requirements of small Web browsers in mobile devices.
){kind=link}
Web browsers contained in mobile devices are similar in concept to the familiar desktop browsers, but their capabilities are much more restricted. The most important point to remember from this use case summary is that a common XML document can be transformed into alternative presentation markup languages applicable to each of these device types and capabilities.
Figure 5-5 Activity flow for selecting a stylesheet
XSLT is a powerful transformation and presentation language that can fulfill many of the portal requirements listed in the introduction to this chapter. One XSLT stylesheet may aggregate the data from several XML source documents, where the specific source documents and elements from those documents are selected by the stylesheet rules at the time of presentation. Conversely, a stylesheet may disaggregate a large XML document by filtering its content based on stylesheet parameters. The stylesheet can also create HTML or WML hyperlinks in the presented portlet content based on a variety of advanced linking elements included in the source XML documents. However, the processing overhead of XSLT requires careful attention to caching of results in order to assure a scalable portal server. All of these XSLT features are described in greater detail in Chapters 10 and 11, along with examples of transforming CatML into HTML.
Design Portal Layout
Review Figure 5-1 to reestablish your context for this next use case. Assume that a Web application specialist has designed several portlets that pull their data from a variety of different sources. Each portlet design has made its own choices for structure and presentation of its data; the portal itself is not concerned with these decisions. However, the overall portal framework contributes configuration control and layout algorithms that are applied to the current set of portlets selected for display.
The portal layout may differ radically when viewed from alternative client devices. For example, a mobile phone cannot display all portlets simultaneously positioned within a large screen. Instead, a mobile phone treats each portlet as a card in a stack, and the layout must include navigational controls that enable a user to select the current portlet from a structured menu. In this situation, the portal layout is focused on navigational rather than positional layout within a screen, although both are equally important in their own contexts.
The specific details of how these layout algorithms work and how a designer applies them are not critical to this discussion. Each portal server vendor has made its own unique choices for how this is done, based in part on the underlying software platform used for the portal server implementation. Some additional details of portal layout are provided in Chapter 11 where I describe Jetspeed's Portal Site Markup Language (PSML) applied to the design of our CatX portal implementation. But first we must continue to focus on how such a markup language is designed.
Customize Portal Layout
One of the ubiquitous features of Web portals is the ability for each user to personalize the portal content and presentation style. In most cases, an end-user cannot create substantially different portlets but can pick from a set (maybe a very large set) of predefined portlets designed by the portal Web specialists. Figure 5-1 shows a Consumer interacting with the Customize Portal Layout use case; that use case includes the results of the portal layout design produced by the Web specialist.
The most radical customization allowed by portals is for a user to add or remove portlets from his or her current display. This permits the user to alter substantively the information aggregation provided by his or her personalized view. The second most significant customization is for the portlet designer to include an "Edit" control on the portlet title bar that gives a user control over the content of an individual portlet. The design of such a customization is very specific to each portlet's implementation. A good example of this feature is the stock ticker portlet available on most mass-market Internet portals. In this case, the Edit button allows, at minimum, customization of a user's preferred stock portfolio.
The third type of customization allows a user to control the skin applied either to individual portlets or to the portal as a whole. The term skin is frequently used in consumer-focused Web applications. Its implementation and capabilities vary. In the simplest case, a skin defines the background color, text color, and font applied to the display; in more advanced designs, a skin defines a collective theme of styles, button images, background wallpaper, and so on. Most business-oriented portals support skins that customize fonts and colors.
When the portal is viewed from small devices such as mobile phones, the customization should allow users to control order and hierarchy of navigational menus, in addition to the other customizations described above. The specifics of mobile device Web applications are beyond the scope of this book, but it's interesting to speculate about where they are headed.