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)