Introducing Digirati’s work with the Victoria and Albert Museum and the Delft University of Technology Library: we’ve been making tools that bring objects from a digitised collection into the editorial process.
How much time and effort can you spend on bespoke narratives built from collection content? If your collection is available via the IIIF Presentation API, then it could be less time than you think.
Suppose you have a large collection available as IIIF. Perhaps each catalogue page shows a viewer providing a common user experience. Each item in the collection is published as a IIIF Manifest. If you want to tell a story about an object or a small set of objects, you might embed that same viewer in a blog post or article page. That’s already a powerful reuse mechanism. But you don’t have to use the same viewer for the same object in different places. You could build (or reuse) specialist viewers for different purposes.
And you can stretch the definition of a viewer a long way, to include any visualisation of collection content (text, images, audio, video), or editorial additions to that content in a particular context, such as slideshows, timelines, long-form narratives, and complex interactive forms like The Garden of Earthly Delights. If you’re working with IIIF, you can also stretch (or discard) the notion of an object: IIIF doesn’t care what the content is. It can be used as a format to get any complex digital structured content to the presentation layer. So maybe this is the answer — use IIIF to drive your special narratives, rather than some one-off data model.
Don’t build a snowflake, just use IIIF! The problem with this approach is, on the face of it, the same problem that applies to rolling out bespoke microsites for new exhibits: cost of production. You still need to build these specialist viewers, and you still need to assemble the content from collection sources to feed your new storytelling mechanisms. Even with a viewer (however loosely defined) ready to go, that’s a lot of content production.
IIIF can be the format for transmitting the custom content to the page or viewer, as long as you can get it into that format. But if your collection is IIIF, it already is in that format! You might just need to tweak and embellish a little.
While just using IIIF is not going to invent new narrative user experiences for you, it can make a big difference elsewhere in the production process. If your new user experiences are driven by IIIF in the presentation layer (either in the web page directly, or in the code that assembles a web page), then the production task becomes one of selection, assembly, remixing and editing — which can all be done without leaving the IIIF model. It’s IIIF all the way through.
The sources (your collection, and also anybody else’s collection) are IIIF.
The production environment is IIIF.
And the output for use on a web page is also IIIF.
No new formats or data models are needed. But can a IIIF manifest, which might contain arbitrary parts of other manifests as well as additional content, drive all these kinds of viewing experience? Yes, it can — with the occasional light sprinkling of additional layout and behaviour hints via the IIIF extension mechanism, whenever more clues about interaction are needed.
IIIF meets Editorial
The V&A’s in-house content management system has a content selection widget. Sources for page components include conventional elements like images as well as resources for embedding, like SoundCloud. There’s also the Universal Viewer for IIIF Manifests and a deep zoom widget for IIIF Image API endpoints. And now, some specialist narrative forms:
Besides the slideshow viewer shown above, we developed a few more IIIF-driven interactives for the V&A:
These two are driven by the same IIIF resource, containing a single image with annotations for each region of interest. And you could have other renderings too, including a regular IIIF viewer.
At first, these were one-offs. We then made an ad-hoc editor to allow the creation of further Ocean-Liners-style Annotated Zooms. But everyone really wanted a framework for IIIF production to drive these narratives. We wanted to support browsing then selection of and from existing digital objects in the V&A’s collections, and from any other IIIF collections, including internal asset management for new content.
What we needed to do was marry the collection at scale to the editorial process. IIIF is perfect for this — but lacks tooling.
This doesn’t work if we have to assemble the IIIF by hand. So we’ve been building tools that address these use cases.
The Digirati Manifest Editor
The Digirati Manifest Editor began with a project for Delft University of Technology Library. They were using a modular exhibit system for physical exhibitions:
We built a static site generator that builds a digital version of this exhibit, from a IIIF Manifest. The editorial task is to assemble a Manifest, from existing resources and new content, for feeding the static site generator (which takes the role of the viewer in this case — the viewer isn’t a component on a web page, it’s an entire generated site). Content is selected by browsing IIIF collections, or by adding new source images and text directly. In TU Delft Library mode, the editor has a plugin for our DLCS hosting platform, so you can create new IIIF Image API resources by dragging in images from the desktop (this can be seen in the footnote video).
A completely standard IIIF Manifest can carry all the content required, but can’t on its own convey some Delft-specific layout hints and behaviours. The Manifest Editor, when built with the TU Delft Library plugin, exposes additional user interface and a preview display for this extra information.
The V&A have different requirements, therefore their editor has different plugins available:
For the V&A, the IIIF Collection Explorer tab shows the V&A IIIF content by default, but can also browse a writable IIIF Collection, so that work in progress, and the final release version, can be saved and then made available to the CMS selection widget seen earlier. The Manifest Editor becomes an additional tool in the editorial process; it creates IIIF Manifests instead of CMS records; these manifests then get integrated into pages just like any other content resource. Sometimes, as in the above example, the output is the only content on the page.
For the slideshow plugin, we embedded the custom slideshow viewer directly into the editor, rather than a regular IIIF Canvas in the centre panel. We also override some of the names of IIIF model elements, to suit the users of the tool. “Canvas” becomes “Slide”, “requiredStatement” (a IIIF property) becomes “Legal notice”, and so on.
If the editor mode switches to “no plugins”, the tool becomes a regular IIIF Manifest Editor — more options appear, and concepts regain their IIIF model names.
If we want to make new experiences, we still need to build the code to render them. But because it’s IIIF, we might find that someone has already made an experience close to the one we want. And if not, it should be quicker to build that new experience in IIIF than from scratch, because of all the wonderful libraries the community produces. Once we’ve built it, we can share it with others, too, so they can use or adapt it.
We might find that the standard IIIF model has enough richness to drive our new timeline, visualisation, story, map, or whatever we might make (the viewing application is in charge of the interaction). If not, and we really need something extra (like TU Delft Library, or the slideshow editor which provides some simple layout hints), we can do that on top of the editor; take all its IIIF editing and organisation features and sprinkle our extra requirement on top.
We also know that, even with custom behaviours and extensions, the content we’re producing is interoperable — it’s still IIIF even if another viewer ignores our extra hints. It’s part of shared IIIF space too, and available for further reuse just like the items in the catalogue, exposed as regular IIIF in a regular viewer.
The Manifest Editor can make regular IIIF Manifests, for consuming in a viewer like the Universal Viewer. An example of this would be using the editor to knit together two sides of a correspondence, from multiple source manifests.
The Manifest Editor can make regular IIIF Manifests, for consuming in specialised tools. For example, a timeline viewer that picks up on navDate properties in the Manifest.
The Manifest Editor can make IIIF Manifests with extra properties, through extensions. Those extra properties are sometimes needed to influence layout or behaviour in a specialised viewer.
The production method has benefits even if you don’t have IIIF sources to start with, because you get the editor and the IIIF model it produces “for free”, and can make use of existing libraries and techniques when making the presentation layer. But if you’re feeding IIIF source material in as well as producing it, the production benefits are quite dramatic.
IIIF Modelling challenge
If you have a particular narrative form that you like, an example of building on collection content (or any content) to tell a story, send it to us and we’ll see how it could be modelled as IIIF. If it can be modelled in IIIF, it can be created in the Manifest Editor.
We’d really like to do some research on this tool and understand more content creation and editorial integration use cases. If you would like to help us, please get in touch! If you want to work with us to build more content forms, and maybe plugins for the editor to aid in the creation of those forms, please get in touch!
Huge thanks to the Delft University of Technology Library, and the Victoria and Albert Museum for giving us the chance to work on these tools.
— — —
Footnote: a longer look at the Manifest Editor
This video shows the Manifest Editor in use, remixing IIIF content and (in Delft mode) building a IIIF Manifest that is then used content by a static site generator, to build a set of HTML, Image, Script and CSS files that can be deployed anywhere.