Yale Library WWW Task Force Report

Submitted July 24, 1996

Members of the Task Force:


Matthew Beacom, Cataloging Department
Ellen Cordes, Beinecke Library
Kenny Marone, Medical Library
Fred Martz, Systems Office
Ann Okerson, Collection Development

I. Executive Summary of Recommendations

II. Framing the Issues

III. Charge to the Task Force

IV. What is "Vanilla?"

V. The Library's Investment

VI. Distributing the Labor: University and Library Roles

Appendices

I. Executive Summary of the Report of the WWW Task Force

In some departments of the Library, individuals' work has been leveraged into exemplary Web services. For example, the Medical Library has been especially successful as a whole, and some smaller libraries and collections such as Divinity are powerful and attractive instantiations and models for others.^[1] In fact, the Library boasts many WWW success stories, too numerous to do justice to in a brief report. Our Task Force believes that the considerable success of certain departmental ventures grows from several factors: the managers of the departments place significant value on the Web and designate it as a high priority; primary responsibility for Web development and coordination is delegated to one person who is either named or takes on the duties of local Webmaster; and the rest of the staff work closely with the Webmaster, learning the basics of the technology and creating resources through it.

In 1994, the Networked Information Support Group, chaired by Alan Solomon (now head of the Research Services and Collections Department), created a Web Development Group as a companion to the existing Gopher Development Group. This Web Development Group in turn evolved into a Library-wide Web Working Group whose purpose was to encourage and leverage the numerous individual and departmental Web-related efforts throughout the Yale Libary system. This group of 20 members is chaired by Lisa Spar (Law Library). In addition to her work in the Law Library (and in general after hours), Lisa invests on average a half day a week or more as an informal coordinator, editor, and Web innovator at the Library-wide level. Others in the group bring this level of commitment and volunteerism to their parts of WWW development. The group meets when possible, though it is difficult to frequently convene such a large, representative group.

As the Working Group's efforts have progressed, the demands for design, coordination, up to date technical skills, and editorial control have grown out of proportion with the time that members can readily spend on these activities. It has been impossible to keep up with the numerous enhancements to html, browsers, software, design and functionality. Furthermore, though clear lines of responsibility and authority for Web development may exist to greater or lesser extents for parts of the Yale Library, no such clarity has yet been built into the overall system. By early 1996, a growing number of voices, in particular those of the AUL for Public Services, called for additional overall improvement and institutionalization of the Yale Library Web. Our Task Force was convened to recommend how that might happen and was asked particularly to concentrate on how to improve what Don Waters, AUL for Systems and Technical Services termed the "vanilla" components of the Library's Web, the components that demand some overall consistency from every department and every librarian who contributes to it.

During this work, our Task Force talked with Lisa Spar, coming to recognize and applaud the WWW Working Group's tremendous achievements in unifying some of the thousand flowers that have bloomed on the Library's Web. We also heard from Sarah Prown (SML), a leader in this area, about her considerable efforts for the Research Workstation. Under the guidance of Matthew Beacom, we also explored and discussed several library Web sites that seemed relevant or exemplary (some these are enumerated and discussed briefly in an appendix). In this report we address both the "vanilla" aspects of Library information on the Web and a means for achieving consistency over time. We believe those two themes cannot easily be separated.

We try to separate what needs to be accomplished, from how to accomplish it, and though we present structural ideas for the "how to," we leave the details for those who will be charged with the next phase of WWW coordination. In short, we believe that independent and skimpily coordinated efforts cannot easily achieve a unified look and feel for the Library's Web, let alone continuously update general information.

An internal WEB site for staff use: For some external examples, seehttp://infoshare1.p rinceton.edu/tech/hptsd.html, the web site for Princeton's library's technical services department, or at http://staffweb.lib.washi ngton.edu/acq/, Peter Stevens's University of Washington WWW site for his acquisitions department. Some examples of internal sites under development for the Yale Library include: Staff New, renovation, technical services manuals, and Medical under development http://www.med.yale.edu/library/admin/intranet/

WEB style guide for Web-creators in the Library to follow

