Skip to content

Instantly share code, notes, and snippets.

@tomcrane

tomcrane/iiifml.md

Created January 24, 2017 09:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tomcrane/0f3a0e0c056987f19af9535ed2cc5ee0 to your computer and use it in GitHub Desktop.
Save tomcrane/0f3a0e0c056987f19af9535ed2cc5ee0 to your computer and use it in GitHub Desktop.
Download ZIP
IIIFManifestLayouts, UV and Mirador
Raw
iiifml.md

(trying to clarify my understanding)

iiifManifestLayouts (IIIFML) is a library that does several different things. The package as a whole has both the logic for organising the visibility and position of IIIF resources, and an implementation of this logic on top of OpenSeadragon (OSD). It makes two powerful features available to rich clients like UV and Mirador:

  1. It understands what a IIIF sc:Canvas is, and handles the of rendering it for you. This means that it understands all possible image annotation bodies on a canvas - dctypes:Image, oa:Choice and oa:SpecificResource, with or without IIIF Image services attached. It also makes use of thumbnails on sc:Canvas when present. It provides an API so that a client can generate UI to allow the user to control the visibility of all the available image resources - e.g. layers of multispectral views, foldouts, use of parts of other images not just the whole. Is is a realisation of what I was scrabbling to find in this gist. An example of how it renders oa:Choice is in this video. UV and Mirador work with dctypes:Image and expect to find an image service, which is what most canvases have; IIIFML supports all canvases.
  2. It has a layout engine that understands the Presentation API and its viewing hints. A much more sophisticated version of something like Masonry. You give it some settings and a space to lay out canvases, and it will flow them, group them correctly for recto and verso alignment, order them and so on. OSD already has collection mode - iiifManifestLayouts takes that idea and runs a long way with it, and does it for canvases not low level tileSources. Again, the repo as a whole contains both the logic to perform the layout, and an implementation of this logic in OSD.

Crucially, it does both of these features together, on the same layout surface. This means you don't have to separate out the overview, thumbnail navigation around a manifest from the view of an individual canvas, or 2-up views of pages. You just zoom out for the layout view, and zoom in to see the individual canvases, as far as the underlying tilesource permits. Navigation around a manifest and viewing of canvases within a manifest are part of the same UI component.

UV and Mirador currently separate the navigation around the object via thumbnails into separate components, in their own panels - the UV's thumbnail panel and gallery component, Mirador's thumbnail strip in Image view, or its gallery view; a user action triggers a selection, which loads a different object into the main deep zoom view.

So if Mirador or UV adopt IIIFML - what does that actually mean?

  • Do they retain their current navigation components, and use IIIFML instead of vanilla OSD in their main viewing component - which gives them feature 1.
  • Or do they also use IIIFML in the thumbnail strips, galleries etc - which gives some of feature 2, for canvases directly?
  • Or do they adopt new modes of navigation that realise the full potential of IIIFML and provide 1 and 2 together?

These options all have very different implications for integration work, and potentially radical changes to the user experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment