Redesigning (Again) Web Sites

Citation

Yamamoto, D. (2003), "Redesigning (Again) Web Sites", Library Hi Tech News, Vol. 20 No. 4. https://doi.org/10.1108/lhtn.2003.23920daf.001

Redesigning (Again) Web Sites

David Yamamoto

Once again I find myself faced with what has now become a biannual ritual of Web site redesign. Knowing that this is probably one of many more to come, I have taken a long hard look at our site to develop strategies to make it more responsive to users, new technologies, and the unforeseen. I have also taken a cue from the business world, resolving that it is no longer acceptable to do things inefficiently, nor is it acceptable for our customers to shop elsewhere because they cannot find what they are looking for. My explorations have led me to other library Web sites, where I have found that, while graphics, layout, and nomenclature may vary, the underlying concept and structure of most library Web sites are remarkably singular and universal.

Redesign work seems to occupy many of our library colleagues and Web managers these days. Invited to write a piece that shares some lessons learned and common observations from my work, what I offer readers with this brief essay are my observations accompanied by proposed strategies for Web design, development, and content management that I plan to implement in my library. Some of you might feel that I could very well be describing your library, while others of you might feel that your environments share nothing in common. Some of my ideas may be novel, while others may be obvious. Managers might consider my proposals as needed and welcome change, while dilettante designers might hear them as the death-toll to their one outlet for workplace artistic expression. It should be noted that my conclusions are purely empirical and unsupported by rigorous scientific methodology. It might also be worthwhile to note that I spent years as a dilettante designer committing the very sins that I would later condemn as an enlightened manager.

Establish a uniform graphic identity

Design inconsistency flourishes when departments employ local sub-site designer/developers that work independently from one another with no oversight or focus on the vision of the library's site as a whole. Within a single site, it is often possible to identify as many different page banners, color schemes, and styles as individual designers. No matter how much more beautiful and sophisticated designer A's site is than designer B's, the net effect for the entire site is an amateurish, home-grown look and feel. More importantly, design inconsistency makes it difficult for users to identify key navigational elements and visual cues that tell them where they are. Design inconsistency can also be costly from a maintenance standpoint.

Eliminate design inconsistency. Establish a strong, library-wide graphic identity and global template that are centrally designed, maintained, and implemented throughout the entire site. It is not necessary to pay a lot of money to a firm to develop a slick corporate ID, nor is it necessary to strive for usability perfection the first time around. The key is to create an environment that is responsive and flexible to change. A site employing a single bad global design that is consistently applied is easier to diagnose and less expensive to fix than a site employing a multitude of templates, some of which are good.

Consistency need not be confining and monotonous. Different pages serve different purposes. A well thought-out design can include consistently placed key elements and be flexible enough for customization depending on the purpose of the page. Uniformity and centralization will not stifle creativity. Talent should be channeled into collaborative, coordinated efforts to develop, test, and improve global designs that all departments may utilize.

Stop naming everything

A visit to many library Web sites reveals pages riddled with resources and services named (all fictitious by the way) "PodunkPAC," "ERez," "DigRef," "DocuXpress," "InfoTrove," "EtitleWave," etc. Often, they are developed, packaged, marketed, and delivered as stand-alone products. This creates confusion on the part of the user, who does not understand what these tools do or why or when they would want to use one versus another. Software from different vendors often lacks interoperability and cross-functionality. Installations do not always share a uniform graphic identity and common look and feel, further segregating them from one another.

Present resources and services to users as seamlessly as possible in the context of the anticipated task at hand. Do not create links containing the name of products; create links that tell the user what they will be able to do if they click on it. If creating true system interoperability and cross-functionality is not possible, fake them. That is, use graphic consistency to create the illusion that the user is interacting with a single system. If possible, use encoded URLs to pass data input by users so they do not have to re-key them each time they transition from one system to another. When a new library service or system comes online, do not give it its own product name, market it as a site enhancement.

Erase the lines between your Web site and OPAC

The notion of the library Web site and OPAC as separate entities persists from the early days when the OPAC was the library's only information system. With the advent of the Web, first generation sites came online, which served primarily as signposts to the OPAC and other databases, or as a medium to deliver brochure-type information. Later, as the capabilities of the Web matured, libraries developed digital collections and services once only available within the library. Despite many advances, the concept of the library Web site has changed very little since those first generation sites. Many libraries still view their Web site as a parallel, somehow separate system from the OPAC.

Do not think of your library Web site as a collection of links to resources such as the catalog, full-text databases, Web pages, etc. Rather, think of all of these pieces collectively as your library Web site. In the future, truly integrated library system software offering functionality beyond traditional acquisitions, cataloging, and public access will become available. ILS vendors should (whether they will remains to be seen) bundle content management components into their systems that will make static Web pages a thing of the past. Improvements in cross-database metadata discovery and presentation will make abstract ideas such as "library portals" and "access integration" realities. Become blind to the lines drawn between your different library systems now, because your users already are.

