What are we doing here?
Combo of text from the Google doc and text from the process recipe/index.md
https://docs.google.com/document/d/1DEwDTU_PGV_1mXYJlAOtADxwfnqfov2gRO7NbMfl0t8/edit https://preview.iiif.io/cookbook/master/recipe/
List https://preview.iiif.io/cookbook/master/recipe/all.html
The GitHub cookbook repo https://github.com/IIIF/cookbook-recipes
The list of issues https://github.com/IIIF/cookbook-recipes/issues
The process
- create an issue on GitHub
- discuss the issue there
IIIF/cookbook-recipes#33 IIIF/cookbook-recipes#34
- are these really just one issue? [TODO] - add some of the discussion below
Turn images on and off foldouts
Are there one or two issues here? Is there a difference between these two? Consider IIIF/cookbook-recipes#35 Look at the issues already on GitHub
Use case - I need to give the user the ability to toggle images for the same view https://wellcomelibrary.org/item/b19684538
Mirador blend layers etc UX decision, not a model decision. Could be any UI and still do the correct thing. Can get as fancy as you like but must be consistent with model
Discuss with reference to examples - Multispectral layers etc etc
Discuss the issue a little bit on GitHub
What is the essence here? It's Choice https://www.youtube.com/watch?v=4AJPVktQ1Zw video of Choice
Is there one or two issues? Multispectral and Flap are actually the same issue? (get the right name for the issues from GitHub)
NB - you don't need to be able to do this step. Clear description of use cases doesn't require building the site. If you're working in groups you don't all need to do what I'm about to do - someone could be working in a Ggl doc for example.
clone the repo master bundle install bundle exec jekyll serve
OK we're ready to implement our issue as Choice
Look at Presentation 2.1 Manuscript: https://github.com/tomcrane/scratch/blob/gh-pages/manifests/foldout-as-choice.json#L112 https://wellcomelibrary.org/item/b19684538 - Pseudo-Albert
https://www.youtube.com/watch?v=4AJPVktQ1Zw
John Dee: https://resources.digirati.com/iiif/an-introduction-to-iiif/dee-sbs.html
Look at the W3C spec https://www.w3.org/TR/annotation-model/#choice-between-bodies
Look at the template recipe
DISCUSS - is this template right? Maybe we'll find out over the course of the next few days.
- Write the issue text
- set the scene
- define the use case
Talk about modelling vs UI again That the recipe is a modelling recipe (but by all means discuss UI in the comments) To what extent does the recipe dictate UI?
Create our container manifest
Put the resources somewhere - two images. (can we ask Glen to get them on AWS? demonstrate this part of the process) Upload the hi-res John Dee images to IIIF Fixtures...
No Image services for now, keep it simple.
OK, write the annotation JSON Get it working nicely
Multispectral example is a painting See it working in Mirador (can we?)
Make sure we have the frontmatter
Process says to reference other recipes. What other recipe is relevant? Other recipe that also features multiple images on a canvas...
IIIF/cookbook-recipes#36 UI considerations The images are all part of the scene. The default behaviour is still valid. This doesn't mean that content control UI isn't useful But it's not as obviously required.
With Choice the clue is in the name. There is a choice of images. That means a human choice. So you need U to allow humans to exercise that choice.
(pull out an example of a Canvas that has multiple images on it, that are not Choice) (something like Fire) - https://tomcrane.github.io/fire/
Scene composition.
With multiple images on a Canvas, the model is saying that all this content belongs on the Canvas. It is opinionated about order (pull out the bit of P3 that mentions order)
Layers are like z-index in CSS
So it still might be useful to offer users the ability to turn things on and off But it's a different kind of interaction.
Modelling issues...
Imagine the Durham example implemented not as two shots but as an additional image on the canvas. Just the flap. Would that also be Choice?
In practice this would be harder to do because of photographic technique, lack of transparency in JPEGs or image services etc.
But is it a valid approach?
So discuss this in the GitHub issues too.
We'd like to go straight into the recipe for multiple images...
But, before we do this! We need to get this issue off of the starting blocks first.
One Pull Request per issue... but you are allowed to include edits to other recipes in the PR if they are references to your issue... (any other scenarios where your PR can have other recipe edits in it? Maybe, discuss)
You need to be a member of the iiif-recipes team to create and push to a new branch in the recipes repo. You can do your work in a fork, in a different repo, but the advantage of pushing to a cookbook repo branch is that your PR will have a preview site built for it, so you can share and discuss the work in progress.
You should include a link to the preview branch in the PR for convenience.
Write up the use case for multiple images This is actually a less specialised example than Choice because it doesn't go somewhere else in W3C spec.
Now make this recipe
The Chateauroux demo: https://demos.biblissima.fr/chateauroux/demo/ https://demos.biblissima.fr/chateauroux/osd-demo/
The Manifest: https://iiif.biblissima.fr/chateauroux/B360446201_MS0005/manifest.json
Search for B360446201_MS0005_0038
- the first canvas with two images
- look at this canvas
...
We have a problem in that we have refs in two different PRs but we may have to wait until one is merged before our final edits. Hopefully this doesn't happen too often.
Now we have two recipes on the go...
Suggestion... recipe maker's Slack channel? Cookery Channel?