Back to StaffWeb Index

June 22, 1999

To: Ross Atkinson

From: StaffWeb Committee (Michael Engle, Elaine Engst, Diane Hillmann [chair], Pat Viele, Cheryl Stadel-Bevans [ex-officio])

StaffWeb Interim Report

I. Charge from Ross Atkinson, March 30, 1999:

The purpose of the StaffWeb page is to provide easy access to information that will assist CUL staff in fulfilling their work responsibilities. The StaffWeb should ultimately include all CUL policies, operations manuals, local directories, and the recent minutes or notes of key library groups. It can also contain any other information that would be helpful to CUL staff.

The purpose of the StaffWeb Committee will be to design, update and maintain the StaffWeb page. This work will entail decisions on both the form and content of the page, which should be made on the basis of your own good judgment as well as input from staff users of the page from throughout the CUL system. The Committee should keep in regular touch with staff, both through the standard systemwide groups (e.g., IRPC, TSEG) and through CU-LIB, in order to obtain feedback on the current state of the StaffWeb page and on new needs that can be fulfilled through the StaffWeb page.

Please concentrate your work initially in three areas:

1. Action plan. Please draft a plan for both the form and content of the current StaffWeb page. I will then assist you in staffing this plan through the CUL system to obtain input.

2. Security. In considering content, please draft a specific recommendation with respect to access limitations. Because the StaffWeb is publicly accessible, we need guidelines as to what information should be made available publicly on the StaffWeb page, and what information should receive more limited distribution. I will then take this recommendation to LMT for their consideration.

3. Maintenance. As a supplement to your draft plan for the form and content of the StaffWeb page, please map out the procedures and resources needed for longer-term maintenance. What should be the specific responsibilities of the StaffWeb Committee? If more resources are needed to maintain the StaffWeb than are currently available, exactly what kinds of resources would be required? How should older material from the StaffWeb page be deselected and archived?

II. Reorganization

In the interests of exploring alternative front pages to the StaffWeb, we mocked up two alternative pages, reorganizing the current StaffWeb page, and trying to suggest different possibilities. First we looked at all the possibilities on a webpage created by the Web4Libs group, in response to a query by Michael Engle:

http://staffweb.library.vanderbilt.edu/breeding/staffwebs.html

This exercise gave us a feel for what others had done. From these we chose two we particularly liked and mocked up two alternatives "in the style of" those we particularly admired. Please note that we did not necessarily make all the links live--these mockups are primarily designed to show the possible organization of the pages.

These two mockups are available at:

1. http://www.library.cornell.edu/okuref/staffweb/staffweb1.html (in the style of Columbia University)

2. http://128.253.121.110/staffweb/BerkeleyStyle.html (in the style of UC-Berkeley)

A feedback form also exists at http://www.library.cornell.edu/okuref/staffweb/review.html--each mockup contains a link to the form.

Some efforts are already underway to improve the organization of the committee minutes. Lists of minutes are being changed to reverse chronological order, and those older than two years are being moved to archive pages--still accessible, but not contributing to scrolling burden.

III. Revitalization

The group spent some time exploring options for adding to staffweb, and have taken the following steps:

We hope that a survey we're proposing to include as part of our review and comment of the proposed redesign of the StaffWeb will garner additional ideas for inclusion.

IV. Security Issues for CUL StaffWeb

Currently, access to StaffWeb is completely open--anyone with an Internet connection and URL can access the material there, including Web search engines and robots. This level of openness has made some staff and administrators uncomfortable, particularly as Internet security in general has become more of an issue.

In fact, most of the information now on StaffWeb, though really intended for (and presumably primarily of interest to) CUL Library staff, is no different than what was previously available in paper. The bulk of the information has already appeared on CU-Lib or is directed to StaffWeb specifically to be made widely available--although for the most part little thought is given to possible interest outside the library system. Other information, such as Procedure 13, has been regularly forwarded to outside requestors in paper--its presence on StaffWeb saves photocopying, postage and staff time.

What, then, are the underlying security concerns? I have been asked, "Do we really want all our meeting minutes available to just anyone?" Though it may be somewhat startling the first time one tries it, a web search of any name appearing regularly in CUL meeting minutes brings back quite an astounding number of hits. Whether or not this is perceived as a problem depends almost entirely upon the individual and his or her familiarity with the Web in general--HOW it is a problem seems to be less easy to answer.

Some discussion of the known uses of this information by "outsiders" might help. Former staff members now at other institutions have reported reading minutes of committees they served on while at Cornell. There has also been at least one case of a prospective employee cruising the StaffWeb looking for clues as to what might be the burning issues at Cornell before arriving here on an interview. Neither of these known uses seems particularly inappropriate.

Certainly there are many documents generated by staff at CUL which definitely should not be public, but it's hard to perceive how those might find their way to StaffWeb without some malice aforethought or egregious error. In general, the "filtering" of public and non-public information occurs prior to the time minutes and reports are distributed, no matter the medium. The same distinctions about what should and should not go outside the committee room have been made by committees and groups since the days that distribution was entirely in paper, and are applied in much the same way in the electronic environment.

To rely on inaccessibility as a protective device seems somehow contrary to the mission of the libraries. Perhaps it is true that there is some need for guidelines for what should and should not appear on StaffWeb, but in the absence of a concrete situation when something that should not have been released was indeed made public, it's difficult to make the case that something is broken.

However, in the interests of exploring possible options and tradeoffs, we offer the following options for consideration:

  1. No restrictions. This our current default. Examples of other unrestricted Staff Web sites reside at http://staffweb.library.vanderbilt.edu/breeding/staffwebs.html
  2. Robot exclusion. This is probably the least effective. It excludes "friendly" robots which, in practice probably means that the staff pages will not appear in search results on major Web search engines AltaVista, Hotbot, Excite, InfoSeek, etc. "Unfriendly" robots will ignore the exclusion.

    The next three alternatives are roughly equal in effect:

  3. Basic authorization. Access to pages in the library Web site would be limited to anyone who knows the current user id and password. In practice, the user id and password would likely be sent out on CU-Lib to all staff, and nothing prevents the library staff from giving the user id and password to others. A configuration file is set on the Web server to protect all files in a specified directory--the first time a user logs in, a file is created for that person that is rechecked each time that person logs in again.
  4. Kerberos authenication. This requires that the SideCar software be running on the user's computer. Access can be limited to only Cornell staff, only Cornell students, only Cornell faculty, or any combination of these categories. CIT runs FrontCar software that traps the IP address and sends it to the Kerberos server to check against a database maintained by CIT based on Human Resources records. The user must enter their net id and password, and must also have the proper status (staff, student, faculty). This option cannot be limited to library staff only. The advantage is that it doesn't require remembering a separate id/password, since presumably everyone knows their net id and password. The downside is that the HR database not entirely clean and up-to-date.
  5. IP address checking. The simplest method, but limited to a specific list of IP addresses. Software called TCP wrapper checks the incoming IP address against a list of approved addresses. No ids or passwords required for this option Staff using any outside ISP (AOL, RoadRunner) will not have access, though EZ-Remote users would. In essence, access is limited to a set of locations on the local network at Cornell. This is not a very flexible or discriminating option, though presumably some of the drawbacks would be eliminated by the proxy server planned for fall implementation.

No other forms of security are likely to be implemented at Cornell, either because of the cost (i.e., a campus-wide firewall) or because of complexity and software dependence.

V. Ongoing Support and Maintenance

At present StaffWeb is maintained by the Technical Services Support Unit. Aside from some links to separately maintained committee pages, all the markup and basic maintenance is done by someone in TSSU. Simple routines have been established to take care of the committee minutes, and as they are easy to capture from CU-Lib and manage via templates, this portion of the task is not particularly onerous, and the timeframe flexible. The less frequent report that must be mounted ASAP, complete with embedded tables and an assumption that it must be easily printable, is more problematic.

Continued exclusive reliance on TSSU resources may unnecessarily limit the possibilities for growth of StaffWeb or make timely response to staff needs difficult. It is also not explicitly part of the TSSU charge, and resides there primarily because of the initiative taken several years ago when the need became apparent. Without administrative sources of support for ongoing maintenance, the burden may be less bearable over time for a small unit like TSSU.

"Support" in this context could take many forms. Administrative staff could learn to do HTML coding for documents they wish to make available, leaving only the task of mounting and linking documents to TSSU. Actual funding to offset the time spent by TSSU staff on StaffWeb work is another option, though given fluctuating demands, it could be challenging to determine what would be necessary and equitable.

Some requirements for mounting information on StaffWeb could be made more explicitly, thus in effect pushing some of the burden off on those desiring documents on Staffweb, and lessening the burden on TSSU. Some such requirements would need to be supported by CUL administration for them to be enforceable, but this, presumably, could be part of the Committee's task for next year.

VI. Archiving

Preliminary recommendations for library staff web pages that will aid in maintaining and migrating these pages for archival purposes:

  1. All pages should include metadata to help identify and describe the pages and their purpose. Whenever possible, current standards or best practices for metadata, such as the Dublin Core, should be followed. A template will be available for use in the fall.
  2. Pages should be kept simple and encoded in plain HTML. Plain HTML utilizes ASCII text, which can be readily maintained and migrated as needed. The inclusion of scripts, images, etc., requires additional software. Often this additional software creates problems when files need to migrated. Elements such as images and scripts should be avoided in library staff web pages whenever possible to aid in the preservation process.

VII. Action Plan

For the summer, we would like to make the Interim Report and mockups available for comment by staff, and gather suggestions and reactions from as many people as possible before getting started again in the fall.

In fall we can implement a newly reorganized front page, add the new resources to the mix, review the comments and suggestions, and move forward on a plan for continued maintenance and growth.

7/9/99 dih

Back to StaffWeb Index