Merging two Manifests

[tomcrane]

Canadiana described it:

Merging together two different manifests that are actually the same item.

But it is perhaps also the "reconstruction of correspondence" and similar use cases:

This is a use case that could be met from two different directions using other apps.
You could start with the sorting room, extract one set of canvases, then switch to the regular Manifest Editor, and import other canvases.

Or you could do the whole thing from the ME, just browsing and selecting (e.g., multi-canvas select in https://tomcrane.github.io/scratch/contentstate/cs.html).

But there is probably a better, dedicated app for the scenario where you want to make a new Manifest out of 2 (and only two) existing ones. Or perhaps, a few. You could imagine, in the UI above, having 3 columns, or even 4 (that you can control the position of) and dragging into the central list, without opening any dialogs (certainly not modal dialogs).

The central one doesn't have to look like that, can be a lot simpler in this view, where you're more focussed on selection and ordering.

Source canvases are still visible in the lists, but the app knows which ones have been moved into the centre, so it can mark them differently.

Only the centre can be re-ordered because that's the actual manifest being edited. The others are selection sources.

[tomcrane]

This is also a Manifest Editor, but without all the complex RHS editors - it's only for canvas ordering and maybe a bit of labelling.

[tomcrane]

From Canadiana:

[tomcrane]

Additional feedback from Canadiana:

When merging two manifests, the Heritage Team would like to be able to see large numbers of canvases, for example 50-100 as long as the screen that they're using is large enough. They want to be able to multi-select batches of canvases from either manifest for merging.

Implementation thoughts

Can a single Sorting Room app serve the merge use case (as here) and the "break up into smaller parts" use case, as in the old Sorting Room (see #43)?

Perhaps. Thinking about existing components, you could have more than one thumbnail strip and/or more than one grid view (which, with the thumbnails set small, can show 100s of thumbs at once on a large monitor).

One (and only one) of these is always the target; the Manifest being created/edited.
One or more of the others are the source, or sources. You select canvases (singly or multiply) in sources and "Add to Manifest" from a context menu on the selection; you can also drag them singly or in multiple selection.

The design needs to be careful and not confuse source and targets.

This is a separate app, not the standard Manifest Editor, because we don't want to mix the two activities.
There's no outline view or RHS contextual panel in this app, it's just for assembling and sorting, creating a new Manifest from existing canvases. You can always toggle apps though - even halfway through creation.

But we don't try to accommodate multiple source panels in a UI that also includes outline or RHS detail components.

[tomcrane]

Canadiana Notes:

1. 2Pane app to facilitate Merging Manifests

Staff envisioned a workflow like:

a) From the app menu, open the 2Pane app

b) A view appears with two panes. The left being the ‘Source Manifest’ and the right being the manifest currently open (or a blank manifest, if the user hasn’t opened a manifest.) The manifest on the right will be called the ‘destination manifest’ in the following steps.

c) The user can open a source manifest from a menu bar on the source manifest pane.

a. This lets the user choose a new source manifest, too.

b. When a user opens a source manifest, the canvases in the source manifest are drawn in the left pane.

d) Users can select multiple canvases from the source manifest and drag them to the destination manifest. This copies the canvases to the destination manifest. The canvases that have been copied are highlighted on both panes.

e) The user can re-order the canvases in the right pane.

f) The user can press save to save the changes/blank manifest.