A. The requisite level of technical skill to implement specific web designs needs to be centralized within the Library system. It is not efficient for everyone who develops home pages to keep up with all the enhancements that may be of use. Further, the identification and dedication of this skill should be associated with an outreach/training function: the person doing this task should also be paying attention to how best to disseminate established skills to the community and how to apportion responsibilities between the Library and C & IS. (For example, three years ago HTML was an arcane skill; today it is everywhere. Today, java and the like are arcane; the person who can do these things is also the person to push others to learn them as they become more widely understood, while moving his/her own skills on to whatever next level of novelty arises.). The individual assigned this responsibility for technical skills would serve on the proposed campus-wide Web developers group. The necessary staffing is at least 1/2 FTE.

B. Additionally, a clear single focus of editorial authority is needed, in particular for the "vanilla" items. This is best achieved through appointment of a single WWW Editor. That is not to say that this editor should work in a vacuum, nor that she or he should have unlimited authority. In the present environment, there is a great deal of distributed authority and many eyes are brought to bear on WWW-making. What is needed is one active intelligence that goes out through the library's WWW pages, looking for inconsistency, incompleteness, inelegance; making editorial decisions about what to support and what to discourage; then working with individuals who provide and maintain pages to help them make a contribution that fits into the wider program effectively. The necessary staffing is at least 1/2 FTE.

C. The broad authority of the centralized WWW position (s) will have effect if backed by an Advisory/executive Committee (no more than five members) empowered to take up sticky issues -- unresolved disagreements, issues requiring funding to resolve, issues involving conflicts with Yale offices outside the Library, etc. -- resolve them where appropriate, refer them to others where appropriate, and thus give authoritative guidance to the editor.

Next steps:

• A. A suitable individual(s) should be identified and appointed as soon as possible. The LMC may choose to reallocate duties or create de novo positions. It may choose to use part of two positions with different skills or integrate the two skill sets described above. In fact, the WWW Task Force believes that the Library needs to seek the above-described technical, training, and editorial skills in one person called the Webmaster. The initial duties will be:

(1) to make rapid progress in improving the current WWW site and

(2) to determine what level of staffing is required for the medium term.

• B. An Advisory Committee should be identified and appointed as soon as possible.
  
  The Task Force proposes that the Advisory Committee be chaired by the AUL for Public Services and staffed by the person(s) described above. Committee members will include one person from SML public services/instruction; one person from a school/departmental Library's public services staff; from cataloging; from systems; and from special collections (Beinecke or MS&A). This group will periodically report to LMC. Additionally, it will keep the Library in general informed about additions and changes to the Library's Web.
  
  The Advisory Committee will be charged with reviewing questions of staffing level and with bringing forward recommendations of appropriate resources over time. Once this person is in place, additional committees will probably need to be created support the Library's Web work (See Appendix 3: "Medical Library WWW Committee Structure" for an effective MODEL.)

---

VI. Distributing the Labor: University and Library Roles

The Front Door represented all of Yale, and required substantial managerial and technical care. The Web was now a major responsibility, and it was time to move that responsibility to an institutional home. Day-to-day operations of the Front Door were transferred to ACS [Academic Computing Section]. . . . In only two years, the Front Door had evolved from the exploratory musings of the technically enabled to an image-bearing tool that required the imprimatur of the President.^[2]

The challenges and issues facing the Library in redesigning the Library Home Page are very similar to those faced by the University in designing Yale's Front Door (as described fully Rob Callum's article). The relationship between the Front Door and YaleInfo is similar to the relationship between the Library Home Page and the Research Workstation, one aimed at providing information to visitors, and the other oriented toward the local constituency (the research community in the case of the Library). The Library's efforts must be well coordinated with the University's efforts in order to present a consistent and well organized presence on the Web for Yale. In turn, the University's efforts can be particularly beneficial to the Library. While there is recognition of the power of such a relationship, it can be further improved. There are four areas of potential cooperation and coordination between the Library and the Computer Center (soon to be renamed Information Technology Services); past success in these areas has varied considerably.

Area of Cooperation/Grade

Navigation/Page Design	A
Content	B
Instructional Services	C (improving)
Technical Development	D

A. University Web Navigation / Page Design

C&IS coordinates content and design for the University's Web page subject to final review by a high-level University advisory board. Matthew Beacom and Sarah Prown serve as Library representatives to the six- member design team for the Yale Front Door. Leon Marr and Molly Simpson represent C&IS, Lisa Tremaine serves as graphic design consultant, and Phil Long chairs the group. The Library members have made their greatest contribution in cataloging and organizing the information presented through the Yale Front Door. Their creative efforts and mediation skills are also highly valued. Coordination between the Library and C&IS in this area has been very successful. The Task Force believes that the current structure for the Front Door should remain in place. The group is small and experienced, with the correct mix of skills needed to achieve the necessary results.

B. Suppliers of Web Content to the University

YaleInfo provides the content for most of the University pages. The Yale Front Door serves as a convenient visitors' guide to the extensive resources available in YaleInfo. Lower-level YaleInfo pages are developed by a wide variety of Yale organizations, much as the departmental pages of the Library web are maintained by individual units. While this diversity of responsibility leads to inconsistent content, it also promotes innovation and creativity which could be severely compromised by centralized control. C&IS is in the process of reviewing the content of YaleInfo and will concentrate on improving weak areas and on converting the remaining Gopher pages. The Design Team will review all revisions and the Library members will consequently have an opportunity to assess the impact on Library pages. A topic that needs to be addressed is the blurring boundaries between general University menu items and Library menu items. For example, if the Library buys a newsfeed (Clarinet is under consideration), does it link at the Library or at a more general university level?

C. Training Members of the University Community in Web Development.

This area presents one of the best opportunities for additional synergies between the Library and University (C&IS). In general, the staff who have built the Library's Web pages and services are self-taught. These staff in turn teach their colleagues and so on. Individuals including Matthew Beacom, Holly Grosetta-Nardini, Sarah Prown, David Stern and others have trained both staff and students in formal and in informal settings. Coordination of Internet instructional services between the Library and C&IS is a relatively new development. Staff from the IIC (Internet Information Center) frequently attend the Advanced Internet sessions conducted by the Library and the Library regularly directs patrons to the excellent information resources provided on the Web by the IIC (http://www.yale.edu/iic). Given the increased focus on instruction in the Library and C&IS's strong interest in expanding educational offerings, there are many opportunities for increased cooperation in this area. C&IS is particularly interested in offering classes in HTML publishing aimed at various levels from the beginner to the sophisticated publisher. Our Task Force suggests that assignment of responsibility in this area be discussed at appropriate levels. For example, a useful division of labor could be that C&IS teaches basic WWW and HTML classes to students, faculty, and staff, while the Library focuses on training them to use the Web for research and for classroom work.

D. Technical Development

Most in need of improved coordination is the area of technical development and Unix operations. The Library and C&IS (and Medical computing) have developed their Web servers independently. Hardware and software vary and supported services are not consistent across the different organizations. Library Web development could benefit greatly from increased cooperation between Systems Office technical staff and their counterparts at C&IS. An especially important need that dedicated C & IS staff could meet is continuing exploration and analysis of Web-related software; that is, this is an opportunity for C & IS to take a leadership role. The pace of software development is so rapid that no individual can evaluate all the new Web-based programming tools, server software, browsers, plug-ins, and HTML authoring packages. Furthermore, many of the new tools now require licensing and purchasing, which in turn carries budgetary implications. The Task Force urges that C &IS undertake the primarily responsibility in this technical area and that a University-wide Web developers group, under coordination of C&IS, be established to disseminate knowledge and share experience.

E. Copyright and Licensing Matters

The Library has considerable understanding of copyright and licensing, an expertise that C & IS would like to take advantage of in Web development. Copyright matters clearly underlie all the information that appears on the Yale Web and need to be managed correctly and effectively both for internally created and externally linked resources. Whether the copyright issues can be managed by a small WWW subgroup or need to be handled as part of larger University copyright needs, is a question that needs also to be addressed.

F. General

While there has been substantial coordination and synergy related to Web activities between the Library and C&IS at the front-line practitioner level (Matthew Beacom and Sarah Prown), and recently at the highest level (Ann Okerson, Don Waters and Dan Updegrove) -- and these must continue -- there is need for increased discussion and planning at a middle level (Fred Martz and Phil Long) and across departments at the higher levels. Fred and Phil have resolved to meet regularly to review progress and exchange information of mutual interest and value. One important area of current interest is patron authentication and secure Web services. In short, the University Web, like the Library Web, is no longer a grassroots movement. Cooperative arrangements between the Library and others in the University require continuous collaboration and interaction at different levels.

Appendices

Appendix 1: Webmaster Draft Job Description

Appendix 2: What the Butler Saw When Looking at Research Library Web Sites: Primary Issues for the Webmaster

Appendix 3: Medical Library WWW Committee Structure

Appendix 4: Assumptions of the WWW Task Force During the Writing of this Report

---

Appendix 1: Webmaster General Draft Job Description

The general description indicates the duties that the Webmaster will perform and the qualifications that the Yale Library will seek in such a position. It is not intended to be a definitive position description.

The Yale Library seeks an individual who works effectively in a team and project oriented environment, who has initiative and creativity, and who demonstrates the ability to provide a broad range of Web services as well as the willingness to explore enhanced information services that reach beyond the boundaries of the traditional library. This person will facilitate development of a library wide Web-based common interface to multiple proprietary systems and with other internal or external electronic resources including full-text/image resources. This person will work collaboratively with colleagues throughout the Yale Library and University. This person will support the development of Web-based forms for access to library resources and services and facilitate CGI scripts to enable forms to serve as an interface to the library systems including electronic mail, application program interfaces and protocol gateways. This person will help redefine the role of a library in an electronic environment.

QUALIFICATIONS

• Demonstrated ability to work collaboratively with colleagues, faculty, students, and staff.
  
• Flexibility and the ability to work well in a demanding, rapidly changing environment.
  
• Evidence of creative activities.
  
• Excellent interpersonal, oral, writing, presentation, and problem solving skills.
  
• Supervisory or project leadership experience or demonstrated potential.
  
• Demonstrated knowledge and expertise using information, retrieval systems and services, including the Internet and World Wide Web.

---

Appendix 2 -- What the Butler Saw When Looking at Research Library Web Sites: Primary Issues for the Webmaster

This analysis of the state of research Library web sites contains three parts. This appendix helps identify underlying issues in creating Web pages with consistent look and feel for the users. The Task Force includes these as the primary sites it reviewed in discussing "vanilla" issues. The questions below will be among the first to be addressed by the Webmaster.

A. Six basics of web site design

B: Two hot issues of web site design

• 1. Graphics-rich versus text-based web page designs
• 2. Uniform versus varied site designs

---

A. The Six Basics: Audience, Purpose, Content, Organization, Presentation, and Operation.

The initial questions one must answer when creating a Web site fit into these six topics: audience, purpose, content, organization, presentation, and operation. Anyone making a Web site should explicitly ask the following questions, and anyone evaluating a Web site should judge it in part by how well these questions have been answered in practice.

• 1. Audience: who uses the site? Is there one audience or several? If several, do the audiences have equal importance? Which audience is the most important for one's institution? Do the different audiences have different needs, interests, purposes? Are there various ways to categorize those audiences, for example: faculty, students, staff; naive users, expert users; affiliates, visitors.
• 2. Purpose: why are the members of the audiences using this Web site? What are they gaining? What does the institution gain from having people use the Web site?
• 3. Content: what does the Web site contain? Text, numbers, images? Documents, services, databases? Are the contents relatively stable or dynamic? How much content is there? Ten pages of text or millions? 20 images or 50,000? Are the contents interactive (Web forms, SQL queries, etc.) or static (scanned documents, digitized images, etc.) What will the Web site contain? How fast is it growing? What parts are growing the most?
• 4. Organization: how is the content in the Web site arranged so the members of the audiences can use the material to fulfil their purposes? Does the organization create a navigable environment? Navigable for whom? Are there many ways to find one item? Does the organization support both searching and browsing strategies? Is the organization flexible or rigid? Will the organization support expansion of content? Changes in the nature of the content?
• 5. Presentation: How well does the presentation style fit with the organization of the content, the content itself, the purpose of the Web site, and the audiences it serves? Are images used as illustrations or icons? Is the layout linear, tabular, graphical? How has typography been used to indicate importance, sequence, or hierarchy? Is wording consistent and clear?
• 6. Operation: how is the site being maintained? Who is responsible? Is there a plan for growth? Are there written procedures or guidelines for contributors or producers of the content? Is there a policy statement? How is the site being evaluated by the institution that created it?

B. Hot Issues of Web Design

1. Graphics-rich versus text-based Web page design

Beyond the obvious reason (pictures are pretty), graphics-rich designs can be deeply appealing to both users and producers of web pages because such designs can convey a great deal of information in a small space and present a coherent institutional identity. On the other hand, using text-based Web Page design can present information more compactly and does not disenfranchise users of the Web site that may not have computing or communications equipment that supports graphics-rich material. As widespread access to sufficient computing power and adequate communication speeds improves, graphics-rich designs are becoming more common.

For an example, see the test design for the Library of Congress at

http://lcweb.loc.gov:8081/homepage/lchp.html

