Anatomy of a Landing Page

While complex web-based projects present challenges in the way of longevity—the average lifespan of a typical website is supposedly two to five years—there are measures that we’re taking to mitigate inevitable decay. In addition to our guidelines package and three-pronged preservation strategy, which we begin planning for before a project is even published, we’re also applying safeguards to our live projects to simplify the eventual need to roll over to archived versions. One of these safeguards is a static landing page. Similar to a print book’s jacket, it’s a piece that contains a project’s metadata but that is also self-contained, easily detached, yet persistently linked to the content it “wraps up.”

Here’s our latest publication’s landing page, which we can use as a map of the key components, outlined in blue and numbered corresponding to the key below:

1. Cover image
2. Publisher info and branding
3. Title
4. Author
5. Cover copy/description
6. Author bio
7. Blurbs
8. Copyright
9. ISBN
10. Catalog record
11. DOI
12. Terms of use
13. Archive info
14. Enter button
15. Background metadata

Items 1 through 9 are typical items found on any book’s jacket, cover, or front matter. The other items are additional pieces we’ve identified as critical for web publications, whether for access or citation.

In addition to an ISBN (9), we assign DOIs (11) to each publication at the project level as well as, when appropriate, to components of the project. These DOIs (digital object identifiers) ensure a persistent url that will always be attached to this landing page, even if the landing page moves or updates. So even though the url in the address bar reads whenmelodiesgather.org, a reader can also navigate to the project by entering doi.org/10.21627/2018wmg, which redirects to the active space on the web where the project lives. If the url ever changes, it’s easy to redirect the same DOI to a new location. (The suggested citation listed in the terms of use page contains this persistent DOI-based url.)

Similar to the DOI, the OCLC record number (10) is yet another identifier and is meant to provide an alternative to the Library of Congress metadata that’s still painfully elusive for interactive scholarly works like the ones we’re publishing. For now at least, the LOC doesn’t offer a way to catalog an object without also holding a copy of the object (and holding a copy would border on essentially hosting the project), so we’re leveraging our own institutional connection to Worldcat’s catalog to seize yet another opportunity to document the release and existence of these publications. The hope here is that, among other things, it could begin a discussion of how individual libraries might pull these records into their own catalogs so the researchers they serve will be aware the projects exist and that they can indeed be accessed online at no cost. It’s not a direct dissemination path, but it’s somewhere to start.

The terms-of-use page (12) sits in a subdirectory of the landing page package and shares its styles. In addition to typical book copyright and legal disclaimers, it provides info about special web licenses and open-access qualifications. It also provides a preferred citation, including the project-level DOI.

The archive links (13) provide access to archived versions of each project and resources that otherwise preserve its components and document its functionality and user experience. When a project is first published, we begin building that archival material so that alongside a project’s gradual decay on the live web, we can provide readers an alternative way of accessing and navigating the material. The documentation link eventually provides readers with a description of the project’s structure and navigation, its technical specs and requirements, and narrative of the user experience, including screencasts and images. The web archive link allows readers to view the entire project as it looked and felt at its initial release via WARC files and, when necessary, dockerized dependencies. Finally, the Stanford Digital Repository link takes the reader to a catalog record for the repository collection once it’s deposited. The collection is comprised of copies of all the files that sit on the server that make up the project and would be needed to someday reconstruct it. Each of these components—the documentation, the web archive, and the repository collection record—become activated once they have been prepared and released. The release varies depending on the project’s anticipated lifespan and when the material becomes available or necessary. The first priority is to serve the content live as it is published, but adding these alternatives as the project ages ensures continued and uninterrupted access to the content, securing its space in the scholarly record.

The Enter button (14) takes the reader to the active version of the project, whether that’s on the same server, an emulated environment, a virtual machine, or a repository. For now at least, all our projects are living on the live web via servers we manage. Once a project is no longer viable on the live web, the Enter button will take the reader to either an archived or emulated version of the project–whichever presents the highest fidelity or closest approximation to the live project. But no matter the format of the project, the landing page will remain in tact and will be the common piece linking all the content together.

The background metadata (15, not pictured) consists of html code that isn’t rendered as something necessarily visible on the screen to the average reader but that helps other utilities access or index the project’s metadata and content. Examples of this are citation meta tags in the html head and links to images to be displayed as thumbnails or cards on various devices or social media. It’s all standard material for pretty much any website, but in addition to all that we’ve included substantial chunks of text and bibliographic material from the project to hopefully enhance the project’s discoverability by black-box search engines and indexes.

In the end, the logic of the landing page is that it serves as a single, static, updatable space that can outlast the moving parts associated with individual projects’ unique frameworks, platforms, or custom components. We’re essentially mitigating the uniqueness of each project with simple scalable entry points that we can customize for each project but that retain all the same vital elements. The above example, for instance, resides outside of the full project’s Scalar package at its own domain that will not be affected by any positive or negative changes to the Scalar platform the project uses. As live projects begin to naturally degrade, the landing page remains the portal by which readers can access archived versions of the project, whether they’re web archives, emulated environments, or pieces comprising a digital repository collection. And the metadata on the page, both exterior and under the hood, ensure citability and persistence. Though formats may change, the data that lives in these small simple packages is adaptable, and what seems a basic intervention effects great strides towards sustainability, both of the projects themselves and the ISW publishing program in general.