Intro | Version 1 | Version 2 | Viewer 1 | Collaboration
This example is different. The developer has taken more control of the process, including the loading of resources. Obtaining and traversing IIIF resources is done before passing to Canvas Panel for rendering. CP knows about Canvases and what to do with their content. It doesn't know about manifests.
This Canvas Panel requires a perfectly compliant Presentation 3 canvas, so I need to make sure it's in that form before I pass it in. Which means I need visibility of some other libraries. For now, we'll use a manifest that I know is valid Presentation 3.
This example also demonstrates the "developer-friendliness" of Presentation 3, the JSON-LD
quirks aren't visible, the data model is traversed consistently with .items,
and so on.
<!-- The v2 Canvas Panel Component -->
<div is="canvas-panel-2" id="cp2" class="canvaspanel"></div>
<script>
async function init(){
let uri = "https://tomcrane.github.io/webcomponents/wunder.json"
let response = await fetch(uri);
let manifest = await response.json();
// manifest = normaliser.normalise(manifest); // skip for now
cp2 = document.getElementById("cp2");
cp2.canvas = manifest.items[8];
}
init();
</script>
I load in a manifest, then pass the 9th canvas to Canvas Panel:
(For now, imagine that this a deep zoom interaction.)
That was easy, and it feels more powerful. It's obvious what I'm doing, as a developer. I can use the version 1 wrapper around Canvas Panel to embed fragments, but with this approach I can start to build viewers with not very much code. I can have my cake and eat it.
What about controls within the canvas?
For spatial content that you can deep zoom into, we need +, -, rotate and flip controls.
For temporal content we need a scrub bar.
Are these part of Canvas Panel? Or do we need to link other components in to do this? OpenSeadragon has a similar issue - it provides its own navigation controls; they occupy viewport space. They probably don't fit our visual designs, so we want to replace them. The Navigator (picture-in-picture) of OSD is also a useful feature. In some scenarios, I'd like more control over these. But often I want them to be part of the black box Canvas Panel component, so that it just works...
As a developer, I'd prefer not to worry about hooking up that kind of behaviour. Canvas Panel should do this for me, but I would like a lot of control (by passing options? controlling through CSS?) of the visual appearance and availibility of these controls. Such as provide new buttons, specify their positions, turn them on and off. (The UV does this on top of its OpenSeadragon component.)
Navigation above the canvas level is not Canvas Panel's concern - IIIF Ranges generating a table of contents are essential features of a larger viewer or containing web page, but they are definitely not part of Canvas Panel. They are other components (and in fact, part of our developer toolkit surroundinf Canvas Panel). We're focusing on Canvas Panel here, not other IIIF components (a metadata display component is another example). But they might need to collaborate with Canvas Panel. If I select a range that's a partial region of a canvas (whether spatial or temporal) Canvas Panel will need to indicate that range.
The Universal Viewer does this for temporal ranges. There is collaboration between the canvas scrub indicator, the metadata panel, and the table of contents. These collaboration patterns need very careful consideration to avoid nasty dependencies. We will return to this in a bit.
It's clear there are many components we can use to build viewing experiences, and that these components collaborate. They have application interfaces. My contention is that CP is the most important of these interfaces, as it is where our model of digital objects (IIIF) meets the content of those objects. it's where it all comes together.
Now build a simple Viewer.