Rebuilding Your Library's Web Site

Citation

Vékony, A. and Waite Bunker, L. (2002), "Rebuilding Your Library's Web Site", Library Hi Tech News, Vol. 19 No. 7. https://doi.org/10.1108/lhtn.2002.23919gaf.001

Rebuilding Your Library's Web Site

Rebuilding Your Library's Web Site

Atilla Vékony and Lisa Waite Bunker

Introduction

Imagine walking into a library where one of the walls is painted black and flashing neon lights adorn the ceiling; another wall has the plaster falling off, the roof is half finished, but the carpet is the best one available in town. A poster on the wall advertises one of last year's author visits. Upon closer examination you find out that several different librarians and staff members had contributed personally over the years to the planning and building of this particular branch, all of them, of course, giving their best. It may not sound like your library, but what about your library's Web site?

Many libraries, museums, archives, and special collections have established some kind of Web presence from the mid-1990s on, and have been augmenting their sites over the years with newer content – often employing newer tastes and talents. Eventually there must come a point when all that diverse content and form is brought under the reins of manageable and aesthetically pleasing uniformity. After all, the library building was designed and built by one or more skilled architects; why should the library's Web site – the virtual library building – be any different?

If your library is like many libraries, it has had some kind of a Web site for the past five years, and always the person who knew most about Web design was in charge of adding new content and design elements. Or worse: different people with different skills and tastes have been contributing to the Web site simultaneously for the past few years, and the current result is a jungle of information and a site lacking uniformity of design, format and navigation. The text-based layout of the page featuring the Steinbeck collection (missing a "Home" button but with plenty of horizontal rules) does not quite match the high-tech page (with the slow-loading Flash intro) designed by the newest hire.

Let us assume that you have been given the charge to do something about your institution's Web site. The management has the sense that it is high time to put some uniform design and clear organization into the site that has evolved over the years to have a life of its own. Just like the architect who designed the building to have a consistent and pleasing look, the Webmaster must make sure that the same level of consistency and professionalism are also present in the Web site as a whole. If such issues are not attended to, virtual patrons and other online visitors will be left underserved and will continue to be distracted from the content of the site by its inconsistent presentation and form.

In this feature article, we will discuss the process and strategies in detail that will help you with rebuilding your library's Web site. Our purpose with this article is to help the one-to-three-person design team of smaller libraries know more about the process and the prospects of rebuilding their site and perhaps some of the pitfalls they may encounter along the way. Therefore, this article is not geared toward libraries with large, well-organized design teams and a professional scale to match. We have drawn on our experience in redesigning and reorganizing the Web site of our former library school, the School of Information Resources and Library Science at the University of Arizona (http://www.sir.arizona.edu), although the following discussion is not necessarily descriptive of that scenario. In order to describe in detail the workflow of a Web site redesign project, the following discussion assumes that redesigners are somewhat new to the library's Web site, or at least they are not the ones that created the current site that is to be rebuilt. In this case they will need to familiarize themselves first with the existing site, and will need to end the process by leaving the redesigned site for others to maintain. In many cases, however, the redesigners themselves are involved with the Web site both before and after the redesign project.

Preliminary preparations

You as the Webmaster should talk to your leadership about what they envision about the future site, what should be kept of the old site, and what not. You may find that they have been thinking about your library's Web presence, but that they do not have a vision of what it could be or what the possibilities are. Be prepared to take the lead in this and tell them about your vision. You may receive much more valuable feedback as they react to your proactive proposal than if you were to ask for general comments or ideas. If you do not have a proposal, however, your questions should be specific, such as how they view the institution and organization, and what kind of an image or online presence they (or their audience) are comfortable with.

Ideally you will have several meetings and ample input from various sources about what is desired, but do not despair if not. Communicate with your leadership about what can or cannot be done. Establish goals together, set deadlines (budgets too) and delegate pieces of the work, if necessary. Acquire any necessary software if your library lacks them. Communicate, communicate, communicate!

Survey the old site: the site map