Users do not care about your organizational chart

Imagine if Amazon.com was modeled after its internal organizational structure, with links labeled "marketing," "shipping and receiving," "purchasing," "warehouse," etc. It sounds pretty silly but the architectures of some library Web sites still reflect the physical and administrative organization of the library itself. This is particularly true in large academic libraries comprising many subject-specific libraries. This can also be true in smaller libraries where collections are maintained within departments.

A user should not have to know which physical library building or department collects materials in a given subject area to be able to locate information on your Web site. Present resources and service based on user needs and expectations as opposed to institutional organization. Build navigation schemes that organize resources and services by subject, format type, or the task at hand. If your library is large and decentralized, try moving toward the concept of "a single library Web site." Departments that are physically and administratively separated can continue to contribute to the Web site, but your users do not and should not have to know it.

Centralize content creation whenever possible

Decentralized content creation can result in pages varying in amount, type, and accuracy of information. A lack of coordination and communication among content creators can lead to duplicative efforts and wasted time. More importantly, users discovering inconsistent or outdated information may question the credibility and professionalism of your operation.

Take an inventory of your entire site to identify general information that is relevant across all units or departments. Assign the responsibility of periodically evaluating and updating that information to a full-time position or committee. Encourage departments to link to general information from their Web sites and focus their energies on creating and maintaining department-specific information only. Harness the creativity and expertise of reference and instructional librarians and coordinate their efforts into building a central repository or help and research assistance pages.

If you have a very large site, an inventory and consolidation of content can seem like a daunting task. However, the time and effort invested now will pay off later. Centralization will improve the accuracy and timeliness of information, reduce time and effort to propagate changes, create a more consistent editorial and publication style, eliminate duplicative effort at department levels, and make implementation of a content management software solution easier if or when you do it.

Create even lines of service and functionality

A lack of coordinated Web programming and knowledge sharing among staff can lead to varying levels of service and functionality across departmental sites. For example, department site A, maintained by someone with more advanced HTML skills, might offer users a comments submission form, while site B, maintained by someone with more rudimentary skills, may rely on the browser's e-mail function. Visitors to any area of your site should expect and receive the same level of functionality and service, regardless of the experience and knowledge of the individuals maintaining the site.

Establish library-wide policies defining a minimal level of functionality for each page. Pool coding expertise and create a repository of reusable scripts and HTML code blocks that perform different functions. Create a mechanism by which department Web designer/developers can communicate needs for new programs and tools. If one department needs something, the chances are pretty good that another could also benefit from it.

Stick to HTML basics

"Artistic" use of HTML for presentation and visual effects makes it difficult for users using specialized screen reading software to understand the organization and navigation of your site. Furthermore, non-standard HTML makes it difficult, if not impossible, for automated parsing routines to interpret the logical and structural nature of the content. Failure to keep content separated from presentation instructions will make importation of text into content management systems and other storage and delivery technologies costly and time-consuming.

Develop structural HTML mark-up guidelines and a Web publishing style manual. Also establish policies that require all Web content contributors to follow these guidelines. Centrally create and maintain a single cascading style sheet that drives the presentation of all content throughout your site. If there are departments in your library that maintain pages that serve specialized purposes, create different style sheets for them but make sure they adhere to the structural HTML mark-up guidelines and style manual.

Sticking to HTML basics will improve access for the visually impaired; create more consistency in style, appearance, and use of color; make global changes easier; lower maintenance and conversion costs; reduce workload at department levels; and lower staff training and software costs.

Anticipate and welcome change

The only constant in Web development is change. In the decision-making process, ask yourself if a proposed design, policy, technology, or workflow will accommodate frequent change. If the answer is no, then a revision is in order. Also, do not become obsessed with initial roll-out of what you hope will be the perfect site in terms of usability. Doing so will only push back deadlines and make you averse to change in the days and months following initial roll-out. Establish policies and procedures for the ongoing evaluation, testing, and refinement of Web page designs and expect and anticipate making changes as you go along. Do not let the fear of jarring your users with frequent, minor changes keep your from making true improvements to you site. It is my belief that change is disruptive only when users have been trained to use a bad design. A well-tested design that is truly an improvement in usability will be transparent to the user.

The UCLA Library Web sites at www.ucla.edu/library.html and www.library.ucla.edu/ allow you to see the current presentations of Web site development.

David Yamamoto(davmoto@library.ucla.edu) is the Public Service Web Developer at the University of California, Los Angeles (UCLA) Library, Los Angeles, California, USA.