Final Report for the STIM “Core Site” 
Jim Coleman, Harvard University 

The Team 

The STIM “Core Site” team consisted of Jim Coleman, Project Manager, Sigrid Mueller, Project Editor, and David Soergel, Programmer. Lois Brooks was “on site” manager for the team after Coleman left Stanford in November, 1998. Coleman continued as the “off site” manager through the end of the project period, and was responsible for the organization of the “intellectual content” of the August conference. Rosemary Rogers, Assistant to Tim Lenoir, handled all of the technical details with the conference, and artfully managed the flow of information between all of the PI’s, conference participants, and Team members. 

Evaluation of the Stanford Team 

The report for Year 1 notes the startup difficulties for the STIM project. These included: a lack of appropriate management experience by the original project managers and their supervisors, a lack of sufficient programming resources to carry out the technology required to meet the project’s goals, and the choice of an inappropriate technology at the outset. 

An early evaluation of the staffing resources after Coleman became project manager in November led to one of the original project manager being laid off, and those resources being devoted to a programmer. A similar evaluation of the original technology solution, MediaWeaver, led to its abandonment as well. A full discussion of the technology employed in the Core Site is available as an Appendix, Technology Used in Science and Technology in the Making.

By early in the second project year, the Stanford team was able to deploy all the major technology features (threaded discussion lists, questionnaires, comment sections, file upload). At this point the early frictions between the PI’s and the Team had also been overcome, a good working relationship with all of the PI’s had been established, and all parties were able to make good progress. 

While the Stanford Team was successful overall in accomplishing the tasks it need to do in support of the project and worked well with the PI’s, it is clear that both the early problems and the early departure of Coleman hampered the speed of the startup, and the conclusion technology pieces of the project, cross-site searching and the creation of the originally envisioned CD-ROM version of sites. Neither of these is, we think, crucial to the goals of the project, but both would have added to the value and functionality of the STIM site. 

The STIM Team was also felt both by the Foundation and by some of the PI’s to bear some responsibility in managing, encouraging and coaching the PI’s on how best to make contact with their audiences. Some of this activity included discussions on site design to achieve more “eyeballs”, some included setting up meetings and conference calls between the PI’s and their contacts, some included explorations of what methodologies, both traditional and newfangled, might result in the creation of more content or interactivity. 

There were also problems with the perceived underfunding of the Berkeley site. This led to additional negotiations and requests to the Foundation for additional funds to carry out the work. While the funding issue was resolved to some extent, the Berkeley efforts were never up to the level of the other sites. 

These were tasks that the Project Manager and Team took on because it was essential to the goals of the project, but we were also occasionally uncomfortable assuming a responsibility for the success of the project in areas that was not entirely ours to control. In future federated projects, the Foundation should consider placing the management of finances under the complete control of the project director, rather than dispersing the funds directly to the PI’s, so that s/he has sufficient moral and economic influence on the entire enterprise. 

Evaluation of Technologies Employed 

STIM used five technology approaches to try to drive up interactivity with its target audience: 
  1. Threaded Discussion Lists 
  2. Questionnaires
  3. Comment Sections 
  4. Email
  5. Electronic Submission of Digital Materials 
Of these, I would deem questionnaires and email to be successful it all of the places they were used; threaded discussion lists were successful in the MouseSite and EVOnline, but not elsewhere; and comments and electronic submissions failed to be used much at all.  This suggests that the more “traditional” forms of gathering information, questionnaires and direct contact, should not be overlooked, even when attempting to used more advanced technologies. The experience with discussion lists suggests that they need to be manned and seeded, that is, pertinent individuals need to be enlisted to participate, if they are to work. Facilities to include comments, as raw, unstructured areas of opinion collecting, probably need to be present for the sake of inclusiveness, but we should not expect much from them. As to electronic submissions, the jury is out completely on how such facilities could be made effective. 

In Conclusion: Epigrams from the STIM Experience 

  • It is difficult to transform communities that have a life outside of the Web into communities that work on the Web unless they believe they are doing real work 
  • To be successful, Sloan projects should attempt to integrate the work of the community they wish to address. 
  • To be “sticky”, sites will need to be self-sustaining and provide an archival presence. By self-sustaining, we mean having the ability to continue to generate interesting and useful content; by archival, we mean having the ability to manage that content for the benefit of its users. 
  • The technologies used in such projects should be proven. The support of a research project should not be a research project in itself. 
  • The cost of the infrastructure required is not small; nor is the skill set of the technical team. Invest as much as you can in both. 

Technology Used in 
Science and Technology in the Making

Introduction

Science and Technology in the Making (STIM) consists of five individual projects and associated Web sites. The main goal of STIM is to use the interactive capabilities of the Internet to gather survey information and personal histories, encourage dialogue among the makers of history, and provide an (inter-)active archive in which focus groups are invited to contribute material. Their contributions in the form of stories, artifacts, and written accounts are part of the history presented on the Web sites. This leads historians to multiply the perspectives of contemporary history and engage the community who made the technology in a collaboration to write their own history. Thus, the traditionally silent subjects of a historical study become personally involved in the writing of their community’s history. Organizationally, the technical development for the five STIM Web sites is carried out by the “core” STIM team, located at Stanford University. Four of the five sites are hosted at the main STIM Web site, sloan.stanford.edu, while Berkeley’s project is hosted at sunsite.berkeley.edu except for the “interactive” portions of the site which are carried out at the Stanford site. The content of the site, site design, and implementation is the responsibility of the individual PI’s. The Core Team has been available through the project to assist the PI’s in digitization, reformatting, conversions, HTML, and as consultants on site design and user interface issues. In the course of the project, a set of basic functionality was developed to support the collection of data pertinent to the site and user interaction/interactivity with the site. Some of this functionality was defined formally, some of it grew organically out of the project, some of it was developed for the purposes of site management, and some in support of larger digital library activities. These basic functions are: 
  • User Login/Identification 
  • Threaded User Forums 
  • Questionnaires Specific to a Site 
  • User Submission Of Digital Documents 
  • User Comments 
  • Graphs Of User Data 
  • Tables Of User Data 
  • Site Maintenance Tools For PI’s 
  • Metadata Cataloging 

Basic Functionality

USER LOGIN 

User login/identification is gathered in a variety of places. For the EVOnline site, EV users/owners are encouraged to log into the site as they enter it, and to answer a questionnaire; the logon enables the system to keep track of what sections of the questionnaire a user has completed. The user name is chosen by the user, and is not associated with an actual name, although other demographic information, including e-mail account, is solicited. 

For other sites, the user login/identification facility is part of other functions, i.e., part of submission of digital documents, or participation in a Web site. In all of the sites, threaded user forums require entering a name, although submissions may be made anonymous to the site. 

There was much discussion about requiring users to log into each site as they entered, and to develop a system to track user movement/navigation through the site. After much discussion, most PI’s decided that such a login requirement would be a disincentive to participation, and a more sophisticated version of user login/tracking was unnecessary. The only user tracking occurs for the EVOnline questionnaire, as explained above. 

QUESTIONNAIRES

Two sites use questionnaires to gather data: EVOnline and the Blackout Site. The questionnaires are delivered as Web pages. In the case of the EVOnline survey, the pages are divided into four segments, due to the length of the survey. User logon is used to keep track of which segments a given user has completed. 

THREADED USER FORUMS 

Among the principal components supporting user interaction are threaded user forums. Each site has at least one forum, most have several devoted to several, occasionally changing topics. EVOnline permits users to suggest topic threads. Two of the sites give the site administrator the ability to “publish” forum entries. That is, the individual entry is not posted to the site immediately, but goes through a Web form-based “publication” procedure where the site administrator can alter or edit the entry if appropriate. In these cases, the original entry is preserved. 

The information gathered from forum to forum differs somewhat, as does the appearance of the messages submitted. In each case, however, users can see all of the contributions in an “outline” form, can then navigate to individual entries, respond to those entries, or start a new thread on the topic. If an entry receives a response, the original author is informed of the response via email (if an email address has been supplied). The amount of required information varies from site to site. Most forums require users to submit names, all permit the forum entries to appear as anonymous entries. 

USER SUBMISSION OF DIGITAL DOCUMENTS 

Since one of the purposes of the project was to encourage the submission of digital information from the user communities, facilities have been developed to permit the submission of digital materials directly through a Web form. Users submitting files are asked for information pertaining to author, title, source, file and resource type, and keywords. Site administrators are then notified of the file submission, can examine the file and then take appropriate action. 

USER COMMENTS 

EVOnline and the Blackout site also have employed a general “comment” facility that allows users to submit comments about the site on almost every page. The Blackout site has extended this facility to include tracking information. That is, the system keeps track of where a user was when the “comment” button was pushed. The user can then specify the type of comment: a comment about this page, a general comment, and so on. The “comments” themselves are posted within the site for the Blackout Site, but not for EVOnline. 