(The user can flip back to the editor and see all the new canvases added to destination manifest. They can flip back to the 2Pane app and choose another Source manifest to add canvases from, too.

[tomcrane]

Digirati Notes on Canadiana Notes

Can it be a n-Pane app? That is, can you open more than one source pane?

We can elaborate this and see how it fits with the idea of "pool" or "tray" UIs - working scrapbook of content, which is another source.
The difference being that a source pane is read-only, it represents an external manifest of other source of content, it is not the thing-being-edited. It's like the view in https://tomcrane.github.io/scratch/contentstate/cs.html (currently broken :( ) where it's just a selection source. In fact it may be reusing the same UI components.

The source are in vault, but they aren't modifiable because they are not the thing-being-edited... until you bring a canvas into your resource (it will be copied).

A tray, rather than a source, might be modelled as another manifest, or just as an array of assets, but it is modifiable - you can add and remove assets.

[tomcrane]

If the panes are in the same browser window they have access to the same vault.
Can drag a canvas, of copy/paste.

(we should use the same multiple-select mechanisms as #134)

Later we can have cross-window drag and copy/paste, where the clipboard contains a content state.

[RussellMcOrmond]

Can it be a n-Pane app? That is, can you open more than one source pane?

We were thinking 2 primarily for visual and usability reasons.

Are you thinking of browser tabs that can drag-drop between each other, where the number of panes aren't taking up screen real-estate on the same tab as the thing-being-edited?

I will be interesting to hear more about the "tray" idea you are suggesting.

We will also want to discuss an MVP, as it would be ideal if we could adopt early and follow (and participate in) ongoing process.

[brittnylapierre]

Alternatively to the initial UI suggestion we submitted - can we ask for the ability to drag and drop into a manifest open in the manifest editor, from universal viewer or another tab/window of the manifest editor?

Ex: http://zimeon.github.io/iiif-dragndrop/

If it is possible, our staff will likely use our access platform or our inventory app to open up the source manifest in universal viewer or the manifest editor, and then select multiple canvases, and drag them to the destination manifest, open in another window of the editor.

If that is not possible - I think it could be to a n-pane app to make it more flexible and suit potentially different kinds of workflows.

For us, the staff said they would like to have one manifest open as the source manifest on one side at a time (read only) where they can drag items to the destination manifest (the manifest open in the editor.) Then they could use a menu to open another source manifest from the n-pane app, which would replace the one they currently have open.

They saw it as working from one source manifest at a time to not overwhelm them. But, if every source pane has this menu, I don’t see how adding the ability to have multiple source panes open at once would be a negative! Some people may work with source smaller manifests and find this helpful.

[tomcrane]

Summary

Have you seen the IIIF Content State specification?
https://iiif.io/api/content-state/1.0/
That specification standardises what is being passed around, and also provide some mechanisms for doing so (including drag and drop).

With this, any source that can put a content state on the clipboard can then be pasted into the Manifest Editor.
The Manifest Editor already has some experimental support for this.

So perhaps the MVP is:

• Ability to open one or more source panes within the standard manifest editor, from which you can drag and drop, or and copy/paste (with menu/keyboard support) into the existing canvas grid/list view(s).
• Ability to accept a paste from any source if a content state is on the clipboard.
• Ability to open source panes as new browser windows - this gives you much more control over your working environment.

The Manifest editor remains the same but can accept pastes from both internal panels and external windows. The source pane is a read only environment, it doesn't need to share vault state or update anything itself. Allowing a source pane to be an external window allows you to do this...

For us, the staff said they would like to have one manifest open as the source manifest on one side at a time (read only) where they can drag items to the destination manifest (the manifest open in the editor.) Then they could use a menu to open another source manifest from the n-pane app, which would replace the one they currently have open.

...with more flexibility over arranging your workspace, alt-tabbing between larger views etc.

[RussellMcOrmond]

This "MVP" idea sounds pretty complete to me. 😆

I didn't know the state of "state". That also seems to be a more generic solution that will be usable in many more scenarios.

The ability to multi-select for a "copy" to the clipboard, and then paste into "the right position" in the editor sounds great.

The ability to "cut" from a multi-selected part of the manifest/collection being edited and "paste" into another to change the order seems to solve that editor need as well.

[tomcrane]

What's the role of the IIIF Explorer, #111 in this?

Is the "source pane" in #133 (comment) an instance of the IIIF Browser component? Which both allows navigating to and then picking from a manifest.

The "MVP" in that comment is pretty maxi, as Russell points out. What's the real minimum?

The manifest-being-assembled is represented in the base grid component #228