Even in a high-powered, high-speed networked computing environment, another obstacle to using graphics-rich designs for Web sites remains: creating a publication-quality, graphics-rich site requires sophisticated graphic design skills. Creating such a site -- especially creating the graphics and agreeing to use the graphics -- takes much more time than does creating a text-based Web site.

For purposes of comparison, look at the opening pages of the web sites for UC Berkeley Libraries (a graphics-rich design):

http://infolib.berkeley.edu/

and for U Penn (a text-based design) at:

http://www.library.upenn.edu/

Each opening page is a concise introduction to the library and a starting place for using the library, but each looks very different than the other. U Penn has 10 categories and 6 buttons for resources. Four of the buttons duplicate the 10 categories, so one has 12 options on this opening page. UC Berkeley has 8 icons for resources, repeats those 8 icons with text links, and has 2 search tools at the bottom of the page, so one has 10 options on this opening page. While the difference in appearance is most striking, what these two pages accomplish for library patrons is very similar. And the differences in what the pages do has more to do with decisions about organization and content than with graphic or text-based approaches to the page design.

For another example of a graphics-rich design see the New York Public Library at:

http://www.nypl.org/index.html

For other examples of text-based designs see the Yale Medical Library at:

http://www.med.yale.edu/library/welcome.html

The University of Virginia Library at:

http://www.lib.virginia.edu/

and Cornell University Library at:

http://www.library.cornell.edu/

None of these is as concise as U Penn's.

2. Uniform versus varied site designs

The second hot issue relates to how unified in design or look and feel the separate pages of a Web site should be. There are two themes in the arguments that favor a uniform design: branding and navigability. Branding, or creating a consistent institutional identity, through the use of set conventions involving images, typography, layout, and some content is highly desirable for the institution producing the site. Branding clearly identifies who is responsible for the Web pages being used, and the set of conventions used provides the institution with some control over the product (Web pages, online services, etc.) it creates. A Web site that is created so that navigating it is easy -- logical, seamless, intuitive, direct -- is highly desirable for the people using it. The set of conventions one uses to brand pages in a Web site may also serve to render it navigable. Branding can help those using a site know where they are, know when they are in your site and when they have left it, and know how to get to other parts of your site from where they are.

The argument against the uniform design is twofold: a uniform design can stifle innovation and the goals of branding and navigability could be achievable by less restrictive means. A uniform design hinders innovation by establishing a set of conventions that blocks design solutions that are appropriate for a particular part of a larger institution. A design suitable for Yale Library may be too generic for the Yale Library Manuscripts and Archives, or Yale Divinity Library, or Beinecke. A uniform design slows innovations that improve upon past achievements by constraining the producers of new Web pages within the institutional web site. In an arena as new as providing library services via the WWW and as dynamic as the Internet, slowing innovation is a bad idea. Supporting innovations, guiding them, and disseminating them are good ideas. The strongest argument in favor of varied design is that the producers of particular web pages or portions of the institutional web site need a large degree of autonomy in order to be free to innovate. Such autonomy and innovation will result in a less-than-uniform design, but the goals of branding and navigability may be achieved by a small set of broadly conceived guidelines that may be adapted by the many producers of institutional web pages.

---

Appendix 3: Medical Library WWW Committee Structure

(we'll need to scan this in or something.)

---

Appendix 4: Assumptions of the WWW Task Force During the Writing of this Report

1. The Web is preferable to other forms of electronic presentation and communication.

2. Coordination of the Web enterprise in the Yale Library falls is part of Public Services.

3. Flexibility and room for creativity are one of the main goals that the Library needs to achieve in whatever structure it proposes for the development of its Web.

4. Many diverse efforts by many people in many subject areas are needed to create a successful Web site for the Library; these need to be coordinated.

5. Improvement cannot happen without investment.

6. The Web is not a brand new activity; its use has been incremental. The need for resources is not because of newness but because of the growing size/scale of the activity.

7a. The various departments of the Library are partners in the Web enterprise. 7b. The different departments of Yale University are partners togeter in the Web enterprise.

8. The Library Webmaster work can be accomplished in more than one way.

9. The Medical Library Web site and staffing serves as a model for the rest of the Library; however there is no one model to pick and imitate.

Notes

[1] Medical Library URL: http://www.med.yale.edu/library/ Divinity URL: http://www.library.yale.edu/div/divhome.htm

[2] See Rob Callum's article in the April issue of Omnibus, URL: http://www.yale.edu/omnibus/Apr96/front_door.html