Tradeshow 2.0 Design Proposal

Mark Bondurant

August 18th, 2000

 

 

 

Executive Overview

 

Aprisa plans to host its second online tradeshow in early November.  The new Tradeshow will build on the success of the first, offering a new look and enhanced features, allowing users to attend lectures, participate is discussions and view vendor booths. 

 

This document is a review of Tradeshow features in version 1.0 and description of features that will be included by Operations in the next version of the Tradeshow and how those features will be provided.

 

The primary goal of this design is to keep the code required and the effort involved in the construction of the system to an absolute minimum.  We emphasize simplicity and robustness of design.

 

Each page in the Tradeshow will share common utilities, which will provide access to all system services and security.  These services will be transparent to the designers.  Concerns involving logging, user identification, and any other services that might be provided will be dealt with in this file.  No other code will be required in most, perhaps all of the Tradeshow proper. 

 

Shared services between all pages means that the probability of failure due to coding mistakes is kept very low because there are fewer points of failure.

 

Outside of the Tradeshow, there will be a set of utilities that will allow the management of the Tradeshow and its participants.  For instance, user activity can be monitored in real time.  Users can be granted staff or admin rights.

 

A completely new feature will be the addition of contract information to the Tradeshow database.  Relationships between vendors, advertisers, and attendees are brokered through contracts and this information is used to tie companies to booths and advertisements.  The front-end that provides the interfaces that will allow us to manage these relationships is Access.  Simple Access forms linked directly to the database will provide a common interface to all Tradeshow Utilities.  There will be very little real code anywhere in the Tradeshow.

 

This emphasis on proper structure, rather than code for effect, means that we can take advantage of the strengths that are built in to the software systems that we are using to produce our site.  And this will give us a simpler, more reliable system.

 

 

 

Requirements Specification

 

 

System Architecture

 

Aprisa’s web plant will be used to host Tradeshow 2.0.  It offers up to 100 Mps throughput, stiff firewall protection, and complete redundancy through load balanced web servers and database servers.  These services are provided in house at no additional cost to Aprisa. 

 

Streaming video services will be provided through Estream, the same provider who did the excellent work on Tradeshow 1.0.  They have proven themselves to be an efficient, professional, and most of all reliable service.

 

 

There will be an additional server required, Webprod04, which will be added as a redundant chat server thus giving us failover protection for our chat services.

 

 

Site Structure

 

As in Tradeshow 1.0, there will be three Tradeshow sites, Vendor Relations, Registration, and the Tradeshow itself.  Each of these sites will be accessed through a separate URL of its own.  Vendor Relations and Registration will open four or more weeks prior to the Tradeshow November 6th opening date to allow the sale of vendor booths and the pre registration of Tradeshow visitors.

 

 

The Vendor Relations Site

 

The primary function of the Vendor Relations site will display booth prototypes for prospective vendors to choose from and to allow the viewing of booth work in progress by vendors.

 

The home page will lead into two areas.  There will be a booth prototype section that will display booth prototypes for vendors to select from and there will be a vendor information area.  The vendor information area contains information pertinent to vendor participation such as prices, schedules, advertising rates, reporting options, and contract information.

 

 

There will also be a separate independent area where booths under construction for specific vendors can be displayed to the vendor.  This area will not be reachable through the site home page, but instead will be accessed directly via a URL that is passed directly to the vendor.

 

While the main Vendor Relations site will be open to the public, the Vendor Booths area will be password protected.  The structure of the Vendor Booths area will be free form with designers being able to create new directories at will. 

 

In order to prevent vendors from seeing other vendor’s booths before the show, each vendor booth directory will have a password kept in a clear text file that can be set by the booth designer.  Security will be provided by an include file that will be attached to each booth page which will block the use of the page without the entry of the password first.  This will free the booth designer from the burden of having to add code directly to each page.

 

 

The Registration and Confirmation Sites

 

Users will be required to register prior to the Tradeshow at a separate Registration site whose function, in addition to gathering demographic information about the user, would be to validate their email address.  The validation of the new user’s email address would be a two-step process.  First the address would be validated as being a live email address in the same step as the validation of the rest of the query page.  This would weed out addresses like “a@a.com”.  Upon completion of the page, an email would be sent out to the user’s email address asking them to return to a confirmation page and activate their account.  Without activation, the accounts would remain non-working.  This would prevent users from putting in false addresses such as “bclinton@whitehouse.gov”.  

 