When you have discussed the scope and desired outcome of the project, familiarize yourself with the existing Web site's structure. Mapping the existing Web site constitutes identifying two different types of structure: the site organization – or site map – you observe online, and the file structure behind it. The site map is the visible organization of content into categories and subcategories on the Web site. This is not necessarily the page called "Site map" on a particular Web site, but the actual organization of content. The file structure is the invisible organization of files into folders (directories) and subfolders (subdirectories) on the server. These two structures do not necessarily coincide or are organized the same way. First, familiarize yourself with the existing site map; understand the way the content is organized – or not organized – on the Web site. Drawing a category tree on a large sheet of paper, where every internal link on the site is accounted for, will be helpful. We also recommend printing the first sheet of every Web page and sorting it into the main categories that appear on the site.

Survey the old site: the file structure

Once the site map is transparent to you, you should access the server to identify which file carries which page of information, which filename on the server is associated with which Web page online. Identify every single file and folder associated with the old site. You will invariably be surprised at the number of unused and unnecessary files stored on the server. Mark the files that contain useful information vs. the ones that are not at all linked to or used by the existing site. Also note which ones, if any, are still being maintained and by whom. You should create an archive of the old site that preserves what existed before this project began, and simply build the new site in a different location on the server.

As time went by, more and more people may have gotten involved at your library and added new material to the site, each person following his or her own file-naming conventions, replacing (but afraid of deleting or archiving) files that became out of date. This may have led to the situation where files such as libinfo.html, libinfo2.html, and libinfo3.htm all exist on the Web server, but only the latest one is "live" and linked to the Web site. Furthermore, because of the initial filename limitations of the PC (8+3 characters) in the early 1990s, many computer users were used to truncating filenames, which contributed to the use and preference of shorter rather than longer (and thus necessarily cryptic) filenames. Therefore, you need to establish a mental link between the live Web page titled "Library Information Page" and the file libinfo3.htm residing on the server, next to its many older and deletable versions.

Create the new site map and file structure; establish standards

Like mapping the old site, drawing up a new site also includes developing a visible site map and an invisible file structure behind it. Propose a new site map – draw a new tree – for the new site and get your leadership's feedback, and ultimately their assent. Observing and understanding how other similar institutions have organized their information will be a great help and source of inspiration.

Even if your library's current Web site may not need an overhaul as far as the site map is concerned, it is very likely to need a new, more organized and consistent file structure, especially if there had been no uniform folder- or file-naming standards in place.

The hierarchy of the new file structure on the server usually will not match exactly the hierarchical organization of the site map. The site map may contain several hierarchical levels (e.g. people>students, and people>staff, where both "students" and "staff" are subcategories of the higher "people" category), while it is more practical to limit the number of subfolders in the file structure for programming and coding reasons. In order to keep the file structure simple, every category and subcategory of the site map should have its own corresponding file folder at the same (the top) level, with its default index.html file. To use the above example, there would be a "people" folder, as well as a "students" and a "staff" folder on the same hierarchical level on the server, even though in the site map the latter two are subcategories of the first. Placing folders with files that are linked to a common template on an equal hierarchical level will facilitate an easier management of links to common page elements, such as common images.

At this time in the project, you should decide on the folder names and the filenames you will use for each page in the new site. For clarity's sake, be as descriptive as you can, although avoid spaces in the names. For example, the aforementioned libinfo3.htm file that contains the "Library Information Page" might be renamed info.html, or information.html, or even library_ information.html. The more descriptive the better; however, a drawback to a long name may be that it means a longer URL. In all decisions regarding standards, think of the future and keep in mind the person who in a few years might have to do the same job you are doing now.

Be consistent in naming folders and files, and decide whether you will use the htm or the html (or other) extension for your content files throughout the site. Mixing them without a reason may cause minor, yet unnecessary problems, and an annoyed Webmaster later on. Most Web site editor applications will let you set this as a preference so it does not have to be done manually.

