Paul Everitt Digital Creations 2000 Digital Creations

Web sites today are about much more than document delivery. They are focused on doing business online. One particular class of web sites is the portal. Though portals are particularly poorly defined, two definitions are useful. First, Jakob Nielsen defined a portal as "the big three": news, search, and directory. Builder.com classified different types of portals, ultimately claiming that "the most popular features of a portal are Web searching, news, reference tools, calendaring, and communication capability." The Zope Portal Toolkit (PTK) project uses a definition that leverages what's good about Zope and the patterns Digital Creations sees in its consulting practices. Thus the PTK has a portal vision. A portal is a window into an organization's practices and processes. The purpose of the portal is building relationships and establishing gravity for an organization to attract readers and contributors, and to organize and manage diverse content. A key feature of a portal is that it is centered on the user (aka member). Its goal is to provide a highly user-centric user-dependent view of the organization's brand and resources. The PTK provides two very important pieces: a framework for constructing custom portals, and an out-of-the-box, useful sample portal. These two pieces are critical to remember, as the PTK aims to be both a framework and a product. The key services provided by the PTK are as follows: Search. The PTK leverages the ZCatalog to provide high-speed fielded and full-text searches of portal content. Since PTK-aware content notifies the ZCatalog when it is modified, the index is rarely out of date. Directory. PTK content can be organized into a hierarchical topic/subtopic system like big portal sites. Each topic acts as a virtual Zope folder, where the contents are specified by a ZCatalog query. Each topic, though, can contain regulary Zope objects such as graphics, templates that customize the presentation, and even discussions. Topics can also provide an RSS feed to syndicate content into channels. Under this system, content can appear in multiple places on the site on the basis of the content of the content, meaning the body text or properties. Membership. The most visible part of the PTK is the membership system. As discussed below, PTK membership extends the Zope user model to include cookies, external data, an arbitrary properties. Members can join automatically, the entire process can be customized, and members get their own area to work in. The last part is the biggest difference with a PTK portal versus other portals. With the PTK, content is generally authored in a member's area, then placed into the "public site" by means of the catalog. The goal is to let members think very clearly about "their stuff". When they want to add a news item, rather than transporting them to the news item area, just let them create a new item in their area. Thus, the PTK is focused very much on a me-centric model of content. Reviewing. By default, when a member authors a piece of content, the content isn't part of the "public site". When a member requests that a piece of content get reviewed and the content is approved, it becomes part of the "public site". The PTK includes extra roles to help this model. First, Managers can turn Members into Contributors, meaning their content doesn't require review. Next, Reviewers receive email notifications and can approve content that needs reviewing. The goals of reviewing are straightforward. First, Members with insufficient privileges should have their new content reviewed before it is visible. In this case, visible means the URL to the content should not reveal the content, the content should not show up in searches or topics, and the content should not be syndicated. However, there is more to the policy than this. First, different Members might have different authority. For instance, by default the content managed by Contributors needs no review. Next, the decision about whether an object is visible is different for each role. That is, a Manager should be able to view or search for anything. Most sites will also want to make reviewing extend to edits and even deletes as well as additions of content. Additionally, content can move between a reviewed state and an unreviewed state. In many cases one Reviewer might decide to override another's decision. When many Reviewers are involved, they need to efficiently get a list of the things in the queue. As Reviewers perform actions on content, these reviewing actions need to be recorded, perhaps including comments about the action. The PTK architecture accomplishes this set of goals with a combination of reviewing metadata, connections to the standard Zope permissions machinery, and metadata in the SiteIndex, which is the default ZCatalog for the portal. Syndication. PTK provides facilities that assist in creating RSS-based channels for content syndication. The PTK does not currently provide a facility to syndicate remote content. Integration. The goal of providing a single view of diverse organizational content means that the PTK needs to integrate external data into the content management system. The first steps have been taken by allowing membership data to come from external sources. The PTK also includes a number of sample kinds of content: Document. This is where most of the content and pages on the site will be created. News Item. Link. Discussion. The key benefits for a Zope PTK portal are as follows: Me-centric content. As discussed above, members author content in their areas, then let the catalog place the content into the appropriate place. Members get a clear view of "their stuff". Turning over control. Members can create specialized forms of content in their own member area which can be woven into the portal site. Reinforces benefits of Zope. With portal content represented as Zope content, many of the Zope benefits apply, such as versions and undo. Extensible. The PTK framework was designed from the beginning to be easily altered and extended. Dynamic. All pages, including searches, are up-to-date. All aspects of the system can be tailored to individual users. High performance. PTK-based sites should start at a million hits a day on a cheap machine and go up from there.

