Choice in Mirador 3 does not display as expected and breaks from previous Mirador versions

[kirschbombe]

Where a manifest uses Choice, M3 currently defaults to displaying all images in a choice stack at once (all are "on") and they are displayed in reverse order from what is expected. For a user, this means that in order to see a specific image in the stack, they must first turn off all of the layers to see the desired image. As well, the first image that appears in the manifest is at the top of the stack, meaning when this image is displayed and a user chooses to display another image, the original/first image must be turned off. The user interaction here should be additive, not subtractive.

The desired behavior would be to revert to how M2 handled choice:

• Only the first painting annotation in a choice stack is enabled on load (this is inline with the spec)
• The presentation of images is upwards in a z-index from the first painting annotation encountered (this is necessary so that as new images are selected, they are visible without having to deselect the first image.

The current behavior breaks the functionality of choice manifests created following the IIIF Presentation spec (2 or 3) and used earlier with M2. Also, the layering of images from the top down mean that selected images are not shown.

You can see this using the cookbook recipe: https://projectmirador.org/embed/?iiif-content=https://iiif.io/api/cookbook/recipe/0033-choice/manifest.json

My particular use case is manuscripts with MSI. Each manuscript folio has 12-25 multi-spectral images in a given choice stack, so a user having to uncheck each layer and reordering them to be able to view a specific image is not a good user-experience.

This relates to another issue (https://github.com/ProjectMirador/mirador/issues/3585) that points out that the current M3 method results in many unnecessary image requests.

This is a major blocker for migrating from M2 to M3 since existing manifests do not work as expected.

Some examples:

• Sinai Palimpsests Project: https://sinai.library.ucla.edu | https://sinai-images.library.ucla.edu/iiif/ark:%2F21198%2Fz1kd1z25/manifest (this requires a login to view the images)
• https://prtd.app/#72f604db-6869-4c08-91ce-7c79502a7f35 | https://dvp.prtd.app/hamilton/manifest.json

This current M3 behavior also affects viewing when there are multiple resources layered on a canvas (without choice). Take for example the reconstruction of a manuscript folio: https://iiif.io/api/cookbook/recipe/0036-composition-from-multiple-images/. In this case, it does make sense to load all resources when the manifest is loaded into the viewer, but the order in which the resources are displayed is top to bottom, instead of bottom to top, meaning the subsequent resources are buried under the first resource and the user cannot view the "scene" as intended.

[kirschbombe]

Following up on some of the Mirador meeting questions:

From the Presi 3 spec: Choice is not explicitly covered in v3, but there is the statement “Clients should process the Annotation Pages and their items in the order given in the Canvas.” https://iiif.io/api/presentation/3.0/#55-annotation-page

This above is vague, however Presi 2 is a bit more explicit in that it defines Choice as having only one default resource: "This can be accomplished by having a “oa:Choice” object as the resource, which then refers to the options to select from. It must have one default and at least one further item to choose from... This is described in the Multiplicity section of the Open Annotation specification." https://iiif.io/api/presentation/2.0/#choice-of-alternative-resources.

Choice is defined in Open/Web Annotation as "an ordered list of resources from which an application should select only one to process or display." So, if we are following the spec, then Mirador should only request a single resource when choice is used, leaving the other options for a user to choose.

If the default is then changed to load a single resource rather than all of the choice resources at once, it seems that we would want the first image at the bottom of the stack so that any additional resources that might be selected are visible (on top of the first resource) when chosen.

Following this, the default for multiple painting annotations on a canvas would be to load all resources; the default for choice should be to only load the first resource.

I think we can make this more clear in Presi 3, but it seems clear in Web Annotation.

[tomcrane]

To support @kirschbombe's points above - I think there are clear default viewer/client presentations for these two different use cases:

1. multiple painting annotations with image bodies on a canvas - a digital collage, for example
2. a painting annotation with a Choice body - a multispectral stack, for example

A layers-style UI is a useful value-add for Choice, but both have a necessary default presentation.

For 1. that means paint everything onto the Canvas. For 2. it means paint the first Choice item and offer UI for the user to select the others.

A client has no idea in case 1 what the multiple painting annotations represent, and whether not simply painting them all would be an inappropriate, misleading or partial representation of the publisher's intent. So the order is important - M3 is correct to paint them all but then produces the wrong result by ordering.

In Case 2, the simple scenario assumes that the choice is between the different items in the Choice, so the simplest implementation only shows one of them at any one time, making stacking order irrelevant. However Mirador's layers UI is a hugely useful addition, evidently so for multispectral images, allowing the user to blend the different choices. In which case it should stack as per spec.

Offering a layers UI for case 1 may sometimes be useful (it allows you to see the "hole" in the Châteauroux example) but may sometimes be misleading, as it violates the publisher's intent.

[cbeer]

Thanks @tomcrane; I think ordering is the source of my confusion, at least. On the Mirador call and previously, I think we've asked for additional direction or specification for this proposed behavior. The cookbook recipes seem to agree on an explicit preference, e.g.:

The presentation of images is upwards in a z-index from the first painting annotation encountered for all subsequent painting annotations.

However, I'm not sure where this certainty is coming from. The presentation API barely mentioned the user of choice, and the only mention of ordered behavior for Choice I can find in specification is in the Web Annotation Data Model:

The order is given from the most preferable to least preferable, according to the Annotation's creator or publisher.

Is there something I'm missing?

[kirschbombe]

Hi, @cbeer. I think we acknowledged a year ago that the spec is fuzzy on the bottom-up ordering and that we need to make that more clear in the next Presi 3 update. Putting this aside, it seems like we might agree that displaying all images from a choice stack is not the intended behavior when choice is present and that this behavior does not follow the spec.

I'd like to move the conversation forward to focus on what the next steps might be to:

1. update Mirador to only display the first image of choice Canvas
2. discuss how best to evaluate/make a decision on the bottom-up/top-down issue

I can attend the next Mirador meeting if it will be useful, but I am open to other suggestions on how to continue the conversation.