Decide how you want to store the images that appear on the site. It is best to store images in a separate folder, which you might call "images" or "assets". The "assets" name has the advantage that you may more readily be inclined to put other files there too, such as PDFs, or Microsoft Office documents, which are linked to your Web pages the same way image files are.

Your site will have images that are common elements in many of your pages, including: logos, rules, navigation bars, buttons, borders, etc. There will also be images that are only used once, or only on pages of a certain category. Therefore you may decide to have an "asset" folder at the top level that contains the common images, and at the same time also have an "asset" folder within each of the main folders of the site, which would contain the images that are relevant only to the pages in that particular folder.

As a general rule, you should use the JPEG image file format for photos and images with many colors, and GIF for images with few colors, such as logos and other page elements. This will ensure that the format is optimal for the image, with respect to both quality and file size. Name the images in a consistent manner that will help future Webmasters better identify the image files on the server without necessarily having to view them. Again, top_banner_logo.gif is so much more descriptive than tpbnrlgo.gif.

Create a skeleton for demonstration

After outlining both the site map and the file structure, and establishing clear and consistent file-naming standards, take the stripped content from each page of the old site and create the corresponding new files in the new folders, and place the content into it. It is best to take the text content without any special character formatting (font, size, color, etc.), and use cascading style sheets later to govern font formatting across the whole site. You can create the skeleton of the site on your hard drive, but should upload it to a new folder on the server for easy access as you demonstrate it to other people.

Build up the skeleton of the site by linking the newly created pages with each other. At this time there are no common graphic elements or any special font formatting, only the old site's text in the default font format on the default background. If you use site management software such as Macromedia Dreamweaver or FrontPage, you can assign each file to a single template, the modification of which will automatically update all of the pages. In order to make the skeleton more presentable and effective – because, after all, people will notice the bareness of your skeleton demonstration – you can design a temporary good-looking template and a nice style sheet for the demonstration.

This demonstration will help you and your leadership visualize the way the new site is organized and navigated, and make further recommendations. It is a good idea to demonstrate the skeleton with a complete sample graphic look. If there is a separate person working to develop the "look" of the site, this would be a natural time to start to marry the skeleton with the graphic look. Even if it is a design no one in the group likes, its presence will help them visualize the proposed site more easily. If you do include such a temporary graphic look, be prepared though that someone will think that it is the final design, and a great part of the feedback may focus on the graphic design and not the organization or content of the new site map!

Create the graphic look

All the steps mentioned so far need not necessarily come before you get a chance to think about or design a graphic look for the site. This part is probably the most enjoyable task for many designers, and many may start out the whole redesign project by first creating sample designs for feedback. That is also a good way to start; however, we do want to stress the importance of planning the new site organization and file structure. It is probably easier to change the graphic design of a site later on than it is to make changes with regards to the file structure, the site map, or the file-naming practices.

Unless your leadership does not intend to have any input in the graphic look of the site, you should create a couple of samples and discuss with them which one they prefer. Keep in mind that your library is a building, a place with people for people. The windows around the building are the same. The walls are the same all around, built by the same builder. The doors of offices are consistent too: they are all wooden and are the same color. Therefore, make the graphic design convey a sense of place and community. Treat it as the virtual equivalent of the physical building you work in, which people visit every day. Both the library building and the library Web site serve as holders of their respective contents, and should not compete with their contents for the attention of visitors.

As you create the look of the new site, consider the latest usability data available concerning the most common monitor sizes, your audience's speed of modem connection, the compatibility and popularity of different Web browsers, the readability and popularity of screen fonts, and countless others. Running focus groups at different stages of the redesign may be useful for immediate feedback from primary users.

Create documentation

When the new site with the new look is ready and has been accepted by your leadership, and has been user-tested any way you may have planned, archive the old site and upload the new one.

Create detailed documentation about the site to serve as a reference to others maintaining the site and for future Webmasters. Explain the file-naming conventions, the file structure, and everything else that a newcomer would find useful. Think of what you would have needed at the outset of the redesign project, had anything been provided. You can describe the function of any forms or scripts you have used, or the metatags you used in the header. The anatomy of the template, if you have used a template, and even how to use it, should also be included here. The comment tag within HTML pages is also an excellent way to let future site maintainers know the functions of several page elements.

Conclusion

The Web site of your library is a building, after all, and it should be treated accordingly. Like a brick-and-mortar building, it should be professionally designed and built, as well as professionally maintained. The whole Web site, just like a library building, should display the work of one common source: either that of one designer/architect or that of a group of them in agreement. The designers should put together standards and guidelines to which future additions and updates would have to conform. Page elements within the same section, like walls, should display uniformity. Calendars and news items should be kept up to date. Scripts, like light bulbs, should be working properly. Online patrons, like walk-in patrons, should be able to feel at ease and find their way around easily, just like in your library.

Recommended Reading

Dinucci, D. (2002), Adobe Master Class: Web Site Redesigns, Berkeley, CA. Adobe.Nine case studies of real-life redesign projects, from Chronicle Books to Refdesk.com to brainPOP.com. This book aims to help you think about how people use your site, how to create and maintain an identity, and how to plan ahead for future redesigns. It is illustrated with before and after pages, including the concepts that did not make it.

Garlock, K.L. and Piontek, S. (1999), Designing Web Interfaces to Library Services and Resources, American Library Association, Chicago, IL. An excellent introduction to library Web site design.

Goto, K. and Cotler, E. (2002), Web Redesign: Workflow That Works, New Riders, Indianapolis, IN. The strength of this book is its attention to the process of Web redesign as it pertains to large projects.

Krug, S. (2000), Don't Make Me Think: A Common Sense Approach to Web Usability, Que, Indianapolis, IN. An engaging, painless lesson on how to create a site that is effortless to use – and how to test the design you come up with.

Nielsen, J. and Tahir, M. (2002), Homepage Usability: 50 Websites Deconstructed, New Riders, Indianapolis, IN. This cocktail table-sized book is far more specific in nature than Krug's. Co-written by the author of the classic Designing Web Usability, it begins with over 100 dos and don'ts of Web design, followed by a point-by-point critique of 50 different Web sites. You may disagree with some of the author's assertions and his stolid resistance to creative solutions, but on the whole there is much well-researched information here. Nielsen also maintains one of the best-known usability Web sites at http://www.useit.com

Norlin, E and Winters, C.M. (2002), Usability Testing for Library Websites: A Hands-On Guide, American Library Association, Chicago, IL. Is your Board of Directors not really sure why usability testing is necessary? Would you like to see examples of testing questions? This very practical booklet focuses on the whys and hows of usability testing for most types of library Web sites.

Helpful Web Sites

Library of Congress Style GuideA well-thought-out set of criteria created to preserve the structure and identity of the Library of Congress's Web site.http://lcweb.loc.gov/loc/webstyle/

The Library Web Manager's Reference CenterA directory of Web sites recommended on the Web4Lib electronic discussion group, organized by topic.http://sunsite.berkeley.edu/Web4Lib/RefCenter

A List ApartAn excellent online journal devoted to Web design.http://www.alistapart.com/

Usability NewsThis biannual newsletter publishes the results of research on such user interfaces as fonts and link positioning.http://psychology.wichita.edu/surl/usability_news.html

Web Design for LibrariansA comprehensive tutorial on Web design within libraries. See especially the chapters on "Organizing principles" and "The four basic elements of information design."http://www.scc.rutgers.edu/scchome_old/policies/web.htm

Web4Lib Electronic Discussion Group ArchiveJoin this electronic discussion group dedicated to digital issues and information, or browse its rich archive.http://sunsite.berkeley.edu/Web4Lib/archive.html

Atilla Vékony (avekony@book publisher.com), MA, Information Manager, Wheatmark, Inc., Tucson, Arizona, USA.

Lisa Waite Bunker (bunker mentality77@yahoo.com), MA, Librarian (temporary), University of Arizona Library, Tucson, Arizona, USA.