Table of Contents
This chapter will describe the project in detail. In some sense, it will function as the duties specification which is at the start of a good project. It details the customer's expectations with respect to the project aims, the required functionalities, the performance measures, the time frame and the interaction with the customer during the project. Of course, some of these general aspects for duties specifications are irrelevant in our current context and we will not address them.
In the book, we will build a portal for an artist group. A portal, in general, is a common Intra/Internet entry point to a bunch of services and different kinds of information. Usually, it allows visitors to register and become portal members. Portal members are offered special services not available to non-members. Often, these additional services include some form of personalization, usually with respect to what information the portal presents to the member and how this information is arranged.
Our portal should satisfy the needs of an artist group. One of the primary aims is the presentation of the group and her artists to the general public. Thus, the portal includes sections Who we are, Our artists, Events, News, How to contact us, Group statutes, Partners, We assume, there is a wealth of information available about the group, her artists and their work. Therefore, a search facility is essential. As a special feature, the portal should support exhibitions, guided tours through thematically ordered collections of art work.
Another major aim is the interaction with the visitors. The group wants to know, who is interested in her activities and her artists work, what do they think, what they are interested in, what do they like and dislike with respect to the portal, the group's services and the art work presented. This allows her to continuously enhance and improve her services and to focus tightly on the most interested audience. Furthermore, the group is convinced that the feedback possibility strengthens the community sense between visitors and the group. Such community sense is essential for art dissemination. The portal contains a guest book. It allows visitors to post a note about their presence and make comments about their visit. Furthermore, each page allows to provide feedback to the page author.
There are more feedback features for registered visitors, so called friends. A friend is a visitor with a special interest in the group and her activity. Unlike a casual user, a friend is interested to be personally known to the group. He expresses his special interests and the group may send him announcements of interesting events or other essential news. As already mentioned, friends are registered. The registration ensures, that the group gets the necessary minimal information about the visitor. For the visitor, the registration and the associated log in opens up the special friend services. The friend services enhance interaction capabilities and provide for personalization.
Friends can collaborate with the group through a common discussion board. There, they can exchange ideas, provide feedback, suggest enhancements or activities, offer assistance.
Personalization is mainly build around the profile concept. A profile is a criterion that filters relevant from irrelevant information. Profiles can be used for different tasks: e.g. they can define a search that retrieves all items matched by the profile, or filter news items such that only items matched by the profile are shown, or provide a trigger to send an email announcement for essential events. Our portal will use profiles to provide these personalization features.
Furthermore, friends will be able to personalize the portal content with private annotations to most content pages. These are remarks the friend makes for himself to correlate the page with his interests and conceptions. They are seen only by himself. He can search over his remarks.
Another kind of registered visitors are the artists, more precisely the members of the artist group . Of course, they can use all facilities for friends (they are friends by definition). While friends can only provide content seen by themselves (with the exception of discussion items), artists can (and should) provide content for all portal visitors. More precisely, they should provide the descriptions for their person and their work. They should be able to control the target audience for their content: they can specify that an item is private, seen only by friends or visible to the general public.
The portal should provide a collaboration platform for the artists. For this purpose, the portal provides a discussion board, a news service, a group calendar and a tool for the collaborative authoring of documents.
The group has strong relations with other artist groups. The portal supports these contacts through the exchange of news items between the groups. Channel associations control which messages are exchanged. The exchange is performed automatically at specified times.
Artists can offer their work in an electronic shop for sale. They are informed via email about visitor's wishes to buy one of their art pieces. For the visitors, the portal shop maintains a shopping cart with the selected items and the total price. Registered users can access their shopping cart at any time. For other users, the shopping cart is volatile and disappears after some time.
As you can see, the example project for this book is quite demanding and contains many elements found in a large variety of projects. This makes it ideally suited for the purpose of this book.
We will now look at the project from various different viewpoints to get a more precise feeling of what should be done.
This section details the various user classes that are serviced by the portal. As Zope is managed via the Internet, all users are, in some sense, visitors. They can use the services from any point reachable via the Internet. This is true both for anonymous visitors, for artists and for the portal administrators.
Anonymous visitors are visitors (or agents) that access the portal without an authentication process, usually called a log in. As the portal does not know anything about their identity, it must be very careful with the services granted to such visitors. Usually, they can only look at the prepared information but have very limited capabilities to change this information. In our sample portal, they are allowed to look around, to provide feedback, to put an entry in the guest book and to maintain a shopping cart.
If a registered user does not log in, then the portal must treat him as an anonymous user as it does not know his identity. On the other hand, a user must be registered in order to be able to log in. This implies that visitors from all other classes are registered.
Friends are regular visitors that are interested in an intensive exchange with the artist group. They are registered and have provided contact information such that they can be informed about essential events, relevant news or the availability of new art objects.
Friends can define profiles to specify their interest and control which information they receive about the group. They can also select how the information is provided: either as a pull service, i.e. available online at their discretion, or as a push service, i.e. by a regular or occasional email.
Friends can annotate almost all content pages. They can use these annotations to personalize the portal content: e.g. make notices, why this page is especially interesting, put reminders about future actions or link several pages together with the same keyword. A friend can search in his annotations via content, fields or keywords. This allows him to recategorize and restructure the content for his special interests. Annotations are visible only for the visitor that created them, they are private.
Friends can interact with the group through participation in a common discussion board.
In this context, an artist is understood as a member of the artist group. An artist can use all services for friends. Besides, he has an associated content area that he can manage himself. In this area, he maintains his personal description and the descriptions of his art pieces as presented by the portal. He can classify, whether the descriptions are private, can be seen by friends only or are publicly available. If the artist provides special properties such as price, the art object is offered in the electronic shop.
Artists can describe events that may be of interest to either the group or the portal visitors. These events are presented in a calendar to get an easy overview about all relevant dates in a specified time frame.
Artists are provided with a facility for collaborative authoring of documents. These documents can be used to collect suggestions and opinions. They can also reflect the current state of discussions.
The portal administrators are responsible for the overall portal and its content as far as it is not delegated to the artists. They add new group members to the database, decide whether a request for friend registration is granted and grant or withdraw special rights. They have the ultimate responsibility for the group wide resources such as e.g. the common calendar, the discussion board and the news board.
The section describes the various information objects that are managed by the portal. These object classes are not independent but interrelated. There are many is a relations which can naturally be implemented by inheritance in object oriented systems such as Zope. Each object class is categorized by a set of attributes, also called properties, and a set of methods operating on the attributes. This section lists only some of these characterizing elements. The detailed structure is defined later in this book.
A search item is an object that can be retrieved via a search. It must have attributes necessary to provide sufficient information in the search overview. This includes the item type (e.g. news, event, artist, art work, ...), the author and a title. A search item has a method that renders it in the context of a search result list, i.e. with the possibility to navigate to the next and previous search hit and to the result overview.
Almost all objects are searchable and therefore are search items.
A news item is a search item that usually is presented differently in a search result overview. Rather than a fixed set of categories, it has a method that renders it in an overview context. This method can use arbitrary content elements such as title, images or summaries to create an appropriate overview for the news item.
An event is a news item with an additional date property and optional time and duration properties. Search results consisting of events only can be organized in chronological lists or calendars.
An annotation is a search item associated with a friend and a page. It is used to make personal notes/remarks with respect to the page.
A friend describes a visitor from the friend class. It inherits from search item and serves as a container for profiles and annotations.
An artist implements the artist visitor class. It inherits from friend and serves in addition as a container for art piece descriptions and events.
A news board is a collection of news items. News items are organized into channels.
A discussion board is almost identical to a news board. It allows to reply to the news items and start a new thread.
An art piece object describes a piece of art. As it should be searchable, it inherits from search item. It is characterized by additional categories to facilitate classification and search for art pieces. Its main content consists of various descriptive texts and a set of media objects illustrating the art piece.
Usually, an art piece is associated with an artist. There are, however, art pieces associated with several artists (coproductions) and art pieces, that are not associated with a group member artist (art pieces lent from outside the group, e.g. for an exhibition). These art pieces are managed by the administrators.
An exhibition is an arrangement of exhibition items in exhibition rooms. Each exhibition room arranges a set of related exhibition items. Each room has a title and a more detailed room description that illustrate the room's theme. Doors connect the room with (thematically) neighboring rooms. The doors are labeled with the respective room titles. There is an exhibition map that provides an overview of the exhibition rooms. The visitor can directly go from the map to any room he likes.
At any moment, an exhibition visitor is in one exhibition room. The portal maintains which rooms the visitor has already seen and provides visual glues for these rooms. This is true both with respect to the doors leading to different rooms as well as the room representation in the exhibition map. This way, the visitor can easily recognize which rooms he has already visited.
Exhibition items are essentially links to art pieces. Usually, several texts and a media object of the art piece are selected to represent this piece in the exhibition. A special exhibition text can be provided that relates this piece of art with the other pieces in this room.
This section describes the portal services a bit more detailed. The trivial services, such as the publication of essentially static pages, are not covered.
Each page contains a feedback link. When a visitor clicks the link, he can send a message to the page author, either an artist or an administrator.
The service should use the visitors mail service to provide for easy replies and avoid anonymous messages. The portal should preset the To field with the page authors mail address, the Subject field with Artist group portal feedback and the message body with the title Feedback for and the page's URL. The visitor should complete the message body with his specific remarks.
An introductory page should inform the visitor about the service details and provide for a choice whether the message is to be sent to an artist, the administrator or both, if applicable.
Visitors should be able to register as a portal friend. They must fill a registration form and provide personal information such as name, address and email address. They can provide optional information such as special interests and reasons, why they want to become a portal member.
The registration uses the visitors mail service to send the registration request in order to obtain a valid email address.
Registration requests are automatically preprocessed. If there is already a friend with the request's email address, then an automatic response is generated that informs the visitor about the status of the friend record. Otherwise, a new candidate friend record is created in the portal. The portal assigns a login name and a temporary password. The login name should be the visitors name as specified in the registration request. Because login names must be unique, some form of disambiguation need to be performed, if there is already a friend with this login name.
A registration request must be approved by an administrator to become effective. The administrator can search for all pending registration requests. He can either accept the request, reject it or even block the email address from any new registration applications. In case of acceptance, an email is generated to the visitor that welcomes him as portal friend. The message informs him about the friend services and provides the necessary login information such as login name and password. If he rejects the application, he must provide a reason. An email is generated to the visitor that informs him about the decision and its reason. The candidate friend record is then deleted unless the email address should be blocked from further applications. In the latter case, all personal data is removed from the record with the exception of the email address; the record is marked as permanently blocked. As the administrator would usually accept all friend requests, he can use the portal in the auto acceptance mode. In this mode, registration requests are automatically accepted, unless the email address has been blocked. Manual acceptance is provided for the case that the service should be abused.
Upon receipt of the acceptance message, the visitor can log in as friend. He can change his personal information as well as the automatically generated login name and password. The email address, too, can be changed. However, in this case, the original email address is retained, too, as a validated last resort contact address.
Passwords are stored as one way hash values of the clear text password. Therefore, the portal is unable to recreate a password. This may become a problem when a user forgets his password. The portal, therefore, provides a service Password forgotten?. The personal information contains two fields Question to ask, when you forgot your password and Your answer to this question that are used by this service. The service asks the visitor for the name and email address he is registered with. It then asks the password forgotten question. If the visitor replies with the correct answer, then a new temporary password is generated and send by email to the registered email address. To prevent denial of service attacks, the old password remains valid until the temporary password is changed. An administrator can activate this service manually on behalf of a visitor without the need to answer the password forgotten question.
Registered users can and must log in to access services not provided to the general public. The portal provides cookie based authentication as well as basic authentication, for those that have severe reservations about cookies. Visitors using cookie based authentication can request that their login name and password be remembered such that they are automatically logged in. This is implemented through a long living cookie while normal authentication cookies have the browser process' lifetime.
The Events service display events in either a chronologically sorted list or in a calendar. It is possible to restrict the displayed events through application of a filter. Filter criteria include event type (e.g. meeting, exhibition, opening,), location and author.
Events can be created by artists or administrators or can be imported from other artist groups. Local events have a visibility that restricts who will see them. Initially, events are private. Later, the author can choose whether they can be seen by artists only, by friends or by all visitors or whether they are even syndicated.
The portal maintains a guest book. Visitors can drop there a note about their visit. They can use it, too, to provide general feedback about the site.
The portal provides a form to create a guest book entry. It asks about the visitor's name, his email address, his comments and various questions about his impressions with respect to the portal. If the visitor has logged in, name and email address are provided automatically. When the visitor submits the page, the quest book entry is created.
As guest book entries can be anonymous, they are not included in site wide searches and are never syndicated. There is, however, a local search facility that just searches the guest book entries. Supported search criteria include name, email address and the valuation results.
This service presents the most recent news items. It is implemented as a news board. News item sources are the same as the event sources.
The discussion board is similar to the news board but is open only to friends. Any friend can start a new thread there or reply to any posted message.
The discussion board provides a special overview display for its items: the thread display. A thread consists of an initial message, the replies to this message, the replies to the replies and so on. Thus a thread is a hierarchical structure with the messages as nodes and a message's replies as this message's children. A visitor can explore the hierarchical structure by interactively expanding and collapsing nodes in the structure. When the thread display is called from a discussion item, then the path to this item should be shown expanded and the current news item highlighted.
The portal provides advanced search facilities. Almost all pages should be searchable, provided they are accessible to the visitor.
There are at least two search forms: a simple one for casual visitors and a detailed one for advanced users.
The simple form provides a single search field. This field is parsed into a sequence of keywords. The search retrieves all search items that match any of the keywords. The keywords may contain wildcards: * stands for a sequence of characters, ? for a single character. A search item matches a keyword, if any of its associated information fields, e.g. text, title, author, keywords, type, etc., contains a word matched by the keyword (with respect to the wildcard interpretation).
The detailed form provides several fields that allow to restrict the search, e.g. to given types such as events or art pieces or to given authors or to a given period or to parts of the search item such as its title. The overall search result is the intersection of the results corresponding to the various field searches. Most field contents are parsed into a sequence of keywords. The search result is the union of the searches for the single keywords. Most of these fields support the wildcards * and ? and interpret them as described above.
A search result is presented first in an overview. The overview is paged with each page describing a few search hits. The visitor can navigate through the result pages. When a visitor clicks on a hit in the overview, the hit is displayed in a detailed view. From there, the visitor can navigate from hit to hit, go back to the overview, start a new search or refine the current search.
Friends can annotate almost all content pages with privat remarks. When a page is displayed for a fried, he will see an annotation link for each of his annotations associated with this page. Additionally, there is a link add annotation to add an annotation to the current page.
Annotations can be managed (i.e. edited, deleted) either from the page they belong to or from the friends annotation folder.
Profiles are named filter criteria. They can be used for searches, personalized alert emails or for home page personalization. Any search form can be saved as profile.
Friends can request to get emails for relevant information. They specify with a profile what is relevant for them. They can specify, too, how often they will be informed: daily, weekly or monthly.
Each friend has a personal portal home page. Via this home page, he gets access to his personal registration information, his profile definitions and his annotations. Access is provided via tabs on his home page. He may define further tabs and customize their content though integration of profile based search results or link collections. He can determine the tab order and which tab is presented by default.
All content items, e.g. art piece descriptions, events, news items, annotations, should be manageable in a uniform way. Each author has a set of type specific folders containing his respective items. He can add new items and rename, delete, edit existing items or change their visibility.
Each content item contains a link to its author. Usually there are further links to related items. Content items have type specific properties and may serve as containers for other items.
Content authoring should be easy and not require special HTML knowledge. On the other hand, persons who know HTML well should be able to leverage this knowledge to obtain more control over the presentation. Such persons are required to adhere to the restrictions imposed by the content management framework.
The portal maintains a group calendar with all events relevant to the group members. Each artist can define new events. Events can be managed either from the artist's event folder or directly from the group calender. The public part of the calendar is presented by the Events service.
The portal supports online exhibitions: guided tours through a collection of art pieces thematically arranged in virtual rooms.
The portal supports the collaborative authoring of complex documents. Each such document consists of a web of linked pages, similar to the world wide web, just small scale. Each artist can add new pages, edit existing pages or add links between pages. Several pages can be edited concurrently by different artists. However, concurrent editing of a single page is not supported. Authoring simple pages should not require HTML knowledge. It should be possible, however, to use HTML for difficult layouts, e.g. such that require tables.
The portal exports its non-local events and news items through RSS for use by other artist groups or interested parties. It imports various RSS channels from other artist groups and makes the items available in the group calendar and the news board.Need to learn more about RSS.
The portal allows artists to offer their works of art in an electronic shop. The shop supports the search for works of art and maintains a shopping cart. If a visitor has decided to buy the items on his shopping cart, the respective artists are informed by email. The email contains the buyers contact information, the list of items commanded from this artist and the total value of the buyer's order. The shop does not support the proper sales transaction.
The portal provides automatic cleanup. This includes deletion of outdated content. Each content item has an associated deletion date. When the deletion date is reached, the item and dependent subitems are deleted automatically. When a new item is created, its deletion date is set to a type specific default lifetime. This is indefinitely for all content items that are not news items or events. The default lifetime for news items is one month, that for events one month more than the events end time. The author can change the deletion date manually.
Usually, you could expect clear prescriptions in this section with respect to screen design and corporate identity. In this book, however, we are not much concerned with presentational aspects as they are not specific to dynamic web sites. Therefore, we make only weak requirements: the portal should exhibit a clear, easy to understand and consistent structure. All services should be easily accessible; navigation should be natural and straight forward.
One can expect that an artist group's portal does not exhibit high volume traffic. This implies that throughput is not a big concern. We will nevertheless point out optimization opportunities to increase throughput at appropriate places. We still have response time requirements: most requests should be answered within 2 seconds. This is mainly a restriction for searches and sometimes for the rendering and display of complex pages.