Implement basic filtering annotations (by motivation)

[mejackreed]

Seen in mocks https://xd.adobe.com/view/f2440f29-045b-4d8d-7b61-0d5c8ece8104-8475/screen/f5e9cc3a-11f7-4269-9291-98d48d54cbd8/Annotation-example-2-annotations-page-3r-motivatio

[GroovinChip]

Use cases:

• Annotations are being retrieved from multiple sources. We need to be able to choose which annotation source can be viewed and distinguish them
• There are different categories of data (transcription, translation, geo-spatial, etc) that annotations can contain. We need to be able to label the annotations based on the category and be able to filter annotations by category

[mejackreed]

@GroovinChip For your different categories, are you using motivations to distinguish them? If so, what motivations are you using? If not, how are you distinguishing them?

[GroovinChip]

@mejackreed we are currently using the annotation labels to distinguish data categories, but we could potentially use something else.

[GroovinChip]

@mejackreed see https://rosetest.library.jhu.edu/rosademo/wa/rose/SeldenSupra57/1r/canvas

[ggeisler]

Below are updated mockups for adding annotation filtering.

Filter icon and expand/collapse control

Filter icon: filter_list at https://material.io/resources/icons/?search=filter&icon=filter_list&style=sharp

Expand/collapse control: expand_more at https://material.io/resources/icons/?search=expand&icon=expand_more&style=sharp

• Rotated to point right when closed

Filter section expanded

When the user selects the filter's expand/collapse control, the annotation header section should expand to reveal the filter options:

A: When the filter options panel is in the expanded state, display a 2px solid [primary_color] bottom border immediately below the filter icon and control. This is intended to follow the pattern we use to indicate which sidebar panel is open. When the filter options panel is closed, the border should be removed.

B: Section header "Filter by". Ignore the way it looks in the mockup above and use the Subtitle2 style (to avoid introducing new typographic classes). We could also try the OVERLINE style, which is closer to what I have in the mockup, but I'm worried the OVERLINE font size will be too small for this context.

C: As discussed with @mejackreed "Source" involve complications to be figured out before we can display it, so I'm just including in the mockup to demonstrate how it might fit in with the filter options. But we can ignore it for our first-pass at this.

D: Motivation: This should be a multiple select component so that the user can select more than one motivation to filter by. When open it will look something like:

Based on discussion with @mejackreed my understanding is that the set of available motivations is configurable and he has a good sense of which subset of motivations we might display so I won't list here the specific options to include (though I'm happy to look into it if anyone wants me to).

Filter options selected

When the user makes a selection from the available filter options, several things should immediately happen:

A: Add to the filter icon the same dot indicator we use in the sidebar menu to indicate that there are layers or annotations available. The dot indicator should remain visible, whether the filter panel is expanded or collapsed, as long as there is some filtering criteria active (even if it doesn't actually filter any annotations on a given canvas). In other words, in this context the dot indicator is intended to inform the user that they have a filter active.

B: Follow the pattern of the multiple select component to display the selected menu option, or options, when the motivation menu is in the closed state. (We might have to change the option menu labels to be left-aligned in the panel to fit multiple selections in the closed menu state, but let's see how this ends up looking, especially since choosing multiple options might not be a primary use case).

If the user has annotation highlighting on, the annotations highlighted on the canvas should immediately be updated to reflect the state after the filter is applied. For example, in the mockup above two annotation highlights were removed when the user selected to filter on "Motivation = Describing"

C: Similarly, the annotations count message should be immediately updated to reflect the state when a new filter selection is made. Remove the word "Showing" that we currently have for the annotation count message. This will make more room for the current constraint filter described below. For consistency I think we should remove the "Showing" part of the message in all states, not just when a filter constraint is visible.

D: When the user's filter selection results in one or more annotations being filtered out of the annotations that otherwise would be displayed on the canvas, show a Chip with the onDelete property. I suggest we try the small size chip (which will be smaller than in my mockup) to save vertical space and feel a bit less prominent in the UI.

If the user selects the chip, all filter selections should revert to their defaults, which means no annotations will be filtered; the canvas highlighting and annotation count message should be updated, and the filter indicator dot should be removed.

Navigating canvases with a filter option applied

It seems very likely that a user that goes to the trouble to specify an annotation filter will want to apply that filter to any canvas in the current document (or at least, it seems that will be the case more often than not). So any filter options applied should be retained as the user navigates to other canvases.

Also, if the user has not explicitly closed the options panel using the expand/collapse control, the options panel should remain open, even if the user navigates to another canvas, hides the Annotations sidebar panel, etc.

[mjgiarlo]

I looked at this a bit with @camillevilla and @cbeer but am not inclined to take this on now. In practice, it seems we are having trouble finding real manifests that include annotations with multiple different motivations. Without at least some real test data, I'm not sure I'd consider this issue actionable (and I'm also not inclined to gin up data).

[ColeDCrawford]

I have a test case for this. I have an application which uses manifests from numerous institutions. Researchers annotate these manifests in the application. Some of the resource providers (eg Harvard Art Museums) provide manifests with existing Annotation Lists. These are not useful in my context - the HAM AnnotationLists are all generated from generic AI facial recognition / object detection experiments, for example - and are confusing both for the end user and for researchers doing the annotating.

I want to be able to filter out the provider's Annotation Lists and only show annotations added by researchers on my application. We have an annotation server (CatchPy) which we are using to store annotations. I would be fine providing a whitelist or blacklist of sources, but this issue captures a more general purpose solution.

Another filter which would be useful would be username of the annotator, though that is specific to my annotation server and not generally included in annotation lists.

[ColeDCrawford]

^We ended up excluding oa:commenting from the annotations.filteredMotivations, as all of the annotations we wanted to filter out were using that, while everything we wanted to include was using a different motivation type. It's a little hacky, and only worked because there wasn't any overlap - it'd be much preferable to be able to filter by source rather than a coincidental proxy.