While the original goal of the PTK was to provide a foundation for creating portal software, the PTK also provides an out-of-the box ability to create arbitrary portals. This chapter discusses how to create and use a portal from the various audience perspectives.

In order to begin with the Zope Portal Toolkit, you need a working Zope installation. Next, you need to download the PTK software product from Zope.org and, following the instructions there, install it and restart your Zope site. When the PTK is correctly installed you will see Portal as a new kind of object in the add list for a Zope folder. If you have installed the PTK software but don't see "Portal" listed, go to the Control Panel in the Zope site, look in the Products folder, and see if the PTK software is listed as a broken product.

Let's make a portal. Start by logging into your Zope site as a manager and going to the folder where you'd like to create a portal. Choose Portal from the add list. The process for creating a portal is unlike the traditional Zope "add form" system. Since one of the main focus points for the PTK was usability, a PTK portal is created using a friendly, verbose, multi-step wizard. On the first screen, provide an id and a title for the portal. On the next screen, choose a default theme and layout for the members, including the public view. Next, provide the default configuration information. This includes email address and policies for membership. Next, the portal needs some default members to administer the site. Create a membership for the manager of the portal site. On the next screen, decide if you want default sample content in your portal site. If you do, this step will take a while as the content is added and indexed. Congratulations, you have a portal site! The last screen of the wizard provides the URL to the new portal. Clicking on the URL launches a new browser window that displays your portal.

Now that you have a working portal, let's take a look at how people become members of your portal. First you need to start a fresh browser that contains no login information for the Zope site. For browsers such as Netscape on Windows, this means shutting down all running copies of the browser. For IE5, however, you can just doubleclick on the IE icon to start a new browser. With your new browser, go to the public URL for your portal site. The "Members" box should indicate that you have not a logged-in member and should provide a link to join. Click on the Join link. The portal then provides a page that shows the use policies of the portal and collects some basic information. Click Join Now! to sign up. By default the portal will ensure that you have a valid email address by sending you the login information by email. Thus, check your email and click on the hyperlink to configure your membership. The page presented will ask you to supply a new password to replace the randomly generated default. Update your password and click Login. The portal provides a "first login" page where the portal's membership is introduced, including a link to the help system. Click on View Site to begin browsing the home page of the portal. You'll notice at this point that the portal page looks slightly different. First, the "Members" box has changed to show who you are logged in as and to provide some extra controls, such as MyHome and What's New. Also, the search form for the site and the news display are configured to remember your last login time. Finally, let's investigate the personalization options available. On any page, click MyHome to go to your area of the portal. Note that the URL for your membership area is [portal URL]/Members/[your id], and the URL to manage your . Since you are logged in and you are in your area, you see the URL differently. Become a member, personalize site, create page, create survey.

Create page, create survey, view membership listing

Approve content, raise status on member,

Change portal look and feel, extend membership properties, change login procedure.

As mentioned above, the PTK architecture is designed to leverage Zope and to be extended as a toolkit. The PTK exists as a Zope Product, which is a set of code and data that is installed into a Zope distribution to create new kinds of things that can be created. Installation of the PTK Zope Product does two main things: install the framework into the Control Panel of Zope, and make Portal a new kind of thing that can be added to a Zope Folder. The Membership component of the PTK adds a number of major pieces over the standard Zope acl_users functionality. First, membership data can be extended to collect arbitrary properties about users. Next, the membership data can come from a relational database as well as the Zope object database (ZODB). Users can be authenticated by cookies as well as HTTP authentication. Additionally, the entire process of handling users is exposed to customization through the Control Panel. Finally, users are associated with a default Home Folder, similar to home directories in various operating systems. Allowing the membership data to be stored in a relational database provides a number of benefits. First, some people just feel better with that data being external to Zope. Second, Digital Creations has been consulting with customers that wish to have millions of members, and these customers feel that a commercial database server will scale better. Third, some membership data might already be collected in a database. Finally, storing the data externally allows other applications to access membership information. These are all major architectural changes over the default Zope facility for User Folders. In the PTK, the content is stored in the ZODB. This delivers many of the crucial facilities. The catalog, which provides much of the strength in the PTK, is a ZODB facility. The new products packaged in the PTK software are a combination of ZClasses, Python Products, and Python Methods. Note that the PTK membership architecture does not provide one facility long hinted at: per-application preferences. That is, application developers are not given a facility to store per-member configuration information with the member. The PTK adheres to the Dublin Core metadata initiative for the attributes used in content. The relevant data elements are identifier, title, creator, subject, description, type, and date.

