Creating our forthcoming Typology of Legal Technologies was an interesting challenge. The evolution of the research methodology and the development of the tool happened in tandem, moving through multiple iterations over the course of almost two years to achieve a kind of symbiosis in the final product.
On the one hand, the research component was informed by the structure and affordances of an interactive, visual, hypertext interface, while on the other the design of the interface was informed by the substantive meaning that we wanted to convey through the Typology.
This took many evolutions, prototypes, tests, demos, discussions about methodology, discussions about discussions about methodology and, ultimately, knot-cutting. In the end, to be useful all research must define its own limits.
This experience was instructive on a meta level. Not surprisingly, the research component of the Typology was challenging to produce, particularly in terms of understanding (i) what a typology is and what it’s for, (ii) what should go into it, given our research concerns, and (iii) how to wrangle and synthesise a hugely disparate set of real-world resources into the framework we developed. But in addition to this more traditional form of research, developing the method of presentation was itself a challenge, because it needed to (i) reflect the conceptual structure of a typology, (ii) make sense to the various audiences who might come to use it, and (iii) be useful. The ultimate result is a demonstration of McLuhan’s oft-quoted aphorism, “the medium is the message”.
We will cover these themes in more detail in future entries, but in this post I’d like briefly to set out the technical aspects of the tool. This might be of interest to those who would like more flexibility in how they present their research to the world – because while there will always be a place for the classic academic article, edited volume, or monograph, we think there is real merit in making use of the affordances of the web to materially enhance how we communicate and disseminate research.
The Typology isn’t just an electronic version of a print document, but is – we hope – something more than that, something that provides novel ways to interact with the substantive textual and visual resources we have gathered and synthesised.
It is of course also accessible – not just open access (like the rest of our publications website, the Typology is licensed under a Creative Commons license), but also accessible across a range of devices, not to mention easily searchable and archivable. This affords something more than an open access PDF does; put bluntly, if the Typology was a 120-page report, it would likely be read by a small fraction of the audience it has now.
And speaking of audiences, given our focus on cross-disciplinarity it’s essential that we actively speak to members of the disciplines we are purporting to address. This means not just providing (open) access, but also access of the right kind. Cross-disciplinarity should not be a buzzword, but something that we actively seek to make happen. We hope we have taken some steps towards this with the design of the Typology.
The front-end
The Typology is a set of pages within our publications website, which was built using the static site generator Jekyll, combined with the just-the-docs theme. I heavily modified the latter, (i) in terms of its aesthetic fit with the COHUBICOL ‘brand’, and (ii) to extend the ability of the main navigation menu to show multiple levels – necessary for the online publication of our working paper. The page layouts are mostly bespoke too, particularly the Typology profile pages.
The Typology itself combines various libraries and bespoke JavaScript. The most obvious example is Isotope, which powers the block filtering interface on the Typology homepage. Apart from that, we made use of Nutshell, a clever and very new library that I happened to stumble on on the day it was launched in August 2022. Nutshell is designed to deliver on (part of) the promise of the Semantic Web, allowing the dynamic embedding of parts of one page in another, akin to the idea of StretchText. StretchText has never really taken off, but for our purposes the idea is perfect – connecting multiple research resources (the Typology profiles, the vocabularies, and the working paper) in a fluid way, helping our readers to see, in situ, connections between CS and law that might not otherwise be apparent to them.
We hope the ‘nutshelling’ of law and CS terms in the Typology contributes to this, in line with the broader approach to cross-disciplinary dialogue that we have adopted for the Journal of Cross-disciplinary Research in Computational Law.
The back-end
Jekyll
As mentioned above, the website is built using the static site generator Jekyll. This means that there is no database as in e.g. a Wordpress website, but only HTML, CSS (Cascading Style Sheets), JavaScript, and JSON (JavaScript Object Notation) resources that are served to the web browser.
From the perspective of a research project like COHUBICOL, this is valuable for a couple of reasons. Firstly, it means the website can be copied very easily, to more-or-less any server or even a personal machine, without any setup required. This is good for archival purposes and for the continued operation of the site beyond the term of the COHUBICOL project. Secondly, it makes server administration a lot simpler (and cheaper). We host the website on Netlify (more on this below), which takes care of web servers, CDNs, uptime management, etc. This dramatically simplifies the work of the web administrator (me!), freeing up time for core research tasks.
Markdown
Like most Jekyll sites, the actual content of the website is stored as markdown text files (…the dark, foreboding Hyde), before being compiled into HTML to be displayed in the reader’s browser (…the respectable, polished Jekyll). Again, this dramatically simplifies the preparation of the text for online use, removing inconsistencies in style and formatting that frequently crop up when working collaboratively in e.g. Microsoft Word documents. (Although the Typology did start life as a set of Word files, where we created a ‘profile’ document for each legal technology, once we migrated to markdown and the NetlifyCMS (see below) we continued to work entirely in markdown.)
Inputting the text
To make inputting text easier for the team, we implemented the fantastic NetlifyCMS. This converts WYSIWYG rich text input into markdown files, ready to be put through the Jekyll conversion process into HTML. This meant adapting the NetlifyCMS interface to include all the bespoke fields and attributes necessary for the Typology, which involved getting to grips with YAML (YAML Ain’t Markup Language) to define the configuration of NetlifyCMS’s forms. Once this was completed, it meant each member of the team could easily get involved in adding their parts of the text directly into the draft site, without needing to understand markdown or Jekyll.
Github
The penultimate part of the puzzle was deciding where to store the source markdown files that make up the website. It made sense to use a version control system (VCS) for this, specifically Git (and Github), because it’s much cleaner than wrangling messy Word docs and is designed for plain text-based files, including markdown. Using Git also meant we could develop the Typology independently of the published website, using Git’s branching functionality to run the draft Typology website alongside the live one.
Apart from this procedural advantage, Github (and other platforms that host Git repositories, such as Gitlab and Bitbucket) have the advantage that we do not need to manage hosting infrastructure for the files. This means less technical administrative work, but also that the files will be stored as an online archive that can live beyond the term of the project, and that might even be useful for future research – especially given the structured nature of the markdown files we created.
Netlify
Finally, the website is hosted using Netlify, an excellent cloud-as-a-service platform for serving (among other things) static websites. Netlify handles the compilation of the markdown files, by running a Jekyll instance in a virtual machine on their infrastructure, then hosting the compiled output directly through their content delivery network (CDN). When a change is made to a file on the website, and is then saved (‘pushed’) to Github, Netlify automatically detects and grabs the change, recompiles the website, and serves the newly-updated version to the world. This is all automatic, and, frankly, it’s fantastic. For simpler websites that don’t require dynamic database-driven pages (which is the majority of academic websites), it’s a really great approach – especially for projects where there simply isn’t time to spare for web server administration, upgrading CMS software, hardening against security vulnerabilities, etcetera. Simply make a change to a page, save it, wait a short while for recompilation (roughly 20 seconds for our site), and your change is public.
That concludes this very brief tour of the technical aspects of the publications website and the Typology. We hope you find the website(s) useful, and that they demonstrate what I discussed above: cross-disciplinarity in action. If you have any comments or feedback on the technical aspects of the site, drop me a line.
Discussion