GRAPHS OF USER DATA 

A Java-based graphing applet (PopChart) is used in EVOnline to supply graphs of data extracted from the surveys. 

TABLES OF USER DATA 

HTML tables of user data extracted from surveys have been developed for the Blackout Site and EVOnline. The interface permits the user to select the fields he/she wants to view. The list of fields can be restricted by the site administrator so that personal or sensitive information is not disclosed. 

METADATA CATALOGING 

Each resource in the site-archival files, comment pages, digital documents, tables, graphs, user forums-can be cataloged by a site administrator using a metadata scheme corresponding to the Dublin Core. This resource-level metadata cataloging is then used to perform “smart” site searches. 

In the case of the Blackout site, the metadata scheme has been greatly extended to permit the site administrator, or any other so-enabled user, to establish a series of complex relationships between any two objects or sets of objects. In theory, this scheme would permit any user to construct his own “site” or view of the site out of portions of the site. For the PI, this facility permits the ad hoc construction of interlinking pages through changes to the metadata structure. 

SITE MAINTENANCE TOOLS FOR PI’S 

A series of Web-based tools have been developed to permit the PI’s to change their sites dynamically. These include: 
  • Web form to change/set forum topics 
  • Web form to archive form topics 
  • Web form to publish forum topics 
  • Web form to set fields that can be shown in a public table view 
  • “private” view of entire tables 
  • “private” view of all submitted data 
  • email notifications when: 
  • objects have been submitted by users 
  • new forum topics have been suggested 
  • new forum entries are available for editing 
  • comments have been submitted 

Technologies Employed

WEB/DATABASE SERVER SOFTWARE 

STIM uses the Netscape FastTrack server, version 3.1, to provide Web services. The server is a Sun Ultra 1, running Solaris 2.6. RDMBS services are provided by Oracle, version 7.2.5. 

COLD FUSION FOR APPLICATION DEVELOPMENT 

With the exception of the Blackout Site, Cold Fusion, version 3.1, is used as the main application development environment for questionnaires, user forums, comments, file submissions, table views of user data, and the site maintenance tools. 

WEBOBJECTS FOR APPLICATION DEVELOPMENT 

WebObjects is used for all of the user interactivity functions within the Blackout site. It is also used for the metadata cataloging modules. Given the complexity of the overall metadata model, and the specific complexity of Blackout Site, WebObjects proved to be a better development environment, even given its significant learning curve. 

RDBMS USE IN THE APPLICATION DEVELOPMENT ENVIRONMENT 

Virtually all of the user interaction/interactivity and site management functionality in STIM is derived from tables set up in Oracle. 

For user logon, a single table tracks user logon and session information while in EVOnline. 

For questionnaires, in general, each questionnaire is a single Oracle table. User responses are mapped into table fields, with the application being responsible for error trapping where this is not excluded through the design of the form. In EVOnline, each questionnaire “page” is a separate table. 

For user forums , a series of four tables manage information gathered by users, legitimate forum names, current forum topics, previous forum topics, and threading. The generation of all of the forum pages is dependent on specific application calls to the database, and each page in these sections is generated on the fly out of data residing in the appropriate tables. Since one of the required functions is the ability to change user submitted data, a separate “archive” table gathers this information. Within the main forum table, entries are flagged if they are have been changed as part of an editing process. All of the forum entries are part of the same table to facilitate cross-forum searching from the main STIM site. 

For comments, a series of tables likewise manages all of the comments submitted, along with user information. 

For user submission of digital documents , tables manage the metadata associated with the object. Current the object is stored in Unix file space, not a table, until the PI determines the dispensation of the object. 

For the graphing applet , the data is extracted from the database via a SQL query, and passed as text strings into the applet. The applet architecture of our version did not support direct calls to Oracle. 

For the table views of data, a table containing user selectable fields is used to control what information is capable of being passed onto the user. This is more flexible, but for the current applications, hard-coded views would have been as effective, and perhaps more efficient. 

For metadata cataloging, a series of tables, one for each field, manages the data. [N.B.: it should be noted that the relational model is not ideal for metadata cataloging using structures like Dublin Core or RDF. Here the benefits of an object oriented model might be more fully realized.] 

OTHER TOOLS 

Other tools used in the creation of the STIM site included Web authoring programs, such as NetObjects Fusion, Adobe Capture for the creation of PDF’s from page images, Photoshop for general Web graphics work, PowerPoint for embedded slides, and Oracle Web tools for data capture/extraction.