Presentation Creation Stories

[sdellis]

As a Presentation Creator I want to add, delete, and rearrange (probably drag-n-drop in "thumbnail grid" view) canvases within a sequence So that I can create basic manifests

As a Presentation Creator I want to select an image resource from any number of pre-configured IIIF-friendly servers and apply it to a canvas So I can add custom content to a Presentation

As a Presentation Creator I want to add/edit/delete ad-hoc content to a blank canvas with basic layout tools (markdown, resource-to-segment associations, embedded content) So I can add copyright statement insertions, blank/missing page statements, create custom content, and possibly even ePub import/export.

As a Presentation Creator I want to group and label ranges within a sequence So I can add logical structure/navigation and table of contents

As a Presentation Creator I want to set attributes such as a "start" page, viewer direction, and other configuration options So presentations are displayed properly in a viewer

[aeschylus]

Thank you for this contribution. In the outline, does "presentation" refer to a general "presentation", such as a "Power Point" presentation or "Prezi" presentation, or does the word refer to authoring IIIF Presentation API-compliant manifests with MIrador?

The requirements seem to be able to go both ways.

[sdellis]

Yes, sorry for any confusion. I was referring to the authoring of Presentation API-compliant manifests with Mirador. However, my understanding is that Presentations could represent "Slideshows" as well as "book-like" objects, so I imagine one would be able to create a "slideshow" manifest using the same basic toolset.

To add some context to this issue, I was encouraged to add "Presentation/Manifest Authoring" use cases to the m2 issues list. Since there is no current manifest authoring tool, and it makes sense to me to have some kind of author/edit functionality in Mirador, I think it's probably better to put them here. If they are deemed to be out of scope for the Mirador project, then someone can move them over to the IIIF User Stories repo.

[aeschylus]

We are collecting stories like this for collaboration on the project once the codebase is core is released in January, so this is a great place for now.

I'd love to hear from @azaroth42 and @mattmcgrattan about this one. Perhaps the interface aspect of the Bodleian work could be abbreviated by creating a custom workspace type for editing in Mirador. It may be easier for users to be able to fully interact with and view the manifests they create in the same environment in which they already do so. The tricky part would be mapping the elements representing manifest objects and structure in such a way that their visual manipulation is reflected in the updated manifest and saved to some server.

This would inevitably help strengthen, clean, and modularise our exposure of the manifest data with an eye toward extracting an easy-to-use wrapper for application developers, as well as help hone the discussion around a full REST API for IIIF, including the proposed dynamic annotation lists.

Thoughts?

[blalbrit]

@cubap has played around in this space too - would be great to have him in on the conversation. They have a manifest manipulator that could be explored further for use-cases and or comments.

[azaroth42]

I think there's two reasonably distinct workflows:

1. Create, update and manage a manifest (plus sequence, ranges, images, etc) which is what Oxford will be working on (as far as I know)
2. Create, update and manage transcription annotations, which subdivides into: 2.1. Create bounding areas around text to be transcribed 2.2. Transcribe the text Which is what TPEN have been working on.

Then there is the ability to sensibly render the transcribed text, which might (IMO should) be a very different rendering to comment style annotations.

[blalbrit]

T-PEN has a manifest arranger - which is what I was referring to. It allows you to modify an existing sequence so - while not a full manifest editor - it allows you to reorder and save a sequence. Worth looking at when you have time.

[cubap]

There are a few things we currently have and several in the pipeline that address the first three cases completely within T-PEN. The fourth is addressed (in a perhaps unexpected way) in Tradamus, launching in June. The last is outside of any work we've scoped, but will be accommodated in our tools as the standards coalesce.

In T-PEN right now, there is an option for projects that allows you to create "virtual manuscripts" by loading images from various repositories and reordering, removing, or renaming them. At that point you can export your project as JSON-LD (for example) and it will be a IIIF Manifest. This feature is not modular right now - that is, you cannot bring some remote Manifest in and rearrange it, nor can you easily pick up the code for the interface and use it in your own project. Our current work for the Newberry will (summer-ish) extend this to be more

1. Modular - the code for the interface will be liftable for simple reuse and support rearranging Manifests from non-T-PEN locations
2. Descriptive - in addition to Canvas labels, users will be able to attach or modify other relevant metadata
3. Expandable - bring in additional images from any resource and generate new Canvases to contain them
4. Selectoriffic (reach goal) - instead of defaulting to the natural ratio of the painted image, the annotated image may be partially applied to the Canvas