The portal toolkit turns over control in a system of gradually increasing roles. Each of the following correspond to a kind of actor in a portal. Guest. This is the role for unauthenticated non-members, namely the general public. Member. Owner. Contributor. Reviewer. Manager. Administrator.

The PTK provides much new machinery for Zope, but also aims for another goal. Zope itself was designed as a platform, not an application. Thus, the classic Zope management environment was by need quite verbose and not immediately discoverable. The PTK, though, works very hard to be a new breed of Zope application. Particularly, the PTK interface was designed to be simple. Fewer knobs are provided, multi-step wizards provide verbose descriptions of steps, and users are visually reminded of things like Undo. A link to the classic Zope management environment is provided as a fallback into a "power user" mode. Additionally, the work on a next-generation "Zope Studio" might yield a "fall forward" into a more powerful interface for portal management. In short, the classic Zope management interface focuses on both content managers and developers. The PTK-specific interface examines what can be done when only content managers are the focus. Here are the differences of the PTK interface from the classic Zope interface: Focused on content managers. This is the overarching design goal. Stripped down. Content managers seldom use all the knobs in Zope. If they need them, Advanced is just a click away. Continuous browsing and managing. Zope currently gives quite a "thunk" when changing from viewing to managing. The PTK interface combines the two modes. First, the look and feel of the site is shared in the management mode. Second, managing is usually just browsing with a few extra control areas inserted. No frames. Using a frame-oriented management screen often leaves new Zope users in a weird state when switching between browsing and managing. Cleaner desktop. The desktop area has no tabs and the add list is replaced by a button that leads to a more descriptive, helpful content creation facility. More natural manipulation. Clicking on items in the desktop leads to viewing the items. To manage the item, users then click on the control to shift into management mode. More importantly, to manage an item while viewing it is just one click to switch modes. More verbose. The PTK design exchanges a terse, productive interface for a verbose, helpful interface. Content creation is broken into multiple steps (i.e. wizards). Structured Text. The content creation facility in the PTK is more oriented towards structured text. Zope.org was a first step in this direction. This means, obviously, the structured text will be better documented and will be "pre-compiled" rather than re-parsed on each request. Only PTK-aware content. The only things that can be added are the PTK-aware things. This means that all the kinds of things seen by PTK authors have the new, easy interface and wizard-driven creation. Contents in batches. The items shown in the desktop are shown in batches, with controls to browse between batches. More prominent safety net. In the box on the page that has management controls, Undo is displayed prominently. Thus, wherever you are, recovery from a problem is just a click away. The interface is designed to become part of the browsing interface, rather than a separate interface. Thus, the pages do not change very much when moving between a browsing operation and a management operation. There are two major regions of the page for the interface. The first is the Member Box, as mentioned previously. The second is the Desktop. This region displays the page contents when viewing a resource, and displays the management view of a resource or a folder when managing. The PTK interface has a number of style provisions. Optional fields on forms are in italics. Links that lead to another step have ellipses after them, such as New....

Though the PTK is most definately a toolkit, it most definately aims to be a working portal as well. This part covers the functionality available to members that read and author content: Browse The Portal Membership management. Create Content.

Member enters URL. Portal returns page with layout and default theme chosen by portal creator.

The first membership service provided for guests is to become a member. This is provided by a Join link in the Member Box. The Guest clicks on Join. If the browser already contains login information, the Already Logged In page is displayed. Otherwise, the browser really is a guest and the Join Form is displayed. The Join Form asks the Guest to provide basic information. By default this includes the following: id. Must provide a unique string. Note that this string becomes the URL to the new member. title. email. isPublic. Reminder Question. Reminder Answer. chrome. The information collected can be extended quite easily by the portal manager. See Manager Extends Membership Definition for more information. The Guest fills in the form and clicks Join. The portal verifies information provided, sends an email, creates a member with a random password, and returns a response form. The response form informs the guest that they will receive an email containing their initial password and instructions to complete their login. The email contains a welcome message, a hyperlink to complete the login, and an email address to send questions. The guest then reads their email and clicks on the hyperlink to complete the login. The portal returns the Complete Signup page, requesting that the guest change their password. The guest provides a new password plus a confirmation password, then clicks Complete. The portal returns the Welcome page and sends an email with the official introduction, including the new password information. At this point the guest is officially logged in as a member, getting a permanent cookie. The page provides the essential information for new members, such as a tour of membership facilities, a link to the help system, and most importantly, a link to get started. This last link returns the member to the portal home page.

