When imagining the various platforms and formats digital authors are using to communicate their complex and interactive arguments, it can be easy to overlook some of the simpler components of web-based content. The topics we’ve covered so far in the Technical Guidelines series have ranged from somewhat to significantly philosophical, but our focus this week, “Links,” is a bit less abstract and perhaps even comfortingly straightforward. This is partly because practically every web-based work contains links, and as one of the most basic and fundamental aspects of the web, they’ve already become pretty well established in terms of their function and their potential pitfalls.
But even basic functions like linking can fall through the cracks when authors are facing more complex challenges with form and interactivity. So we came up with a guide to both help authors check something basic off their lists and also to remind them that even though they seem like simple little things, links can pose a real problem for the fidelity of any web-based work.
When imagining the various platforms and formats digital authors are using to communicate their complex and interactive arguments, it can be easy to overlook some of the simpler components of web-based content.
First, it can be tempting to use absolute urls when linking to files within the project. Fixed addresses seem, well, fixed, and thus more solid. But when you consider that the project will be moving during the production process from the development to the publication server, it’s actually much safer to use relative links. This way when the base domain changes, your internal links will automatically pre-pend those relative pathways with the new domain.
In some cases, when authors are using pre-formed platforms or text editors, they may not realize that when they add links via a GUI interface they might not be pointing links correctly. It’s important to check the source view when using GUI systems to ensure those hrefs aren’t unnecessarily populated with domain and even subdomain labels that will send the future publication server searching for a draft or development file that might not exist once the project has been published at its new home on the supDigital servers. Fixing these kinds of link issues can take quite a bit of time in the migration phase of the production process.
If it’s web-based, it’s bound to have links.
It can also be tempting to use the linkability of the web to short-cut traditional citation practices. Pointing out to external sources, though, guarantees that your project will be open to link erosion within months if not days. While it can be helpful to readers for bibliography citations to contain urls, making those urls active links means that if any of those sources, which authors and their publishers cannot control, move or are deleted from the web, your project has lost some of its functionality. It contains a dead link. And the more dead links a project contains, an inevitability over time, the more dated the project, in turn, appears.
These are just a couple of the aspects of linking the guidelines cover, and they’re considerations that should form the initial planning of any interactive digital work. If it’s web-based, it’s bound to have links. So establishing a standard protocol from the beginning will make the whole process go much more smoothly.
Jasmine Mulliken is Digital Production Associate at Stanford University Press. She coordinates the production and workflow of born-digital projects, including recommending platforms and coding standards to authors, consulting with authors on projects’ technical attributes, and evaluating best practices for archiving and preservation.