Through our Mellon-funded work with Johns Hopkins University and Tufts University as well as with Brill Publishers, abstractions emerged that led us down the path of extending the existing Scaife on Perseus with a much more flexible, componentized system.
The goals are:
- to decouple the ingestion of texts from the UI-layer that presents these texts (this also enables us to then serve up more than just texts)
- to enable building a new site with more composition than custom engineering
- to create an ecosystem of widgets that can be reused and built by the digital humanities community
Goal 1 – Architecture
The first step in achieving these goals was to extend the architecture.
By decoupling the frontend UI-layer from the backend, we open up a ton of opportunity for rapid development and innovation in how people interact with the text and metadata. This also means that there could be multiple backends supporting text and standoff annotation in different formats.
We are referring to the backends, at least in the text cases, as Text Servers. The primary job of a Text Server is to ingest source texts and annotations and alignment data (although alignments might be seen as just another form of annotations) and then provide an API to any frontend consumer. A single Text Server might service more than a single frontend.
Goal 2 – Composition
Enabling the digital humanist to build and launch a new site with a minimal amount of expert programming knowledge can be achieved through composition, rather than doing a lot of things from scratch.
If we have some well known Text Servers up and running already for texts you care about but you want a your own site, the ideal is to be able to just install a few packages, arrange them how you like, and then deploy.
Or maybe there is some custom thing you want to do with the data—you can build on top of this composed site by building a custom widget (that you hopefully open source, though are not required to).
Goal 3 – Ecosystem
For over 10 years, we have built up an ecosystem of reusable Django apps that enable composition of web applications. The idea being that 80% of most web applications share the same functionality—so why re-invent the wheel. Let’s bootstrap an application with the reusable bits through composition, and then spend the engineering time on building the new bits.
This same approach is where we are taking Scaife. The Scaife ecosystem will consist of the scaife-skeleton, extendable widgets, and various template projects. Such projects will use the Scaife Skeleton along with popular arrangements of the widgets, that are ready to go out of the box.
The First Step - Scaife Skeleton
The first step towards these goals was realized when scaife-skeleton was published in June 2019. This installable package ships with the the main framework from the popular Scaife reader, which features two collapsable sidebars plus the main content reader area. Widgets can be dynamically added or removed based on the content that you'd like displayed.
This is the foundation for any Scaife reader. It consists of two main skeleton types, FixedSkeleton and EditableSkeleton. In the FixedSkeleton case, you—the site developer—pre-determine and decide what widgets will belong to the layout. With the EditableSkeleton, you only provide the options of possible widgets and the user of the reader selects the layout at runtime.