Do You Have the Right Stuff? Seven Areas of Expertise for Successful Web Site Design in Libraries Jerilyn R. Veldof Shane Nackerud ABSTRACT. In the mid-1990s it was common for one person in the technology department to design or redesign the library’s Web site. But today it is virtually impossible for one person, or even two or three, to create a user-centered Web design given the complexity of the Web environment and users’ needs. This article explores the seven areas of expertise now necessary to create successful library Web sites: project management, information architecture, usability, access for people with disabilities, graphic design, content creation, and programming. The authors draw upon their collective experience in designing nine different library and university Web sites and in testing usability of four other library Web products. [Article copies available for a fee from The Haworth Document Delivery Service: 1-800-342-9678. E-mail address: <getinfo@ haworthpressinc.com> Website: <http://www.HaworthPress.com> Ó 2001 by The Haworth Press, Inc. All rights reserved.] KEYWORDS. Web site design, library Web sites, information architecture INTRODUCTION Do you remember 1995? Batman Forever was the top movie, O.J. Simpson was found not guilty, Republicans touted their “Contract with Jerilyn R. Veldof ([email protected]) is User Education Coordinator, University Libraries, and Shane Nackerud ([email protected]) is Web Services Coordinator, University Libraries, both at University of Minnesota-Twin Cities, 180 Wilson Library, 309 19th Avenue South, Minneapolis, MN 55455. Internet Reference Services Quarterly, Vol. 6(1) 2001 Ó 2001 by The Haworth Press, Inc. All rights reserved. 13 14 INTERNET REFERENCE SERVICES QUARTERLY America,” and the Internet, specifically the WWW, began to explode in popularity. It was also probably around this time that someone in your library decided that the library needed its own Web site. So a staff member that knew a little about HTML cobbled something together. It could have been you. The site probably wasn’t too flashy, but you were proud of it and you enjoyed the break from your regular library job. The library director was thrilled with the site since it showed the library was on the “cutting edge.” Those were simple times, weren’t they? How times have changed. Librarians are today doing work that we never would have dreamed of in the early 1990s. We create digital gateways to licensed resources as well as an array of our own online creations ranging from library published scholarly journals and digital libraries showcasing unique collections to knowledge management systems and user customizable interfaces. These new arenas of work necessitate skills, abilities, and knowledge in information architecture, graphic design, computer programming, usability, disability access, content creation, and project management, among others. Areas of expertise such as these often cannot entirely reside within our staff, and most certainly cannot be expected from one person. Outsourcing to other campus departments or outside entities is sometimes the most strategic choice you might make. This article is written to help you understand the expertise needed in these seven areas. This understanding will help you assess whether you have in-house expertise already, whether it is of value to you to develop this expertise in your staff, or if it makes more sense to selectively outsource the expertise. The authors will be drawing upon their collective experience in designing over nine different library and university Web sites and online tools. These include the University of Arizona’s Web site, the University of Arizona and University of Minnesota libraries’ Web sites, and various projects such as an online information literacy tutorial, a frequently asked questions database, and a wizard-like tool to identify research tools in particular disciplines. These Web sites have similar, broad-based goals in common. They: _ Include content that meets the needs of the users. _ Have interfaces that are user-centered, not librarian-centered. _ Are used successfully without intervention from library staff even by people with no idea how to conduct library research. _ Stand side by side with commercially driven Web sites with topnotch graphics and programming. _ Create minimal work in the way of updating and changing. Jerilyn R. Veldof and Shane Nackerud 15 To fulfill on these goals, the authors found that a Web designer or design team should master or outsource seven areas of expertise: _ _ _ _ _ _ _ Project management Information architecture Usability Access for people with disabilities Graphic design Content creation Programming This article will elaborate on each of these areas primarily using illustrations from the 1998-99 redesign project for LUMINA, the Digital Gateway to the University of Minnesota Libraries. LUMINA PROJECT BACKGROUND The LUMINA project began with recognition that the current library home page was causing problems for University of Minnesota students. Heavy use of library jargon, confusion caused by having over 40 individual links from the home page, an outdated looking interface, and the amount of time staff were spending at the reference desks and in the classroom explaining basic things, all pointed to the need for a redesign of the site. A team of library members from a variety of disciplines and professional levels (including information technology (IT) professionals, civil service staff, and librarians from science and engineering, arts and humanities, and distance learning) were pulled together and charged with the redesign. The group’s challenge was to create a new LUMINA that undergraduates could use successfully, including those who come to the University with no idea how to conduct library research. Instead of designing a Web site by librarians that forced the student to conform to it, the new Web site design would need to conform to the student. Wayne Weigard, of American Libraries fame, puts it clearly that our ultimate challenge is to “locate the library in the life of the user, not the user in the life of the library.”1 This became the primary aim of the Web Design Team (WDT). At the same time, the team knew that LUMINA would be critiqued along with slick commercial sites that utilized top-notch graphical design and programming. So the appearance of the site became another 16 INTERNET REFERENCE SERVICES QUARTERLY goal of the group. To respond to both these challenges, members of the Web Design Team would have to learn new skills and to outsource parts of the project that were beyond the scope of our abilities. The LUMINA redesign project will be used throughout this article to illustrate and expand upon the seven areas of expertise we are covering. For a look at the before and after Web sites of the LUMINA project, see Appendix A. PROJECT MANAGEMENT Web design projects often involve a number of different people to various degrees over a certain period of time. Managing the people and the process by which the project is to be accomplished will help the project move along more smoothly.2 Project management is the process of planning, organizing, staffing, and directing the production of a project.3 The tasks of a project manager are typically performed by one person, but can also be split among numerous individuals depending on relevant skills and the current stage of production. Although the project itself is the main focal point in this endeavor, managing the people involved with the project is quite possibly the most important job the project manager has. Ultimately, the success of a Web site depends on the capabilities, talents, and experience of the people working on it, and how well they work together.4 A good project manager brings a team together, learns and understands the skills and desires of the team members, and harmonizes disparate ideas. Along with the people involved with a Web site project, there is, of course, the project itself. Although no two Web site projects are ever identical, every Web site project normally follows six major stages. Many of these stages reflect one of the seven areas of expertise we discuss in this article. In the site definition and planning stage, the parameters of the site are determined as well as the primary audience. Budgetary concerns are hammered out, decisions are made about outsourcing skills not available from within the design team, and a schedule is planned. The second stage, information architecture, consists of mapping out the organization of the new site. Obviously, it is important to be flexible during this stage as information gathered in future developmental stages will have an impact on organizational and content decisions made. Information architecture will be discussed more below. During the third stage, site design, the overall look and feel of the site is created. The site design is determined by decisions made in regard to Jerilyn R. Veldof and Shane Nackerud 17 information architecture, goals of the site, usability testing, graphics and programming capabilities, and more. Content is also written during this stage, including rewriting existing content, and developing new content as a result of the decisions made above. The fourth stage, site construction, involves constructing the bulk of the Web site. This, of course, includes converting content to HTML, putting graphics into place, building secondary and tertiary pages and levels, creating any necessary database components, and testing it all for proper functionality. Site marketing, the fifth stage, involves publicizing the new Web site and informing the public of any new or exciting features. It is an opportunity for the library to showcase its abilities and highlight the services and tools it supplies to the user community. Finally, the sixth stage is tracking, evaluation, and maintenance. As anyone involved with Web site design will tell you, a Web site is never finished. Server logs should be maintained and analyzed for usage patterns that can suggest problem or surprise areas. Links should be checked regularly. User satisfaction and feedback should continue to be sought through site feedback forms, surveys, usability testing, comments at the reference desk, etc., and the site should be modified as appropriate.5 The site development stages for LUMINA at the University of Minnesota Libraries mirrored those above through the work of eight librarians and staff members who joined to become the Web Design Team (WDT) in March 1999. The members of the group consisted of librarians and staff representing science and engineering, humanities and social sciences, distance education, information technology, access services, and general reference. Due to this variety of backgrounds and the resulting differences in the clientele served, the group struggled early coming to a consensus on the goals of the redesign effort. Some group members had serious reservations with the proposed focus on undergraduate students since a large audience for the site is faculty and graduate students. Eventually, a compromise was reached and the group decided the primary goal would be to create a Web site undergraduates could easily use, but not at the expense of alienating our “expert” users, namely graduate students and faculty. Managing such a diverse team with various beliefs and interests and facilitating this group to reach consensus was one of the more challenging roles of the project manager. A timeline was also produced early on which gave the WDT a self imposed window of seven months for the completion of the redesign effort. Unfortunately, the project took a little under a year to complete. In 18 INTERNET REFERENCE SERVICES QUARTERLY retrospect, the suggested timeline was not necessarily unrealistic, but the team overestimated its own capabilities during the initial planning stages, specifically in regard to graphic design capabilities. The WDT spent a great deal of time designing its own graphics and the look of the site before realizing it was unsatisfied with its own efforts. If the decision to outsource the graphic design of the site had been made earlier, preferably from the start, the project could have been completed on schedule. (For more information concerning this topic please see the section on Graphic Design, later in this paper.) Overall, however, thanks to initial planning efforts and an understanding of project management principles and stages, the WDT successfully created a new library Web site for the students, faculty, and staff of the University of Minnesota. While in hindsight various project stages and problematic issues could have been handled better or avoided, any library involved in a Web site design process should be prepared for and expect the inevitable crisis. At the University of Minnesota Libraries, managing the WDT staff proved to be the biggest challenge due to the differences in opinion on what an academic library Web site should be. In the end, though, staff members involved with the project were able to put their differences aside and pool their talents together in order to create a new and improved LUMINA. More about their efforts follows in the sections below. INFORMATION ARCHITECTURE The organization or “architecture” of the Web site is the one area where librarians have the home court advantage. Librarians are skilled at creating organizational schemes and labeling systems, at categorizing, indexing, navigation, and searching–the crux of information architecture. Recognizing the value of this new area of expertise, library schools such as at the University of Michigan and University of Wisconsin-Madison are beginning to take on the responsibility of educating future information architects.6 Information architects determine the objectives of the site. They grapple with questions such as whether the site will be primarily designed to inform people about the library or to be a gateway to online resources; to primarily serve the novice undergraduate user or to cater more strongly to graduates and faculty–the “expert” users. Information architects also determine the scope of the site. They answer questions such as will the site include access to, and assistance in, Jerilyn R. Veldof and Shane Nackerud 19 using search engines like Google or Alta Vista; if it will include non-Web-based resources and services and if so, will they be presented at an equal or lesser level. The next area the architects determine is the organization of the site. Will the site have an instructional focus and lead users through the research process, or will you display all information equally? Will the site be organized by material format or by subject areas? The site architecture also impacts on the flexibility of the site. Will it, for example, allow for multiple entry points to the same resource, or will it tightly control access to a resource? Will it include only Webbased resources, or will it also present non-Web-based resources and will that access be organized differently? Because the work of the information architect is so rooted in the training and experience of librarians, librarians at both the University of Arizona Library and the University of Minnesota Libraries took on this role. But the authors must add a cautionary note. Decisions about the information architecture sound deceptively like ones that librarians might make in their offices and meeting rooms, devoid of user input. This indeed, could be the first fatal error of the design team. There are, thankfully, alternatives. At the University of Arizona, focus groups with students and faculty helped the redesign team identify what “customers” really wanted to use the Web site for and how they used other Web sites to do their research. This helped the team prioritize preferences and needs in the site architecture. At Minnesota, focus groups and interviews were valuable in uncovering the vastly different mental models that students and librarians had about the research process. This knowledge helped the librarians avoid constructing additional barriers in the design of the online tutorial.7 During the beginning of development of the University of Minnesota Libraries’ Web site, initial usability testing on nine other university library Web sites pointed out architectural snafus to avoid and the architectural models to emulate (usability testing will be discussed next in this paper). Early paper drafts of the site’s initial architecture were also tested with students before costly, intractable decisions were made regarding the site architecture. These kinds of lessons were critical in developing a site that “located the library in the life of the user,” and not vice versa. After gathering this kind of feedback from users and grappling with organizational issues, information architects finalize a site map, or site schema of the organization and structure of the Web site. This schema serves as the plan for the rest of the work of the team. It includes de- 20 INTERNET REFERENCE SERVICES QUARTERLY tailed specifications for the site, a description of the site content (see “content creation” below), programming needs, and some sketches or rough drafts of initial pages.8 All of these decisions relied heavily on usability, the next area of expertise we will discuss. USABILITY In institutions with thousands of students, a Web site may be the only interaction the student will have with the library. Without a reference or instructional intervention, the student must rely solely on the Web site to lead them to the research tools they need. In countless tests of library Web pages, the authors have seen student after student give up, go down the wrong paths, pass by rich resources, and groan in exasperation because our home-grown interfaces are roadblocks in the way of access to our research tools. If we in libraries are actually building roadblocks ourselves, what kind of a future do we have in store for us? We must take intentional action to remove our own barriers and build easy-to-use interfaces to the research tools for which we pay such a dear price. The most critical piece in the design of a Web site, therefore, is ensuring the usability of that site by your target users. “Usability is the degree to which a user can successfully learn and use a product to achieve a goal.”9 Testing for usability is the cornerstone of building the kinds of interfaces that help students to be successful researchers. As with all the other arenas of expertise discussed in this article, usability has its own cadre of professionals. Usability “experts” typically have advanced degrees in human factors and psychology. Companies that focus solely on running usability tests for their clients are fairly common. CJ Olson Market Research Inc., for example, has a professional usability lab from which it runs tests for clients paying over $250 an hour.10 Behind the one-way mirror is a tiered seating area with video recording equipment capturing the computer screen and the test participant’s speech and body language. Monitors are arranged for observers to catch every word and movement up close from the usability room. Despite the professional nature of usability testing, this is one area that librarians can and should develop in-house competencies and experience. Usability is one of the best ways to learn about your users–their needs, their habits, and their requirements with the online library systems you create. This knowledge is invaluable in many other areas of running a library as well. And you do not need fancy video equipment and viewing rooms to conduct and analyze your usability sessions. Jerilyn R. Veldof and Shane Nackerud 21 There is, in fact, a proliferation of libraries who have recognized the value of doing their own usability testing. The first ACRL proceedings including a program on usability was in 1999 followed by three such programs at the 2001 ACRL Meeting.11-14 As of this writing, between both authors, we have delivered over 12 workshops and presentations to librarians hungry to learn how to do this themselves. Usability testing is being done on a regular basis in such small libraries as Roger Williams University to Big 10 schools such as the University of Wisconsin. Staff at many of these libraries are now publishing on their usability process and the methodologies they used.15-20 This article will illustrate just one redesign project using LUMINA, the home page to the University of Minnesota Libraries <http://www.lib.umn.edu>. The team used a number of user centered design techniques including heuristic evaluations, cognitive walk-throughs, card-sorting, and pen and pencil evaluations.21,22 But the most powerful of the techniques used was the usability test. Usability testing was used as a stealth device–a quick way to swoop in, get quick user input, and provide the team with specific design changes or enhancements. The most common way the team conducted testing was by scheduling concurrent tests with two or three usability “testing teams.” The testing teams consisted of a test monitor and recorder. Students were recruited just prior to each test from a snack area outside the library and enticed with a monetary contribution reflective of length of the test–15 minutes, 30 minutes, 45 minutes, or 60 minute test slots were exchanged for anywhere from $5 to $20. Each testing team worked with 1 student at a time. Students filled out basic demographic information including their status, their self-reported facility using the Web, and whether or not English was their first language. Then they were asked to complete tasks simulating actual undergraduate research needs. Questions ranged from: _ “What time does the Math Library open on Sundays?” to _ “You are in management class and have to write a paper about management trends in business. Find a journal or magazine article on this topic.” (See Appendix B for full list.) Test monitors encourage students to think aloud during the testing process by asking neutral questions such as, “Why did you click on that link,” or “What are you thinking as you look at this page?” Leading questions such as “Did you find that link hard to understand?” are to be absolutely avoided. Monitors must refrain from rescuing students, teaching students, or correcting them.23 22 INTERNET REFERENCE SERVICES QUARTERLY Directly after a test or group of tests, testing teams and observers discussed what they learned. Did all the users fail to find an article index on business? Did any of them see the link to “hours” from the home page? Then the teams would compare notes to see if there were any patterns or obvious barriers that the students commonly encountered. The group would then mull over ideas to fix the identified problems, such as, “Perhaps we might put the link to “hours” in a different color and move it over to another part of the page that students see more easily”; or “Perhaps we might experiment with an instructional approach to the indexes page that guides students through the process of selecting an index.” Proposed solutions would be implemented and re-tested to see if the problem was fixed. If not, the team would try another approach, constantly working toward a satisfactory success rate. Each testing round would only necessitate four to eight usability tests per category of user (undergraduate students for example). Jakob Nielson, one of usability’s gurus, actually suggests only five tests per round: “The main reason is that it is better to distribute your budget for user testing across many small tests instead of blowing everything on a single, elaborate study.” Beyond this number your tests are subject to the law of diminishing returns: As you add more and more users, you learn less and less because you will keep seeing the same things again and again. There is no real need to keep observing the same thing multiple times, and you will be very motivated to go back to the drawing board and redesign the site to eliminate the usability problems.24 Testing at both Arizona and Minnesota was limited to undergraduate and graduate students with the ultimate aim to build an easy to use Web site geared to first-time library researchers without antagonizing or causing problems for the expert user. The team was also obligated to ensure that first-time library users with disabilities would also be able to use the site easily and quickly. DISABILITY ACCESS Using the WWW can be extremely difficult for persons with disabilities. In addition to the obvious difficulties encountered by visually impaired users, there are many other disabilities that should be taken into account when designing a Web site. These include hearing disabilities, Jerilyn R. Veldof and Shane Nackerud 23 physical disabilities, and cognitive disabilities.25 For example, a Web site may include important audio messages but not transcribe them for people with hearing disabilities. A site may also use one-word links in very small fonts or links wrapped around small graphics. Links of this kind do not provide an adequate sized target for people with physical impairments who have difficulty using a mouse.26 A Web site may also have secondary and tertiary pages all with their own presentation, navigation, and organization, forcing people with cognitive disabilities to relearn the structure of every page. To help a Web design team address these issues, there are many published guidelines on how to properly design a site for accessibility. Two of the more famous guidelines include those produced by the Web Accessibility Initiative of the W3C and Section 508 of the Federal Rehabilitation Act. Both of these efforts have produced detailed and lengthy guidelines that delve into every aspect of Web accessibility, and they continue to be modified and enhanced. The WAI in particular has created three levels of priority for accessible Web page design. The guidelines in priority level one (see Appendix C) are relatively easy to implement, while levels 2 and 3 suggest other guidelines that may be too expensive or difficult for Web sites to implement, or even be exclusionary depending on the browser used. For example, level two requires that a Web page author use style sheets rather than tables to control layout and presentation. Style sheet languages such as Cascading Style Sheets (CSS) are considered more accessible and allow Web page authors to separate content from layout. In fact, the W3C is recommending that layout specific features of HTML be phased out in favor of style sheets in future versions of HTML. However, as many Web page authors know, style sheet languages such as CSS are not fully supported by level four browsers such as Netscape 4 and Internet Explorer 4. To transform pages currently using tables for layout into CSS compliant pages could certainly be expensive, but more importantly this strategy could also make pages unreadable or confusing for level four browsers, which, unfortunately, are still being used by many library patrons. In fact, Jakob Nielsen predicts that level four browsers will have to be supported until late 2003.27,28 At what level, then, is a Web site considered accessible? This, of course, is up to the library or governing body of the library to decide. Many organizations have Web accessibility guidelines which go far beyond the W3C’s, making specific reference to do’s and don’ts concerning tables, frames, lists, links, multimedia, presentation, and forms. It is important in any Web site design effort to be knowledgeable about the 24 INTERNET REFERENCE SERVICES QUARTERLY policies at your own organization or institution, or if no policies exist, to come up with your own using basic accessibility guidelines found on the Web and in discussion with disabled members of your library’s community. Accessible design principles not only aid disabled users in using a site, but these same principles help all visitors make effective use of a library Web site. In redesigning LUMINA, the University of Minnesota Libraries’ design team found that the University of Minnesota had no written policy concerning accessible Web site design. However, the Disability Support Services (DSS) department of the University had very detailed guidelines on accessibility that provided the necessary direction for LUMINA.29 Members of the design team also met and corresponded with DSS throughout their efforts to ensure the accessibility of the design. Screen readers were employed to make sure the site could be navigated effectively, and a text only version of the site was created allowing people to quickly navigate and/or use Lynx more effectively. Is the site completely accessible? Unfortunately, it’s not. There are still problems, especially with the use of tables for layout and presentation. However, with the help of DSS, the University Libraries have made LUMINA as accessible as possible and continue to strive toward complete accessibility. It is difficult, sometimes, to give users the visually appealing, information rich site they expect while at the same time keeping things simple and accessible for disabled users. It is important, however, that we attempt to achieve both. GRAPHIC DESIGN The Web today is full of bells and whistles. Sites that have multi-media content and flashy graphics are not the exception but the norm. And, while it is possible to spend too much time on graphics and the look of a site, a good graphic design can aid in both the usability of the site and the subsequent trust a user has in the information of a site. Users tend to trust and want to use sites they find visually appealing more than purely text based or sites “unprofessional” in appearance: “A site that looks sloppily built, with poor visual design and low editorial standards, will not inspire confidence.”30 Most librarians will probably agree that a quick look at the library Web site landscape leaves much to be desired in the area of aesthetic quality. Jerilyn R. Veldof and Shane Nackerud 25 Librarians and library staff are not necessarily educated in graphic design. However, in today’s landscape of libraries as publishers of information, graphic design has become increasingly important for handouts, pamphlets, PowerPoint presentations, and of course, Web pages. The library Web site is typically a library’s front door to the world and the way most people see that library for the first time. This first impression is important and can certainly set the initial tone of a user’s perceived ability to navigate the site effectively. Some may argue that the usability and content of the site should be the most important aspects of any Web site redesign effort. This point is hard to argue with. A pretty graphic will not give you the information you need, at least not directly. However, graphic design should not be forsaken in favor of content or usability. Library Web sites are now competing with all kinds of information delivery Web sites, such as Ask Jeeves, Alta Vista, and Google, that are not only interactive but inviting and “catchy.” Thanks to these sites and others, our users not only prefer this type of information display, but expect it. With all of this competition, and considering all the money that libraries spend on databases, indexes, and site and server maintenance, it is important to create a positive impact with Web sites that invite, instill confidence, and effectively provide the information our users are looking for. The University of Minnesota Libraries came to these conclusions during the redesign of its main Web site, LUMINA. The library staff charged with redesigning the Web site, came up with various designs on their own using Photoshop, Illustrator, and other like programs. While the designs were functional and could certainly be made usable, they were simple, unimaginative, and lacked the creativity necessary to make an impact. Realizing the importance of an appealing graphic design in today’s Web world, the design team looked into three options to improve their faltering design efforts. One option was to find another library staff member that had advanced graphic design capabilities to design the site. A second option was to contact a computer graphics department on campus and ask whether a student, class, or professor was interested in some work on the side. A third option was to contract with a non-university graphic design firm. After discussing and researching each option, and even accepting some design work from a student on campus, the design team decided to focus on hiring and working with an outside design firm. There are both advantages and disadvantages to working with an outside design firm for graphic design: 26 INTERNET REFERENCE SERVICES QUARTERLY Advantages: 1. A good graphic design firm will provide professional looking graphics for the home page, and secondary and tertiary pages, effectively creating a look and feel for the entire site. 2. A good graphic design firm can provide a fresh perspective on tools and services offered on the site. 3. A good graphic design firm will provide a timeline for completion of a project. 4. A good graphic design firm is knowledgeable in the tools and methods of designing graphics for the WWW and can save time with speedy service. 5. A good graphic design firm employs not just graphic designers but artists that can come up with designs that are fun, exciting, and functional. Disadvantages: 1. A design firm can be expensive to employ (anywhere from $1,000 to $150,000 depending on who you use). 2. All designs are paid for, even rejected designs. 3. A good design firm has many clients all vying for time. This can mean that your project might be put on the back burner when you least expect it. 4. There is the possibility that all designs will be unsatisfactory, forcing a library to either settle or start all over again. 5. A design firm does not typically employ librarians and may not fully understand the mission of the library. In considering the advantages and disadvantages of using a graphic design firm, the Web Design Team (WDT) at Minnesota felt it was important that any graphic design firm hired would also be willing to be guided by the feedback received from the library’s users during usability testing.31 This would certainly affect the cost of the project and the timeline, as it would force the WDT to meet on a more regular basis. The WDT contacted several graphic design firms before finally deciding on Ashanti Eaton (AE) of Minneapolis. After inspecting their designs and speaking with the president of the company, the WDT felt AE could deliver the exciting and professional site desired at an affordable price. AE began working on the site September 1999. Over the next 3 1/2 Jerilyn R. Veldof and Shane Nackerud 27 months, AE designed four sets of graphics, two of which never got past internal testing within the team. A number of unforeseen problems surfaced during this effort. One was a problem of semantics. Initially we told AE that we wouldn’t need any programming assistance since the library had internal programmers to code any necessary Perl, PHP, Java, and the like. Unfortunately, AE also considered HTML to be programming and refused to convert into HTML any of the templates or pages they had designed. Realizing that it would be easier for them to convert their own designs into HTML, the WDT decided to pay extra for this service. Secondly, the WDT assumed that AE would test their designs on numerous browsers and OS platforms. While they did test on newer versions of Netscape and Internet Explorer, the WDT later found out that they had never tested their designs or HTML coding on the Macintosh platform, a platform commonly used in educational settings. Numerous bugs were fixed by members of the WDT after our own internal testing. These two problems would have never surfaced if HTML coding and browser/platform testing had been in the contract from the beginning. Overall, however, the experience was a positive one. AE’s creativity and knowledge resulted in a unique, professional, and aesthetically pleasing site <http://www.lib.umn.edu>. The response to the site has been very positive from U of M faculty, staff, and students, and also from other libraries nationwide. CONTENT CREATION One of the best parts of the redesign process is usually the relief that the Web content has already been created. There should already be a page for the hours of all the service sites and libraries or a Web site explaining borrowing policy, for example. It is a rare redesign project, however, that does not in some way have to address content creation. Needs are bound to arise in early user testing and feedback that will necessitate new content. At the University of Minnesota, for example, users were exasperated when there was no way to browse just the electronic journals. The team concluded that a new Web page would need to be developed. There had been no Web page in the previous design that helped students select a search engine or Web directory, yet there was enough indication that the Libraries should offer a portal to the non-proprietary Web that such a page would need to be developed. 28 INTERNET REFERENCE SERVICES QUARTERLY Content that you currently have available in your Web site, may also need to be greatly edited. During usability testing, students will often comment on what information they really need on the page, and what’s in the way or merely extraneous. Therefore, it’s very important that if you farm out Web page creation to various departments in the library, there should be some level of participation with usability testing. The content creators should also have in hand a completed “blueprint” of their part of the Web site from the information architecture phase of the project. Armed with this blueprint and experience with the user interacting with the previous site or the site prototypes, the content creators should be ready to begin their job. The primary job of a content creator is to put pen to paper, so to speak. In the business setting, content creators are often technical writers whose primary task is to translate complex information simply and accurately. Technical writers often have bachelor’s or master’s degrees in technical writing, where they were educated in writing consistent and clear documentation. The University of Minnesota Libraries hired graduate students in technical writing, through the University’s Department of Rhetoric, to apply their abilities to the online information literacy tutorial. This process was an eye opening one for those of us untrained in technical writing. We learned that our styles were inconsistent across the tutorial. Some pages were quite verbose with long paragraphs, no breaks, and no easy way to browse. Other pages were brief and punchy, with bulleted lists and fragmented sentences. Some of our language was chatty and youthful and others, academic and distant. Some pages went on for several screens, others were short and lacking much information. Some pages seemed extraneous, where others packed far too much critical information together on one page. The technical writers were able to see these inconsistencies in our style and tone. They helped to chunk information on a page and add headers and sub-headers to improve browsability. They also helped to even out the pages, making each page a more manageable size for Web reading and facilitating the flow between the pages. Another important component of content creation, aside from the writing of that content, is the issue of redundancy–one of the most tedious aspects of maintaining a Web site. If a description of an index appears on several library Web pages, for example, and the year range changes, each one of these pages must be identified and changed. This can result in an enormous amount of tedious work and a lot of room for error. Using a database driven model to deliver this content is the logi- Jerilyn R. Veldof and Shane Nackerud 29 cal solution to this problem. The next section on programming will explore this solution further. PROGRAMMING Not only has the WWW moved in a more graphical direction, but interactivity is now a big part of its appeal. Gone are the days where Gopher and flat text files ruled Internet space. Today sites are dynamic, changing, and displaying based on client-supplied data, and obviously giving users a more customized view of the information they seek. Again, after visiting popular sites like Amazon.com and Barnes and Noble, is it any wonder that our users are expecting this type of interaction and customizability in their libraries? Libraries, too, have been moving steadily away from producing flat HTML files and opting instead for dynamic, database driven sites. One of the more popular tools in development in libraries today is the MyLibrary or user-customized library portals concept currently being used by libraries such as North Carolina State, University of Washington, and Virginia Commonwealth University. Another trend picking up momentum in libraries today is the effort to move to a more database driven format for library Web sites. A database driven Web site, if designed properly, can make site maintenance easier, provide more consistent and up-to-date information, and allow for multiple ways of displaying the information on your site.32 Today a typical Web site consists of three layers. The first and most public layer is the interface. This is the layer that includes the HTML and Javascript code seen by the users. This layer has already been discussed above. The third level is a database system such as Oracle, MySQL, or MSSQL, which stores information pertinent to the Web site and the users of that site. In a library setting, this could be a list of the indexes subscribed to by the library, the staff directory, an e-journals list, etc. In the middle is the integration layer. This layer makes the contents of the database visible to the user and can take many forms such as Perl, Java (servlets, JSP), Cold Fusion, PHP, ASP, and the like. As opposed to the early days of the Web when HTML was the key skill to have, today’s Web site development requires people knowledgeable in each of these layers.33 Unfortunately, moving beyond HTML can be difficult. Learning HTML and using it is simple when compared to the challenge of learning programming languages like Java, ASP, Perl, or PHP, not to men- 30 INTERNET REFERENCE SERVICES QUARTERLY tion database design, modeling, and SQL syntax. However, as stated above, our users are demanding more out of library Web sites based on other sites they have visited on the WWW. The library community needs to come to grips with this fact and either learn these new skills ourselves, outsource these skills, or begin to train new librarians to be able to effectively use these skills in library school and beyond. What are the essential skills then? The choice of programming language and database are dependent on a number of factors including server environment, nature and scope of the projects involved, current knowledge and skill sets, and, of course, money. Generalizations, however, can be made. To make a bare bones Web site in today’s Web development world, essential skills include HTML, CSS, Javascript (as well as knowledge in some sort of graphics package such as Adobe Photoshop), and knowledge of CGI and Perl. Almost all Web servers are automatically equipped with the capability to handle Perl and there are many, many pre-built scripts a library can download from the WWW and modify. This includes scripts for e-mail, chat, calendaring, cookies, simple databases, and more.34 Using pre-built Perl scripts is certainly a good way to begin and can certainly add some basic interactivity to a library Web site, but pre-built scripts will only take a library Web site so far. Depending on your server environment, the next level of knowledge includes being able to utilize programming languages like Perl, PHP, ASP, Java, ColdFusion and the like, writing scripts and programs from scratch as needed, or reusing pre-written code for specific and new purposes. For example, the University of Minnesota Libraries use PHP and cookies to create the text-only pages preferred by many of our visually impaired users, and by users with slow Internet connections. With PHP and cookies, graphics and backgrounds are stripped out of a page when a user selects the text-only version. PHP is also used to authenticate users for licensed database access, drive ILL and document delivery services, and provide other dynamic functions site-wide. Sooner or later, however, even this level of skill will prove inadequate as more and more projects demand database technology. Examples have already been mentioned above such as the MyLibrary concept, or databases of indexes and electronic journal holdings. Skills required for projects such as these include advanced knowledge of PHP, ASP, ColdFusion, or Java. If Java is the programming language of choice in your library, knowledge of either servlets or Java server pages (JSP) is a must. On top of this advanced programming knowledge, staff should have knowledge Jerilyn R. Veldof and Shane Nackerud 31 of database design and modeling, as well as knowledge of the database system in use whether it be Oracle, MSSQL, PostgreSQL, or MySQL. Early in the development of the WWW and its use in libraries, the University of Minnesota Libraries recognized the potential power of Web enabled databases and built Research QuickStart, a wizard like tool allowing a student to find research tools in a specific subject area.35 The backend database contains thousands of resources from indexes and databases to bibliographies, dictionaries, encyclopedias, catalogs, and other traditional library resources. Until the redesign of LUMINA, however, this data was only accessible through Research QuickStart. It was quickly decided during the redesign of LUMINA that the data in Research QuickStart should be reused across the site. Using PHP, the Research QuickStart database now drives much of the content of LUMINA including the indexes pages, pages listing libraries and collections, reference resource pages, and more. Divisional libraries also make use of the database in their own resource lists making Research QuickStart the overarching database across the library Web. The beauty of this, of course, is that resource information is maintained in one place, but accessed through numerous pages and sites. This obviously makes site maintenance more efficient and ensures that users receive the most up-to-date information no matter where they access the resource. Based on the success of this model, the University of Minnesota Libraries have developed other databases with PHP and MySQL to help drive the content of LUMINA. This includes databases for e-journals subscribed to by the libraries, hours of the various collections and libraries, the staff directory, as well as other minor projects and sites. Each page of LUMINA is also indexed in a database which allows for the creation of the site map and index, and may, in the future, allow for the attachment of metadata to each page where this is deemed necessary and appropriate. Due to the success of this endeavor and the swift proliferation of databases running the site, however, it has become necessary to reexamine this strategy and look into the possibility of a true overarching database or data warehouse to drive the site. This is the next step in the design of LUMINA. CONCLUSION It seems clear to the authors that no one person would be able to adequately develop the expertise and give the time to handle all seven of the areas described here. In fact, it’s even hard to believe that an entire team of library staff would have all seven areas of expertise adequately cov- 32 INTERNET REFERENCE SERVICES QUARTERLY ered between them. We are well beyond the time when all of our staff only needed a traditional MLS to run a library. A short-term solution may be to outsource some of these areas. But if libraries are going to continue to become digital gateways and publishers of information–and we hope they are–a smarter longer term strategy would be to cultivate this expertise from within our profession. Library schools, therefore, need to fully embrace this new digital paradigm–not just those cutting edge schools–but all schools lest they become archaic purveyors of obsolete skills and technology. Libraries also have to be serious about staff development and training in these areas and train forwards; in other words, to look to the new skills, abilities, and knowledge that librarians will need right around the corner from now, and stop most of their time looking backwards. “The future ain’t what it used to be,” goes the saying.36 In order to stay ahead and on the cutting edge, libraries and library schools are going to have to continue to move out of our comfort zones and tackle the future head-on. Welcome to the new century! Received: June 1, 2001 Revised: June 29, 2001 Accepted: July 3, 2001 NOTES 1. Wayne Wiegand, “Mom and Me: A Difference in Information Values,” American Libraries 29 (7) (August 1998): 56-8. 2. Susan M. Thompson, “Managing the Web Redesign Process,” in Internet Librarian ’99: Proceedings 1999 (Medford, N.J.: Information Today, 1999), 177. 3. Dictionary.com: Entry for “project management.” Available: <http://www. dictionary.com/cgi-bin/dict.pl?term=project%20management>. 4. Ashley Friedlein, Web Project Management (San Francisco: Morgan Kaufmann Publishers, 2001), 180. 5. Patrick J. Lynch and Sarah Horton, Web Style Guide: Basic Design Principles for Creating Web Sites (New Haven: Yale University Press, 1999), 4-9. 6. For example, the University of Michigan School of Information offers a course called “Information Architecture” and the University of Wisconsin-Madison School of Library & Information Studies offered a special topics course called “Information Architecture” in the Spring 2001 semester. 7. Jerilyn R. Veldof and Karen Beavers, “Going Mental: Tackling Mental Models for the Online Library Tutorial,” Research Strategies (under review). 8. Lynch and Horton, Web Style Guide, 7. Jerilyn R. Veldof and Shane Nackerud 33 9. Jerilyn R. Veldof, Michael Prasse, and Vicki Mills, “Chauffeured by the User: Usability in the Electronic Library,” Journal of Library Administration 26 (3/4, 1999): 115-40. 10. CJ Olson Market Research Inc. is accessible at <http://www.cjolson.com>. 11. Ruth Dickstein, Abigail Loomis, and Jerilyn Veldof. “The User is the Expert: Experiences at Three Universities Using Usability Studies to Inform Gateway and Tutorial Design.” Presented at the ACRL Meeting, 1999. 12. Mary Pagliero Popp, “Testing Library Web Sites: ARL Libraries Weigh In,” Presented at the ACRL Meeting, 2001. 13. W. Bede Mitchell, Laura Davidson, Rebecca Ziegler, and Ann Viles, “Testing the Design of a Library Information Gateway,” presented at the ACRL Meeting, 2001. 14. Suzanne L. Byerley and Mary Beth Chambers, “Usability Testing and Students with Disabilities: Achieving Universal Access on a Library Web Site,” presented at the ACRL Meeting, 2001. 15. Ruth Dickstein and Vicki Mills, “Usability Testing at the University of Arizona Library: How to Let the Users in on the Design,” Information Technology and Libraries 19, no. 3 (September 2000): 144-51. 16. Sandra D. Payette and Oya Y. Rieger, “Supporting Scholarly Inquiry: Incorporating Users in the Design of the Digital Library,” Journal of Academic Librarianship 24, no. 2 (March 1998): 121-9. 17. Nicole Campbell, Sharon Walbridge, Janet Chisman, and Karen R. Diller, “Discovering the User: A Practical Glance at Usability Testing,” Electronic Library 17 (1999): 307-11. 18. Janet Chisman, Karen Diller, and Sharon Walbridge, “Usability Testing: A Case Study,” College and Research Libraries 60 (1999): 552-69. 19. Veldof, Prasse, and Mills, “Chauffeured by the User,” 115-40. 20. Campbell, Nicole, ed., Usability Assessment of Library-Related Web Sites: Methods and Case Studies. LITA Guide #7. (Chicago: American Library Association, 2001). 21. Veldof, Prasse, and Mills, “Chauffeured by the User,” 115-40. 22. Dickstein and Mills, “Usability Testing,” 144-51. 23. Jeffrey Rubin, Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests (New York: John Wiley & Sons, Inc., 1994). 24. Jakob Nielson, Alertbox, March 19, 2000: Why You Only Need to Test With 5 Users. Available: <http://www.useit.com/alertbox/20000319.html>. 25. Judy Brewer, Web Accessibility is a Cross-Disability Issue. Available: <http:// www.w3.org/Talks/WAI-Intro/slide5-0.html>. 26. Computer Accommodations Program of the University of Minnesota, Guidelines for Accessible Web Page Design: Text Links. Available: <http://cap.umn.edu/ WebSiteAccessibility.html#TextLinks>. 27. Although it is still recommended that designers not use tables for layout purposes, newer screen readers such as Hentner-Joyce’s JAWS 3.7 and Window-Eyes 4.1 from GW Micro both claim better support for HTML tables. The W3C has also developed a table “linearizer” called Tablin which can render tables “according to preferences set by the presentation layer.” Available: <http://www.w3.org/WAI/Resources/ Tablin/>. 34 INTERNET REFERENCE SERVICES QUARTERLY 28. Jakob Nielson, Alertbox, March 19, 2000: Why You Only Need to Test With 5 Users. Available: <http://www.useit.com/alertbox/20000319.html>. 29. Computer Accommodations Program of the University of Minnesota, Guidelines for Accessible Web Page Design. Available: <http://cap.umn.edu/WebSiteAccessibility. html>. 30. Lynch and Horton, Web Style Guide, 17. 31. Bruce Tognazzini, If They Don’t Test, Don’t Hire Them. Available: <http:// www.asktog.com/columns/037TestOrElse.html>. 32. Kristin Antelman, Getting Out of the HTML Business: The Database-Driven Web Site Solution. Available: <http://www.lita.org/ital/1804_antelman.html>. 33. Sacha Cohen, Web Skills to Learn Now. Available: <http://dotcom.monster. com/articles/topskillsneeded/>. 34. Shane Nackerud, “The Potential of CGI: Using Pre-Built CGI Scripts to Make Interactive Web Pages,” Information Technology and Libraries 17(4) (1998): 222-9. 35. University of Minnesota Libraries, Research QuickStart. Available: <http:// research.lib.umn.edu/>. 36. Although this quote is generally attributed to Yogi Berra as cited in Ralph Keyes, Nice Guys Finish Seventh: False Phrases, Spurious Sayings, and Familiar Misquotations (New York: Harper Collins, 1992), the original quote, “Not even the future is what it used to be” originates with Paul Valery as quoted in Joseph Epstein, Ambition: The Secret Passion (New York: E.P. Dutton, 1980). SELECTED FURTHER READING Project Management Friedlein, Ashley. Web Project Management. San Francisco: Morgan Kaufmann Publishers, 2001. Lynch, Patrick J. and Sarah Horton. Web Style Guide: Basic Design Principles for Creating Web Sites. New Haven: Yale University Press, 1999. Thompson, Susan M, “Managing the Web Redesign Process,” in Internet Librarian ’99: Proceedings 1999. Medford, N.J.: Information Today, 1999. Information Architecture Rosenfeld, Louise and Peter Morville. Information Architecture for the World Wide Web. Sebastopol, CA: O’Reilly & Associates, 1998. CNET builder.com. 10 Questions about Information Architecture. Available: <http:// www.builder.com/Authoring/AllAboutIA/ss01.html>. Usability Campbell, Nicole, ed., Usability Assessment of Library-Related Web Sites: Methods and Case Studies. LITA Guide #7. (Chicago: American Library Association, 2001). LITA Human/Machine Public Interest Group. Usability Testing Resources. Available: <http://www.vancouver.wsu.edu/fac/campbell/hmiig/usabres2.htm>. Jerilyn R. Veldof and Shane Nackerud 35 Nielsen, Jakob. Useit.com: Jakob Nielsen’s Website. Available: <http://www.useit. com/>. Krug, Steve. Don’t Make Me Think! A Common Sense Approach to Web Usability. Indianapolis: New Riders Publishing, 2000. Rubin, Jeffrey. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. New York: John Wiley & Sons, Inc., 1994. Access for People with Disabilities Clark, Joe. Web AccessiBlog. Available: <http://www.joeclark.org/accessiblog/>. Computer Accommodations Program, University of Minnesota. Guidelines for Accessible Web Page Design. Available: <http://cap.umn.edu/WebSiteAccessibility.html>. Paciello, Michael G. Web Accessibility for People With Disabilities. Lawrence, Kan.: CMP Books, 2000. World Wide Web Consortium. Web Accessibility Initiative. Available: <http://www. w3.org/WAI/>. User Interface and Graphic Design Cooper, Alan. About Face: The Essentials of User Interface Design. CA: IDG Books, 1995. Garlock, Kristen L., and Sherry Piontek. Designing Web Interfaces to Library Services and Resources. Chicago: American Library Association, 1999. Lynch, Patrick J. and Sarah Horton. Web Style Guide: Basic Design Principles for Creating Web Sites. New Haven: Yale University Press, 1999. Nielsen, Jakob. Designing Web Usability: The Practice of Simplicity. Indianapolis: New Riders Publishing, 2000. Content Creation Lynch, Patrick J. and Sarah Horton. Web Style Guide: Basic Design Principles for Creating Web Sites. New Haven: Yale University Press, 1999. Strunk, William Jr. The Elements of Style. Boston: Allyn and Bacon, 2000. Zinsser, William. On Writing Well: The Classic Guide to Writing Nonfiction. New York: HarperPerennial, 1998. Programming Antelman, Kristen, “Getting Out of the HTML Business: The Database-Driven Web Site Solution,” Information Technology and Libraries 18 (4, 1999): 176-81. Castagnetto, Jesus et al. Professional PHP Programming. Birmingham, UK: Wrox Press Ltd., 1999. Greenspun, Philip. Philip and Alex’s Guide to Web Publishing. San Francisco: Morgan Kaufmann Publishers, 1999. Schwartz, Randal L. and Tom Christiansen. Learning Perl. Sebastopol, CA: O’Reilly & Associates, 1997. 36 INTERNET REFERENCE SERVICES QUARTERLY APPENDIX A LUMINA: Digital Library Gateway for the University of Minnesota Libraries-Twin Cities at http://www.lib.umn.edu Before . . . . After . . . . What is not shown in this screen capture are the “mouse-overs” that show when the mouse is placed over the links on the curved line. Jerilyn R. Veldof and Shane Nackerud 37 APPENDIX B Usability Test Questions 1. How would you find a book about affirmative action? 2. What time does the Math Library open on Sundays? 3. Find a journal or magazine article about the management trends in business. 4. Does the library subscribe to Sports Illustrated (the magazine)? 5. You need to get a hold of a book that we don’t have here in the Library. Somebody told you to use Interlibrary Loan. How would you put in an Interlibrary Loan request? 6. You've heard that the Science and Engineering Library has moved and you want to find their web site for more information on this. How would you do that? 7. Someone told you that Google would be a good place to search for something on the web. Where would you go to find Google using this web site? 8. How would you find out if the library owns a video about Shakespeare? 9. How would you find information from an encyclopedia that is online? 10. Let’s say you were trying to get into a library database but your username and password weren’t working. How would you get help? 11. Assume that you are taking a class in a subject completely new to you: mathematics, women’s studies, geography, or communications. When the professor assigns you a paper, how would you find out about information resources in that subject area? 12. How would you find a book at the Minneapolis Public Library using this web site? 38 INTERNET REFERENCE SERVICES QUARTERLY APPENDIX C Disability Access What follows is the WAI’s priority level one list of accessibility checkpoints. According to the WAI, a Web site must satisfy these checkpoints to achieve a minimum level of accessibility. 1. Provide a text equivalent (e.g., “alt” or “longdesc”) for every non-textual element on a web site. This, of course, includes the ALT tag for all images. 2. Ensure that all information conveyed with color is also conveyed in the absence of color, and that color contrast is appropriate in images, text, and backgrounds. 3. Identify changes in languages. 4. Ensure that the information on a document utilizing style sheets can also be accessed with browsers unable to use style sheets. 5. Ensure that equivalents for dynamic content are updated as the dynamic content is updated. For example, if a script producing dynamic content changes, make sure the NOSCRIPT description or equivalent also changes to reflect the updated script. 6. Avoid causing the screen to flicker. 7. Use the simplest language available to convey the site’s content. 8. If server side image maps are used, provide redundant textual links for the areas on the image map. 9. For data tables, identify row and column headers and in tables with two or more logical levels of rows and columns identify through markup the relationship between data and header cells. 10. If frames are used, title each frame for better identification and navigation. 11. If applets or scripts are used, make sure the page works properly when these programmatic elements are switched off. 12. If multimedia is used, provide captions or transcripts of important content. And if all else fails, if an accessible page simply cannot be developed, provide an alternate page or site that is updated as often as the inaccessible version. (http://www.w3.org/TR/WCAG10/full-checklist.html)