New users will not only be added to the Tradeshow database, but also the chat database.  This means that they will be able to directly enter chat rooms directly without further need to go through a second registration process.

 

Demographic information collected by the Pre-Registration site will include personal information for the new user such as address and phone, information about the user’s company and the user’s role within it, and it will also include how the user found out about the Tradeshow.

 

 

The Pre-Registration site will remain open during the Tradeshow itself to allow new users to register.

 

 

The Tradeshow

 

The basic Tradeshow structure will not change.  There will be booths, auditoriums, and chat rooms tied together with a map and various lobbies, all accessed through a front entrance and a log in page.  System services such as security and logging will be provided through an include file that will be attached to each web page, the same strategy that was used by Ampersand in the first show.

 

Attendees must have the option not to install unwanted pug-ins in their browsers, so pages including animation will also have static versions that will display for browsers that cannot or do not want to accommodate dynamic content.  The one exception to this is Windows Media Player, which must be used to view the video content in the auditoriums.

 

 

 

In the drawing above, the site map and the lobby serve the same function, which is to allow access to all parts of the site.  The Other Features box covers bathrooms, bars, and event schedules.

 

Streaming media will be accomplished just as it was successfully before, through Windows Media Player and Estream broadcasts.  Video will be viewed in the auditoriums.  Some video presentations, such as the keynote address, will be at predefined times.  Others will be on-demand.  A link to download Windows Media Player from Microsoft will be available at the Auditorium entrance.

 

Vendor booths are customized sub-sites specific to each vendor participating in the tradeshow.  These can either be hosted by the vendor or hosted by us in a subdirectory under the main Tradeshow site.  If the vendor is hosting their own site, then they must provide a link to their site and security access.  Vendors have the option to build their own booths or have us build them by selecting one of our predefined booth formats.  Booths can contain slide or video presentations.  However, video cannot be hosted by us on our servers but instead must be obtained through an outside contractor such as Estream.  Delivery of outside vendor booths must occur at least two weeks before the opening of the show to allow us time to pass it through QA.

 

Chat Rooms are supplied through a chat server, which will be sited on our Exodus site on servers webprod03 and webprod04.  When chat discussions revolves around a specific topic or a particular personality is available for attendees to meet, then the chat room will be moderated.  Otherwise chat rooms will be allowed to progress in a free form manner.  Chat room features, such as the setting of nick names, creation or deletion of rooms, or running of bots will be limited.  Because any chat server we choose will require users to download a client in order to participate, this client will have to be in the form of a Java applet and the download must be transparent to the user.

 

 

Extending Tradeshow Features

 

The extension of Tradeshow features beyond those achieved in Tradeshow 1.0 must naturally be researched and discussed as to their practicality and cost effectiveness.  Any list of additional features must be finite with a specific cut off date for the addition of any new features.   The cutoff date for new features is September 1st.

 

Additional features that might be added to the existing show could include the ability to have users send messages to each other and to post both private and public messages on a bulletin board in the main area.  The sending and receiving of messages, if implemented should also be possible from both inside the chat area and outside in the tradeshow proper.  Messages would be stored in the database and would be probably be delivered on the next page request.

 

Another possible feature might allow users the ability to query user’s locations within the tradeshow.  Users though, would have to have the option of remaining invisible and thus private.   This feature might be desirable for system administrators as a real time viewer that shows all the current user’s locations within the show and what they are doing.

 

Depending on the chat server we choose, we may also have additional features that could include the ability to create private meeting rooms on demand or to send each other files.

 

The Pre-Registration site might be extended to include vendor lists, peeks in the bathrooms, or the ability to post messages in advance.

 

Tradeshow Security

 

When users log in to the Tradeshow itself, they will use their email addresses to identify themselves.  They will then receive a cookie, which will contain their user session information including their email address.  Because of the load balancer we cannot use Session or Application variables except in certain situations where server context is of no importance, which means that all information personal to the user must be stored in cookies. 

 

Application information, information common to all users must be stored in the database.  This would include timeout information and the current active user list.  The current active user list is a list of all users in the system and their current location such as chat room 3 or the auditorium.

 

 

Tracking and Reporting

 

Each time a user logs in, the time and the user’s IP address will be logged in the database.  This will allow us to link user information to the web server’s logging database.  The web server will keep track of the who’s, what’s and when’s, such as when a user hit a particular page.  Reports involving user activity will be generated using Site Server reporting.  Reports involving demographic information, because this information is not kept in the web server database and is thus outside Site Server’s domain, will be generated using Excel or Access. 

 

 

Advertising

 

Ads will be static, built into the rooms themselves.  A separate count of impressions or page views will be kept for later reporting to the advertisers.  A click through count will also be kept.

 

 

Production Schedule

 

 

The feature set for the Tradeshow, as a whole, will be frozen on September 1st.  All new hardware must be installed by September 8th.  The database and security infrastructure will be in place by September 22nd.  The final version of the system will be released on October 19th.  The two weeks following are left for QA and the reworking of booths.

 

The Vendor Relations Site will open on October 2nd.  The Pre-Registration Site will open on October 8th.

 

 

Functional Specification

 

 

 

Registration and Confirmation Sites

 

The registration site will function as it did in Tradeshow 1.0 except for the addition of a new email confirmation step.  When the user has successfully filled out the registration form, an email will be sent to their email address instructing them to login to the Confirmation Site.  Prior to the Tradeshow, the Confirmation Site will activate their account and inform them they are registered for the Tradeshow.  Marketing at this point may want to give them some sort of thank you for having filled out the form.

 

 

During the show, the Confirmation Site will log them directly into the Tradeshow setting them down in the site as if they had logged in normally.  This new extra step of forcing users through a confirmation page will allow us to confirm our user’s email addresses.

 

The User Information Form will have required fields, which the user must fill in.  If information is missing or unacceptable, then java script in the form itself or the form processor will bounce them back to the input page with an alert message and the cursor placed on the offending input field.

 

The Confirmation Page will function in this way too.  If they enter an email address not in the database, then the Form Processor will bounce them back to the Confirmation Page with an alert stating that the email address is unknown and the cursor on the email address input field.  If the entered email address is already confirmed, then the Form Processor will pass them on as if they had just confirmed.

 

The Show Summary pages will be the same as last time, listing exhibitors, events, and sponsors.

 

 

The Vendor Relations Sites

 

The Vendor Relations Sites are dedicated to vendor sales of both booths space and advertising.  Because of this the Vendor Relations Sites should be the first to come up in order to get sales started as early as possible.

 

 

The Main Vendor Site is dedicated to the display of possible booth selections, show schedules, advertising rates, reporting options, and contract information.  Vendors will have a simple single password login to get in.  I would suggest something simple like “goaprisa”.  The idea behind the password is to encourage them to talk to our sales department in order to get the password.

 

Once in the site, they will be presented with a menu page that will allow them to view the six to eight booth prototypes or a series of pages dealing with vendor specific information.  All these pages will be simple HTML pages with no security.

 

The Vendor Specific Sites are individual sites that are used to display booth designs to specific vendors during their construction.  These will be ad-hoc directories that will be protected by a vendor specific password.  The vendor will go directly to their site by entering a URL specific to their site.  There will be no menu.  A vendor URL might look something like: “http://tradeshow.thecubicle.com/vendors/toshiba.”

 

On entry the vendor will be presented with a login screen, where they will enter their password.  The Vendor Specific Sites will have their own login processor, which will read the vendor’s password from a clear text file in the vendor directory.  If the vendor enters the correct password, then they will be allowed into their booth.  The purpose of this password is to prevent venders from viewing their competitor’s booth designs.

 

 

The Tradeshow Site

 

The functionality of the Tradeshow site will be broken up into subdirectories to help manage the clutter within the main site directory and to aid in post-show analysis.  Breaking the site into sub-sites makes it easier for us to analyze site traffic within a specific function because we can query traffic data just for that sub-site.

 

 

Entry into the Tradeshow will be just as it was before.  A front entryway, a login screen, and a lobby/menu which can take the attendee to any section of the show.

 

 

The Login Processor for the Tradeshow site will accept email addresses as passwords from attendees, pass them back a cookie to later identify them, and add an entry in the Active Users table in the database.  Any page after the login screen will compare the attendee’s cookie values to the values stored in the database for that user to determine whether the user can access that particular page.

 

If a user tries to access a page directly, such as a booth or the auditorium, without entering through the front entrance, then they will be presented with the login page first.  Once they have logged in, then they will be allowed to proceed.  This means that vendors can bookmark their booths but will still be required to log in.

 

Besides the lobby/menu, attendees can navigate around the Tradeshow site by using the Tradeshow Map.  All pages after the login page will have a button, which will bring them to the Map page.  The Map will have links to every booth and every system function, such as the Auditorium or the Bathroom.

 

The Booths site will have an index of booths and vendors.  Users will be able to view a list of vendors and booths.  Clicking on a booth will take them to that booth.  Each booth will be its own sub-site under the booths directory, if we are hosting it, or it will be a link to a vendor site if the vendor is hosting it.

 

 

The Information site will be a clearinghouse for general information and functionality that fits nowhere else.  The feedback email link as well as the link to theCubicle.com will be here, the event schedules, both daily and for the show, as a whole will be here, the Tradeshow Mission Statement will be available, and finally a new feature, a bulletin board, which will allow users to leave messages for other attendees, companies, or the show as a whole.

 

The Pressroom is a vehicle for vendor announcements and presentations.  Presentations can be viewed on-demand by selecting one from a menu on the Pressroom screen.  Presentations that are being hosted by us are kept is separate directories under the Presentations site.

 

 

The Auditorium site is the receiving point for Estream broadcasts.  There may be some on-demand presentations, in which case there will be a menu available to select them.  There will definitely be broadcasts at specific times and a schedule of show times will be visible.  It will also be possible to download and install Microsoft’s Media Player from Microsoft’s web site, the client of choice for the video presentations.

 

The Bathrooms will still be mostly decorative with two additions.  The toilets will flush and the Privacy Statement will be written on the wall.  Somewhere on the walls of the bathrooms there will be some scribbling.  If you click on it, you will be shown a closeup of the tile showing the complete privacy statement.

 

 

The Chat site will function just as it did before.  When users create their accounts in the Tradeshow they also create matching accounts in the chat database.  Users enter the chat rooms pre-logged in and configured.  The first time they use chat, there will be a delay while the chat client, probably a java applet, is downloaded.  Moderators will have extra privileges, such as the ability to boot people out back into the Tradeshow.

 

This leaves two sites left unaccounted for in the old show, the Wireless Pavilion and the Lounge.  Both were simple HTML pages in Tradeshow 1.0.  The purpose of the Wireless Pavilion was to provide links to special vendors.  It can do this again.  The Lounge had no special functionality other than to advertise Words On Wine.  Neither of these sites are complicated enough to be worthy of diagramming.

Technical Specification

 

 

Overview

 

The primary goal of this design is to keep the code required in the design and construction of the system to an absolute minimum.  The bulk of the creative staff producing the designs and layout of the site will be primarily artists.  The bulk of the work that will be needed for the Tradeshow will involve design and art.  I feel that in order to take maximum advantage of their strengths, it’s important not to burden them with concerns about infrastructure. 

 

Each page will have attached to it a shared include file, which will provide access to all system services and security.  These services will be transparent to the designers.  Concerns involving logging, user identification, and any other services that might be provided will be dealt with in this file.  No other code will be required in most, perhaps all of the Tradeshow proper.

 

Outside of the Tradeshow, there will be a set of utilities that will allow the management of the Tradeshow and its participants.  For instance, user activity can be monitored in real time.  Users can be granted staff or admin rights.

 

A completely new feature will be the addition of contract information to the Tradeshow database.  Relationships between vendors, advertisers, and attendees are brokered through contracts and this information is used to tie companies to booths and advertisements.  The front-end that provides the interfaces that will allow us to manage these relationships is Access.  Simple Access forms provide a common interface to all Tradeshow Utilities.  There is very little real code anywhere in the Tradeshow.

 

Although this design builds on the basic structure Tradeshow 1.0, it takes the lessons we learned and uses them to produce a new paradigm that emphasizes simplicity.

 

 

Roles

 

I have found that the best first step for me in designing a successful system is to identify the players that will be using it and then defining the types of information they provide and require.  In the past, we used dataflow diagrams to define user types or entities and the information that passed between them or “data flows”.  Now days I tend to think of the system as a play and treat people as players who have roles within it.  I can identify five roles within the Tradeshow, each one with a different set of attributes and needs:

 

 

The Vendors and to a lesser extent the Advertisers, are most interested in the movements of the Attendees, Advertisers being more passive, waiting for page views or click-through counts from their ads.  The Moderators and Administrators are mostly interested in keeping things moving, the Moderators in the chat area and the Administrators in the system as a whole.

 

Each of these concerns can be thought of as objects in and of themselves and are broken down thusly:

 

 

System and Contact can be broken down further:

 

 

Attendee’s have limited amount of system access, they need to be tracked, have demographic information, contact information, and a role in their businesses.

 

 

Vendor objects are simpler than the User Objects.  Just as the users, they have a company.  But they are also concerned with their booths and contract.

 

 

Advertisers are similar to Vendors except that they have ads instead of booths.

 

Moderators and administrators are the simplest forms of users, having greater access but no demographic or tracking information.

 

 

Data Model

 

By breaking down the users into roles and then isolating their needs, we can derive a set of classes of information necessary to supply the needs of the user roles above.  We accomplish this by constructing a Data Model.

 

 

The trick with building a data model is to find the center of the system around which all other objects revolve.  This can take several iterations through the design process.  The above chart is in its third version.  At this point Company is the most important object. 

 

To summarize the design at this point:  attendees represent their companies or are leads into their companies.  Attendees generate activity and have access rights.  Companies can form contracts involving advertising and booth space.  At the bottom is the Tradeshow itself, which is nothing more than a collection of locations.  Security is expressed simply as a relationship between Attendee and Location.

 

 

The Database Layer

 

It’s not hard to move from the Data Model to the Database Design itself.  It’s mostly a process of “normalization”, setting up the sets of tables that represent each object.  In the simplest form, normalization is the process of separating repeating data out into separate sets of tables.  This improves the storage efficiency of the database at the cost of speed.  It also allows data with multiple dependencies to be more efficiently linked when performing queries.  Since we are not performing real-time operations or other database intensive operations, database performance is not an issue in the Tradeshow database and we can design it towards maximum flexibility and go with full normalization.

 

With full normalization, some objects will be manifested through several tables.  Address for instance also has a City, State, Postal Code and Country tables.  Each City record shares the list of states.  This means State entries wont be separately entered for each City.  This prevents the possibility for different spellings of the same state.  It also allows us to use the State table to populate the state drop down list in the demographics forms in Pre-Registration from the database, thus enforcing consistency in our customer’s answers.

 

Database tables can be grouped together to form macro objects, which can be treated as a single entity.  These entities act as true objects with attributes and methods.  The mechanism that is used to create these objects is stored procedures.

 

Stored procedures are database queries that are stored in the database.  The language of these queries can be quite complex and a great deal of the business logic of the system can be stored at this level.  There are two advantages gained by doing this.  The first is performance.  With stored procedures, the web site scripts pass the database the name of the query to be executed rather than having to submit larger, complex queries for syntax approval and marshalling.  The second advantage is found in moving the business logic out of the scripts.  This helps in forming a second tier business layer removing business logic from the web or presentation layer.

 

The stored procedures listed below have a particular name structure which helps to identify their function.  They start with “sp” to denote that they are stored procedures, as opposed to views, or triggers or other database objects.  Following that is the object they represent, such as Booth or Attendee.  Next is the class of functionality they provide.

 

            add                  Unconditionally adds an instance of the object

            get                    Retrieves a reference to an object in the form specified by

                                    the argument that follows.

            id                     If an instance of the object already exists it returns a

                                    reference to it.  Otherwise it adds a new instance of the object

                                    and then returns a reference to the new object.

            update              Updates the attributes of an object.

            delete               Deletes of an object.

 

Notice that, except in the case of internal functionality such as Contracts and Location, there is no update or delete functionality.  The Tradeshow is a real time event.  Data is collected and never altered or destroyed.  Last is the type of information returned.

 

            list                    Returns a recordset containing all or a subset of the available

                                    objects in the database.

            id                     Returns the value of  the key field ID.

            <column>         Returns the specified column value.

 

Stored procedure arguments in italics are read/write otherwise they are read only.

 

Activity

sp_activity_add_activity      activity id, location id, user id

sp_activity_add_argument      activity id, argument

 

Ad

sp_ad_get                     ad id, url, location id, position id

sp_ad_add                     ad id, url, location id, position id

sp_ad_delete                  ad id

sp_ad_update                  ad id, url, location id, position id

 

Address

sp_address_id                 id, street1, street2, city id

 

 

Attendee

sp_attendee_add               id, role, anonymous, email address,

                              company name, <company address>,

                              <attendee address>, title id,

referral id, income id, supervisory id,

budget id, decision id

sp_attendee_get_role          role id, role level, user id

 

Booth

sp_booth_get_location         location_name, description, url

sp_booth_get_list             contract id

sp_booth_update               booth id, url, location name, description

 

Budget

sp_budget_get_list

sp_budget_get_id              id, budget

 

BusinessLine

sp_businessline_get_list

sp_businessline_get_id        id, business line

 

City

sp_city_id                    id, city name, country id, state id,

postal code id

 

Company

sp_company_get_id             id, company name

sp_company_id                 id, company name, address id,

company size id, company revenue id,

                              business line id

sp_company_add_company        id, company name, street1, street2,

city name, state name, postal code,

country name, company size, company revenue, business line

sp_company_update             id, company name, street1, street2,

city name, state name, postal code,

country name, company size, company revenue, business line

 

CompanyRevenue

sp_companyrevenue_get_list

sp_companyrevenue_get_id      id, company revenue

 

CompanySize

sp_companysize_get_list

sp_companysize_get_id         id, company size

 

Contract

sp_contract_get_list         

sp_contract_add_contract      id, document_location, form type,

company id

sp_contract_update            id, document_location, form type,

company id

sp_contract_update_invalidate id

 

Country

sp_country_get_list

sp_country_get_id             id, country

 

DecisionLevel

sp_decisionlevel_get_list

sp_decisionlevel_get_id       id, decision level

 

FormType

sp_formtype_get_list

sp_formtype_get_id            id, form_type

 

IncomeRange

sp_incomerange_get_list

sp_incomerange_get_id         id, income range

 

Location

sp_location_get_name_url      location_name, description, level, url

sp_location_get_name_id       location_name, description, level, id

sp_location_get_id            id, url

sp_location_get_passage       passage, user id

sp_location_update            id, location_name, description, url,

level

 

Note

sp_note_add                   company id, note

sp_note_get_list              company id

 

Position

sp_position_get               position id, description

sp_position_get_description   description, position id

sp_position_update            position id, description

 

PostalCode

sp_postal_id                  id, postal code

 

Referral

sp_referral_get_list

sp_referral_get_id            id, referral

 

Role

sp_role_get_list

sp_role_get_id                id, role

 

State

sp_state_get_list

sp_state_get_id               id, state

 

SupervisoryLevel

sp_supervisorylevel_get_list

sp_supervisorylevel_get_id    id, supervisory level

 

Title

sp_title_get_list

sp_title_get_id               id, title

 

 

The Business Layer

 

The business layer in the Tradeshow will be pretty thin. What business logic there is, is concerned with control of movement and logging activity.  Most of the non-presentation logic for the show is tied up in the stored procedures making complex business objects unnecessary.  Stored procedures in the database will be presented within the web site using Microsoft’s Data Environment, which is built into Visual Interdev.  Because all of the transactions within the show are atomic in nature, with no state being transactions other than the user’s identity, we don’t need to be worried about problems occurring from the load balancers.

 

 

 

The Security Model

 

The Tradeshow is not a secure site, which makes the security model fairly simple.  There are three levels of security, User, Staff, and Administrator.

 

 

The primary difference between Staff and User is that Staff has admin rights in the chat rooms.  Staff accounts are used by lecturers and chat moderators.  Administrator accounts at this point are the same as staff accounts except that they have no company information.  Until we have administrative functions that need to be segregated they will have no additional privileges beyond the Staff accounts ability to administer chat.  We might want to add the ability to erase graffiti off the bathroom walls or to remove posted messages for instance and these could be added to the administrator’s abilities.  Another important function would be the ability to use system utilities such as a contract editor or a user locater.  The important function of the Administrator account is that account activity can be separated from the Staff and Attendee’s activity when running reports.

 

Every page in the Tradeshow has a corresponding location object in the database.  Each location requires a certain user level to access it.  In this way pages can be restricted to just staff members or above or just administrators.  Each page will include an include file which will contain the code to implement the Tradeshow security policies.  The include file will use the URL of the page to reference the page’s location object to obtain its required access level.  It will then compare this to the user’s cookie, which will contain the user’s role.  If the user lacks authority to access the page, then the page will abort with an error message.  The include file will also set a security level variable which can be accessed by the rest of the page.  This variable can be used to hide or uncover page features depending on access level.  In this way administrative functionality will be hidden from normal users.

 

 

Required Code

 

Most of the Tradeshow is fairly straightforward HTML and can be handled by the artist/coders we are hiring.  There are several pieces that may require a little more attention:

 

 

The features in parenthesis are optional features. 

 

 

Tradeshow Services

 

The Tradeshow Include File is probably the most complicated of the required pieces.  It consists of at least two modules. 

 

The first is the Security Module.  It acquires a reference to the location object for the web page the user is accessing.  It fetches the user’s security cookie and compares the role levels of the page.  If the user’s access rights are too little for the page, it generates an error page and returns it to the user.  Otherwise it allows the user to pass on to the next step.

 

The Logging Module provides a logging function and a set of constants to any other code within the web page.  This allows page architects to log other events than just page access.  Events that should be logged would be things like presentations selected or chat room choices.  The Logging Module will then log the users entry into the page.

 

The Messaging Module checks the database for any messages to the user.  If it finds any, it deletes it from the database and displays it along with the rest of the page as a java alert.

 

All of this could take as long as three days to get it written and working in a reliable manner.

 

Use Case: Page Developer Creates A New Page For The Tradeshow

 

Using the yet-to-be chosen page editor, a page designer completes a new web page to be added to the Tradeshow and saved it as an .ASP file (not .HTP).  At the top of the page, above the page header, they add the line:

 

     <!-- #include FILE="\login\login.inc" -->

 

This adds the Tradeshow Services Include File to the page.  The new page has a new event that the designer feels should be logged.  She tells the lead developer that a new event needs to be logged.  The lead adds the new event to the ActivityType table and adds a new identifier to the login.inc file to enumerate the event.  At the point were the event takes place, the page designer adds the following code:

 

     <%

          DE.Log tsEventIdentifier

     %>

 

When this code executes, the event will be added to the database.  When she feels the page is finished, she tells the lead developer to add the page to the show.  The page is moved to the Tradeshow in the staging area for QA and an entry for the page is added to the location table in the database.

 

Use Case: A User Logs In To The Tradeshow

 

The Attendee enters through the front doors and is sent directly to the Tradeshow Lobby.  The Tradeshow Services Include File determines that the user has not logged in and shunts him over the \login\login.asp page, sending his return URL along as an argument in the login page URL.  Confronted by the login screen, he enters his email address incorrectly.  The login form passes the form data, including the Attendee’s incorrect email address, in the form environment and the return URL of the Tradeshow Lobby page as an argument in the posting URL to the \login\loginProcessor.asp page.  The login processor attempts to look up the email address in the database and fails.  It posts the user back to the login.asp page along with an error message and his return URL.  The Attendee enters his email address again, this time correctly.  The login processor checks the email address again, this time finding it in the database.  The login processor issues the user his cookie and sends him back the Tradeshow Lobby.

 

Use Case: A Vendor Views His Booth Though A Bookmark

 

A vendor wants to check their booth to see if it’s working correctly.  They have book marked its address in their browser.  When the attempt to access the page, the Tradeshow Services Include File checks to see if they have logged in by looking to see if they have the cookie.  The vendor does not, so they are shunted over to the \login\login.asp page.  Then vendor enters their email address, the login processor finds it in the database, and they are passed back to their booth page.

 

 

The Attendee Registration And Confirmation Forms

 

The Attendee Registration form and its attending processing page will involve a lot of field checks and database lookups.  The Confirmation Form and its processing page are much simpler, requiring only one look up and a write to activate the account.  Together, this pair could take as long as two days.

 

Use Case: A New User Pre-Registers For The Tradeshow

 

A potential attendee enters the Attendee Registration Site.  She looks at the list of sponsors and at the Tradeshow schedule and decides to register.  She is busy and the registration page is daunting in its scope.  She fills in her name, email address and skips the rest.  When she submits the form, a java script, embedded in the page checks that all required fields have been filled in.  Finding fields unfilled, it alerts her a puts the cursor on the first missing field.  She sighs and fills the rest in.  She gets past the java script and moves on to the form processor.  The form processor catches the post from the login.asp page.  It checks to make sure she hasn’t already registered.  She hasn’t, but it finds her company already in the database.  It adds her as a new but as yet deactivated user attached to her already existing company.  It sends her an email informing her of the confirmation site.  It then thanks her for registering by displaying a thank you page.

 

Five minutes later she receives the confirmation email and she clicks on the URL in the email.  It takes her to the confirmation site where she reenters her email address.  A java script makes sure she filled in her email address and she is passed on the confirmation form processor.  It confirms her email address and that her account is not yet activated.  It then activates her account.  She is ready to attend the Tradeshow.

 

 

The Bulletin Board

 

The Bulletin Board identifies the user and his company through his cookie and does a scan for messages, displaying a list of viewable messages.  Selection of a message displays the message as simple text.  Adding a message is more complex.  Users could have the option to send messages to individual users, companies, or to make them public.  Once they select a message scope and enter a message, the form processor adds the message to the database for later viewing.  We may want to forward any unread messages to the recipient’s email address at the close of the show.

 

 

Site Management Utilities

 

The Site Management Utilities will be bare bones applications with functionality stressed over beauty.  Their purpose is to give Marketing and Sales the ability to control important parts of the Tradeshow database.  All of these utilities will be written in Access.  The setup files will be kept on the Q: drive.

 

There will be four utilities, Contract Manager, Location Editor, Company Editor, and User Activity Monitor.  All will be contained in the same application, under four tabs, each looking something like a spreadsheet.

 

Contract Manager keeps track of Vendors and Advertisers.  It shows the location of the physical contract document, it logs the locations of booths and ads covered by that contract, it keeps notes on issues and conversations pertaining to the contract, and it identifies the company with whom the contract is with.

 

The spreadsheet will show a list of existing contracts.  Contracts cannot be deleted.  They can however, be invalidated by toggling the “valid” flag to no.  Contracts are added by entering a new contract at the bottom of the spreadsheet.  Several of the fields in the spreadsheet will be drop down lists.  The Company field will display a list of existing companies.  The company list can be edited by selecting the Edit Company List button at the bottom of the window.  New contracts are added empty, without booths or ads. The Add Ads button displays the Add Ads window for the selected contract.  Booths must be added to contracts through the Location Editor.

 

The Location Editor maintains the Location List.  The Location List contains one entry for every page in the Tradeshow.  It also identifies locations as booths.

 

On start the Location Editor displays a list of locations sorted by URL.  Booth locations will have a booth name and a contract.  To make a location a booth, you must fill in the booth name and select a contract.

 

The Company Editor maintains the Company List.  Its primary purpose is to create companies for contracts.  It will be a simple spreadsheet list.

 

Lastly is the User Activity Monitor.  It shows a list of the users in the Tradeshow and what they are doing, in real time.

 

Use Case:  Sales Sells A Booth

 

Steve sells Toshiba booth space.  In the process of the sale he introduces them to our Vendor Relations site.  They decide that one of our stock booth designs will work, with some additions.  Steve writes up the contract in Word and faxes a copy to Toshiba.  He then creates a contract entry in the database using Contract Editor, which shows where the Word document is and points to the Toshiba company entry in the database.  He then introduces Toshiba to their booth designer.  She creates a booth site in the Tradeshow Development Site by using the Location Editor and then copies the booth to the Vendor Relations Site where Toshiba can see it and comment on progress.  Then either She or Steve adds the booth to the Toshiba contract.