By default, PTK portals assign permanent cookies to identify members. In many cases, though, these cookies will get lost. Thus members need a facility to log back in. To start, a member goes to a portal page, which identifies them as being a guest. In the Member Box the guest clicks on Log In. The portal returns a

On the Log In page, a Guest is asked for the login information. If the Guest can't remember the login information or if the login information remembered is wrong, the portal needs to help the Guest remember the login information. The Login Page contains a control saying Forgot Your Password? Guest clicks on control and gets a page asking for the challenge question and challenge answer entered when the membership was created. If the Guest provides this information correctly, they are logged in and the account information is emailed. If the information is entered incorrectly, a warning is displayed and a link to send an email to the Managers is displayed.

Guest clicks on Log in. Provides username and password.

Member visits portal. Portal returns home page. Member clicks in Member Box on Personalize. Portal returns personalization form, containing email address and choice of chrome, plus some view-only attributes such as last visit date/time and current roles. Member also chooses Beginner or Advanced mode, which determines whether they see Wizards one-page at a time, or all in one page. Member fills in changes and clicks Save. Portal sends an email with the changes and returns the Member to the page they were browsing when the Member click Personalize.

Include searching.

This chapter discusses the general facilities for creating content, such as upload, FTP/WebDAV/Netscape, undo, versions, creating folders, etc. It then goes into management of each kind of content.

Member visits portal and clicks on My Stuff. Portal returns the desktop. Member clicks on New... Portal returns Create New Content page. This page contains a list of kinds of content a Member can create, with paragraphs describing each kind of content. Member clicks on Document. Portal returns Create New Document page, the first page of the wizard. This describes what will happen in the process of creating a new Document. The Member supplies an id, title, and optional description, per the Dublin Core specs. The explanation notes that description and title are searchable, along with the body. The Member then chooses whether they want to type the content in or upload the content. The Member provides the information and clicks Next.... The next page in the wizard discusses the body of the content and provides controls for specififying the body. If the Member chose to enter to content online, a textarea appears, otherwise an input for a file upload appears. Below this, a selector appears for the format, with a choice of Structured Text, HTML, or Plain Text, with the first chosen by default. Format is a hyperlink to help that describes the three formats, particularly Structured Text. The Member clicks on Next.... Obviously, since the content might be uploaded, the content is actually created at this point. The introductory paragraph explains this. The next page of the wizard collects the cataloging information. The PTK attempts to leverage Dublin Core, so this information is called Subject. A paragraph describes what happens, stating that the Member will provide the metadata and optionally request that the content become part of the site. The user supplies the topic information and chooses yes or no to request addition to the catalog. The member then chooses Next.... The Finished! final page of the wizard lets the Member actually create the content item. It explains what will happen when the content is created. The wizard displays what the URL will be for the new item. It also notes that, if this was a mistake, the Member can click on Undo to remove the creation of the item. Member clicks on Done. Portal creates the content and goes to a page displaying the content. If the Member is in Advanced mode, they see all the options on one page with no verbose text, just labels. That is, they see id, title, optional description, optional textarea, optional file upload, format, and subject.

Member clicks on My Stuff. Clicks on New... Clicks on Image. Provides id and title, clicks Next... Member provides the upload file, clicks next. Portal creates the Image. Member provides cataloging information, clicks Next... Wizard shows Finished! screen, which shows the URL for the Image and explains how it can be referenced. Member clicks Done! and views the new Image. If the Member is in Advanced mode, all the options are shown on one page.

Member clicks on My Stuff, then New..., then Link. Wizard is the same as Document, but the second step collects a URL and not a TEXTAREA for the body. the description is the only thing used for indexing purposes.

Goes to page, clicks on Manage Page.

Member clicks on Undo. Desktop fills with last five operations the Member performed, with much of the same text explanation from the current undo screen.

afasf Stuff

Creating a portal is a wizard-driven exercise. As such, it is reasonable to permit a setup where members or even guests

All members, in batches.

Include browsing management screen

Layout and theme

SQL and property sheets

This is ...

Follows Dublin Core. identifier, title, creator, type, date.

subject, description, body, reviewing status, .

Dublin Core A set of conventions... Product Member Manager Administrator Anonymous Reviewer Contributor Home Folder RSS Channel Topic Content Theme Layout Structured Text Desktop Member Box