Closed tomcrane closed 1 year ago
From Canadiana:
Further Canadiana comments:
In the bulk canvas modification room, the Heritage Team would like to be able to rearrange canvases too. The Heritage team would like to see 50-100 canvases at once, as long as the screen they are using is large enough.
The bulk labeller might work better as a list interface rather than a grid, by default - gives you a linear view. If it's just a tiny thumbnail and a label then it won't be a very wide list, though. The grid view but with small thumbs would work well too, especially as it's likely the labels edited in this app would be very short strings - page numbers. Roman numerals still won't be all that long.
You could drag canvases around in either mode. You're still editing the Manifest in Vault, it's just that you can do two operations in this app - apply labels to multiple canvases, and change their positions in the manifest's items
array.
For any other activity, you'd switch to the regular editor.
Next steps
Sketch a UI Confirm with Canadiana Confirm with others for wider opinion (eg Ghent)
There are two UIs here:
Scenario overlaps #43 You might want to re-paginate a selection from the bigger manifest as you export it.
Hey @tomcrane from the meeting - Ability to put items in either chronological order or alphabetical order (Heritage reels) has more to do with an eventual collection creator/editor app in our use case. https://github.com/digirati-co-uk/iiif-manifest-editor/issues/132 All of our canvases are set up to have a label that is along the lines of 'Image 1.' But, in our case collection members are ordered by their label or by date usually. So we've had to make sure that this is easy to do.
But bulk re-labeling and repositioning of canvases is definitely a manifest editor feature they would make heavy use out of. In the single manifest context - it would be they noticed a few pages were scanned or indexed in the wrong position. So they would go into the manifest editor for that manifest and re-order the pages in the correct order. Depending on how many indexes away from the correct position the canvases were in, there would need to be a lot of keeping track of correctnig the labels for this shift if they had to do it manually. So ideally, if they grab 5 canvases and move them 100 canvases away, every one of the canvases that shifted position could be re-labeled using the bulk label feature, without them having to go into each affected canvas, one by one.
They would be using this too in the context of the creating many document manifests from a reel manifest. Since they would want to auto-populate the new document manifest canvases with 'Image x' labels. So I'll reference the splitter app issue here: https://github.com/digirati-co-uk/iiif-manifest-editor/issues/43
Hope that helps!
Canadiana Notes:
Where users currently re-order canvases in a manifest, additionally allow them to select multiple canvases to move. Allow users to enter a position to move many canvases using a number input in addition to drag and drop, to prevent having to hold down the mouse and scroll for long periods of time, for very large manifests.
For relabelling – select a continuous run of canvases and the number format (Roman, Arabic), and select the start and finish numbers - then it will update the labels based upon the input.
Digirati Notes on Canadiana Notes
Multi select for dragging, and also contextual:
The latter 2 prompt for a number. You could do this just with one option and ask for a negative number but this might be clearer.
This operation should also accept a format string, so you can label things like "Image 1", "Image 2" or "Page 13", "Page 14" etc. The default format string is just {n}, the incrementing number, but you can edit it (and reset it).
Multiple selection can be a tricky interaction when you have grids of items.
Dropbox UI is worth considering - clicking the large target area of the whole thumbnail selects that image but will deselect any other images, whereas clicking the smaller target area of a checkbox in the corner adds to the current selection.
Google photos doesn't have click-to-select, because a single click makes the image full screen, but it does have the same idea of a smaller target area for building a selection without involving other combinations or key-holding - both are suited to touch UI.
If presented as a list of canvases rather than a grid with larger thumbs, the same behaviour can still apply - you need to click the boxes to add to a selection:
All of these UIs allow non-contiguous selection, but I think that's OK... just needs sensible behaviour.
Does that context menu mentioned earlier also include...
... which launches some additional UI that allows you to select/edit a format string (default {0}), specify styles, specify start value, and (maybe) specify increment.
This is not MVP:
Increment: 2
Format string: "Pages {0} and {1}"
Number style: Arabic
Initial value: 8
... this could be useful!
Increment: 1
Format string: "{0}"
Number style: Roman,
Initial value: "xiv"
Everything looks good here! I like the implementation thoughts, too
We need to determine the relationship between this and #228 - is it the same grid? A different, more complex grid?
(Relating to the bulk modifications using a set of pre-defined rules)
From slack
I was thinking, as an abstract concept, it would be great to have runnable "Scripts" in ME that you could run on a manifest to "do something" - likely generate new IIIF like annotations or ranges but if we bake it in as a global UI element, with a list of scripts that can be run and embed that concept into the minds of users - I think that would be a great addition as custom scripts have a home - and you have a single place to see capabilities like that.
This was for something unrelated, but could be an approach more generally for running one-off tasks on a manifest or canvas. Ideally an action could be a preconfigured "one-click" interaction, or provide a form/UI to the user to configure how the action runs.
It would save us trying to find logical places in the UI for what are essentially buttons.
Split this into
EDIT - this issue has been split into two - this one, and #235. Some of the comments below have been edited to reflect this.