As far as I know, there is no plan to build in complex Zoning or Choice for images or the grouping of Canvases with alternative labels, though nothing in the standard prevents that from being done elsewhere. Our planned interface for the Newberry (and the T-PEN 3.0 that follows) will be able to display Zones and Choices, though it will not generate them. Tradamus (landing in June) is a digital publication suite of tools that enables the creation of digital editions and publications which address the latter concern by considering a tr:Edition as an ordered collection of tr:Outlines/sc:Manifests, though I am sure that somewhere the standard may allow for several named ranges to be applied.

All that said, we are an open shop and have realigned many of our internal efforts to make our tools easier to reapply, reuse, and extend for myriad purposes. If you have any specific needs or would like to collaborate on any specific feature development, we will happily share code and include any interested party in our designs, especially as we seek to make our services and underlying code available to anyone for whom it is useful. Our unpublished plans include a few very specific IIIF and annotation services that will only be successful if we can amass enough cases to make it relevant.

[sdellis]

@aeschylus said "The tricky part would be mapping the elements representing manifest objects and structure in such a way that their visual manipulation is reflected in the updated manifest and saved to some server."

Isn't that what single-page app frameworks get you? Most have an ActiveRecord-like ORM layer that sync the client-side objects with the server via a REST API. Angular has the ngResource module, but there's also the more agnostic Breeze.js library. Do you envision Mirador having some kind of dependency management (Require.js?) for libraries and modules necessary for different "builds" (i.e., Vanilla BookReader, Manifest Editor Tools, Transcription Editor, Comparison Workbench, etc.)? It seems that would be a good way to distribute the work, as well as the software. Some folks may not need everything and the kitchen sink.

I agree with @azaroth42 that the display of transcription and translation annotations would be handled differently than comment-style annotations (line-by-line overlay vs. adjacent-list). Would a "transcription" annotation use the sc:painting oa:Motivation to distinguish it from the comment-style annotations? How will the T-Pen transcription tools/interfaces integrate with other viewers -- through an Annotator.js plugin?

Finally (and apologies for the length here), @azaroth42 , I believe there is a bit of crossover with those two scenarios you outlined, right? It seems to me that there are annotations that get saved as part of the manifest ("institutionally-sanctioned and curated"), and annotations that are not saved as part of the manifest ("third-party transcriptions/translations/commentary"). Otherwise, how does a scholar at Yale annotate an object at Stanford? Are both parties (Oxford and T-Pen) apps editing manifests, or is T-Pen simply saving annotations in a separate backend store?

[azaroth42]

I suggest that Mirador is not the right repo for this issue. Move to IIIF/iiif.io ?

[blalbrit]

+1

[aeschylus]

At this level of abstraction, I think it makes sense to move it. It's true that Mirador is an authoring environment in the sense that one can create annotations, however, functionality like searching all images within a large collection of servers as possible contents for a placeholder canvas has never really been discussed until this issue. I agree with Rob that sussing out which things are in scope for Mirador, and which things may not be, would fit better under iiif.io.

As far as frameworks and syncing go, we have been trying to keep Mirador as entirely "front-end only" as possible. There is no API for editing manifests on a server in the way there is for retrieving image regions, annotations, and manifests, so that would need to be figured out or at least begun first. Most web frameworks assume one backend. Mirador has n backends. There are a few reasons we chose not to begin Mirador using a framework, although someday a flexible enough framework may come along, and it could be ported over if the sustainability is there.

[sdellis]

I'm glad that this is being discussed again. I'm in a good position to help contribute since many previous obligations have begun to clear up.

I don't know if it will be of any use to anyone else, but I created a super-simple Presentation Server that I have been using for local development CRUD stuff. I wanted to get authentication working before releasing it to the wild and making it a public API. Anyway, I'd love to get some feedback on it if anyone has a few minutes to give it a go.

It's hot off the press, so I've only had a chance to do basic experiments against it in my off hours. Once you have it running and drop a multi-image manifest in, you can play with a drag-drop "page" order fiddle I made using the jQuery UI Widget factory. The manifest manipulation is done on the client and the full (edited) monty is PUT back to the server (probably won't scale, but just tinkering). I also started to play with a Backbone/Marionette app for constructing/editing manifests (not quite ready to share, but soon). @aeschylus , my assumption was that there may be n backends for GET, but only one backend for POST/PUT/DELETE requests for a single manifest. Annotations are another story.

Finally, @azaroth42, @jpstroop pointed me to what seems like a similar project you've worked on. It looks like it will allow for requests to be made to portions of manifests and would be more scalable than my simple server. Unfortunately, I ran into a few issues spinning it up... probably my own naivety with Python. Will give it another go soon.

[azaroth42]

IIIF/presentation-api is just a library along the same lines as osullivan, there's no server implementation just a parsing/object mapping set of code.