Keep it Simple

A major goal of our work has been to keep the implementation simple, avoiding external dependencies where possible. The universal header and footer uses fewer than 400 lines of JavaScript code and functions without any additional libraries or frameworks. This implementation strategy allows the team to work in a codebase that is simple to understand and easy for vendors to change.

The universal header and footer are divided into modules. This allows a main program file to import configuration files customized for particular UKL web properties.

Centralize Configuration

Having a single set of files for header and footer content across multiple websites reduces development costs of maintaining, extending, and troubleshooting the code. Instead of multiple implementations across various content management systems and programming languages, there is one centralized set of files. This allows a group of editors to connect to a single file system to modify configurations and code instead of connecting to multiple systems. Adjusting the HTML response header configuration via server settings also allows us to disable caching of the universal header and footer files, so that users receive changes immediately. You can see the implementation of the universal header and footer in Figure 2.

Figure 2. Network architecture of the universal header and footer.

Follow Campus Branding Standards

Work on the universal header and footer began with collaboration between library personnel and members of our campus Marketing and Brand Strategy Web Communications group. This group provided us with campus web standards, including required colors, fonts, logos, navigation links, and mandatory header and footer elements, as well as a mockup design adhering to these standards. Once we reached consensus on design of the mockup, we began work on coding the header and footer.

Coordinate Messaging Across the Libraries

We wanted to be able to coordinate messaging across library web pages, and the universal header and footer helped us with this goal. Having the code in one location facilitated separate configurations for each satellite website while also establishing a global config to turn on alert messages and survey prompts for all websites set to allow this feature.

Follow Web Accessibility Standards

We built the header to meet Web Content Accessibility Guidelines. We took the colors from campus web standards and composed them to pass requirements for text contrast. Where the contrast was close to failing guidelines, we increased font weight. We used Accessible Rich Internet Applications labels throughout the headers to provide access to screen readers. We also selected the project font from the list of campus web standards. We chose Usual from Adobe Fonts for its flexibility as both a header and body text font, maintaining clear contrast at larger sizes and readability at smaller ones.

Enable Reuse Across the Libraries

Another design goal was the ability to reuse the code across web properties. We accomplished this via the combination of dynamic imports and an HTML attribute named “data-base_path.” This attribute serves as the path on our server where the configuration would be loaded differently for various “data-base_path” attributes. We provide details for this configuration below.

Maintain Code Flexibility

While developing and maintaining software is a continuous effort, the current iteration has proven flexible enough to add features quickly. In the third design iteration, we added new features in anticipation of release among several UKL web properties: requested logos with appropriate fallbacks for each vendor, additional messaging layers, and optional drop-down menus. Throughout the process of adding features, we continue to incrementally refactor code to improve simplicity of the design. With the current setup, we provide the resources needed for each new feature within the configuration, and we add the code for using that data either as part of a function or a function by itself.

Provide Fallback for Code Delivery

The header’s current implementation involves recreating the script from a different source in case of errors. This source for fallback behavior is a CDN that allows us a fallback with multiple points of failure. We designated the CDN as a fallback instead of as the primary distributor because of caching concerns; it sets browser caching expirations at around a week from their first usage of the header. This long expiration time means changes don’t appear quickly, so we can’t use it as a primary source. But using it as a fallback allows us to set generic messaging to let users know there is a problem, and the version on campus will replace it as soon as website issues are resolved.

The implementation assumes that if one of the pieces of the universal header were to fail, then all would fail. Essentially, the only piece that triggers fallback behavior is the error occurring on the universal header HTML script. On an error, the script will:

1. Rebuild itself with the script hosted on the CDN

2. Rebuild the footer with the script hosted on the CDN

3. Set the src attribute for the CSS to be that of the CDN

4. Clean up the HTML, deleting the unused scripts from the page

Customization for Individual Sites

We implemented the universal header and footer as a script tag in the html <head> element. It includes the location of the script, as well as some fallback behavior in a block of JavaScript. An example of the implementation is in Figure 3.

Figure 3. Example implementation of main header script.

Required elements in our implementation are standardized identification names and specification of a “data-base_path” that corresponds to the file path of the configuration on the host server. In universalheader.js, we select this HTML attribute and, using the dynamic import language feature, import the appropriate configuration for the host of the HTML. The dynamic import is a feature introduced in 2020 that allows us to import modules via a path or URL, a useful tool in this case. This allows the universal header to take different configurations of certain layers for each vendor.

For organizational clarity, we standardize the configuration file paths. Additionally, we use a global configuration for items that our team wishes to standardize between instances, for example, exact colors for each layer and the various pieces of central messaging. Figure 3 illustrates the layering.