Press Design Documentation

by Chiao Cheng and Josh Finkler

I. Essentials

II. Introduction

The Press application allows a company to manage and display recent articles in which the company or web site has been featured.

The application differs from the bulletin board application and the news application in that it was not designed to allow arbitrary users to post messages or events. Rather, the application allows site-wide or group administrators to post significant media coverage of company activity for others to view. Unlike the news application, press will mainly be a collection of summary information about articles written by people outside the organization, usually providing a link to the full off-site article if available.

The Press application will most likely be used by companies who receive significant media coverage. This is especially helpful for smaller companies trying to build their brand name.

III. Historical Considerations

The Press application was designed by looking at the display of similar information on other sites like www.scorecard.org and www.valinux.com. The initial design was later modified to add pagination and access to the archive of expired articles based on feedback from client sites.

IV. Competitive Analysis

The Press application is consistent with the functionality of similar systems on the public internet.

V. Design Tradeoffs

By employing the templating system in this application, site owners benefit from the ease with which they can customize the look and feel for each article. The templating system adds additional complexity to the Press application, especially with respect to adding articles into the system versus having a uniform display throughout all the press events. Here, we have sacrificed usability for a more advanced feature set. The use of templates will at least require the administrators to learn and use the coding standards of the templating system. Although this puts an additional burden onto the administrators, the benefits of doing so should outweigh the costs: having a templating system allows significant display flexibility, in that displays may be changed easily without changing the underlying code. Additionally, this means that the application is highly scalable.

VI. Data Model Discussion

The Press Application contains two main tables. The first one is the template table which holds the template name and the actual template code. By using this table, users may store different styles of display for the press events. Each different look and feel simply uses a different template. 


create table press_templates ( 
        template_id             integer primary key, 
        -- we use this to select the template 
        template_name           varchar(100) not null, 
        -- the adp code fraqment 
        template_adp            varchar(4000) not null 
);

A site administrator can define named templates to control how these pieces of information are displayed. The templates are written as ADP fragments using the variables listed above. For example, the system default template might format a press item as follows: 

<dl><b><%=$publication_name%></b> - <%=$article_name%> (<%=$article_pages>)
<dd>(<%=$publication_date%>) - "<%=$abstract>"</dd></dl>

This template would be expanded into:

Dog's Life - Planet of the Dogs (pp 50-52)
January 1, 2100 - "They used to say that every dog has his day. Little did humans know that the collapse of their society at the beginning of this millenium would give rise to a new golden age of canine rule."

The second table is where the articles are stored. Every entry is stored as a record with information on the article. This includes publication name, the link to the publication, title of the article, and administration data such as who created the article. There is a scope field which allows the article to be defined for either public or group. A public scope means that everyone will be able to see it. A group scope mean only people belonging to the group may see it. The template_id is how the articles are associated with the templates. So this allows each article to be formatted differently. 


create table press ( 
        press_id                integer primary key, 
        -- if scope=public, this is press coverage for the whole system 
        -- if scope=group, this is press coverage for a subcommunity 
        scope                   varchar(20) not null, 
        -- will be NULL if scope=public  
        group_id                references user_groups, 
        -- determines how the release is formatted 
        template_id             references press_templates, 
        -- if true, keep the release active after it would normally expire.  
        important_p             char(1) default 'f' check (important_p in ('t','f')), 
        -- the name of the publication, e.g. New York Times 
        publication_name        varchar(100) not null, 
        -- the home page of the publication, e.g., http://www.nytimes.com 
        publication_link        varchar(200), 
        -- we use this for sorting 
        publication_date        date not null, 
        -- this will override publication_date where we need to say "Oct-Nov 1998 issue" 
        -- but will typically be NULL 
        publication_date_desc   varchar(100), 
        -- might be null if the entire publication is about the site or company 
        article_title           varchar(100), 
        -- if the article is Web-available 
        article_link            varchar(200), 
        -- optional page reference, e.g. page 100 
        article_pages           varchar(100), 
        -- quote from or summary of article 
        abstract                varchar(4000), 
        -- is the abstract in HTML or plain text (the default) 
        html_p                  char(1) default 'f' check (html_p in ('t','f')), 
        creation_date           date not null, 
        creation_user           not null references users(user_id), 
        creation_ip_address     varchar(50) not null 
);

VII. Legal Transactions

Site-Wide Administration Pages

From the Site Administration pages at /admin/press/ the site-wide administrator can do the following:

Sub-SIte Administrator Pages

From the Maintainers admin pages at /press/admin/ the press coverage maintainers can:

User Pages

VIII. API

There are two procedures that are public:

this is more than two. ron? chiao?

Private Functions: (these function are used internally by the application.)

Administration Functions:

IX. User Interface

The site wide administrator has to be able to control all the press events on his site. This includes adding, editing, deleting articles. In addition site-wide administrators has control over all articles in any scope. The admin can also specify a template to be used by an article when it is created.

The sub-site administrators have almost the same permissions as the site- wide administrator except that this person only have the permissions for a particular sub-site. So this person may not affect other sub-sites without permission. Like the site-wide admin, the sub-site admin can also specify templates to be used.

The user has the most basic interface. It is just a display of the most recent articles. The user does not have control over the display.

X. Configuration/Parameters

You can change the site-wide behavior by setting the following parameters: 

    [ns/server/service/acs/press]
    ; maximum number of press items to display on the press coverage page
    DisplayMax=10
    ; number of days a press item remains active
    ActiveDays=60
    ; do we use clickthrough tracking from the press coverage page?
    ClickthroughP = 1

XI. Acceptance Tests

You should test adding, viewing, editing, and deleting a press item:

XII. Future Improvements/Areas of Change

The expiration behavior of press coverage is strange. Once an item surpasses the site-wide maximum number of active days and expires, the only way to turn it back on is to set the important_p flag and have it displayed permanently. It would make more sense to define a per-press-item expiration date.

Any administrator can create public press coverage. This currently cannot be restricted.

Future Improvements

XIII. Authors

Advertisements