View Mode Switching Issues

[Rosie Le Faive]

Last December, I pushed a change to the starter site that made it use a different mechanism to select “alternate viewers”. It is posing a problem and we need to revisit it. I would like to ask the community for input, but first I want to lay out the problem.

Problem Analysis: Alternate Viewer Modes

Different files need different viewers. For some files (e.g. video, audio), the file extension/mime type correspond to the category (Video, Audio) that matches a Media Type provided by Drupal. Thus, we configure those Media Types to display with the appropriate viewer, and all is good. There are two desires/edge cases. The first is, for example, PDFs, which have no dedicated media type and so get put in File or Document. But the desire is for all PDFs to be displayed with PDFjs. The second edge use case is a desire to choose, on an object-by-object basis, what viewer is used. For example, you only want certain selected images to use OpenSeadragon.

Media Types

Drupal out of the box provides the following Media Types:

• Image

• Video

• Audio

• File

• Document

• Remote Video

AFAIK these are installed by Drupal’s “Standard Install Profile,” and we use them as they come (with a few alterations like adding the media_of field). Like Islandora, Drupal does NOT stop you from making your own types, and offers you no advantage (eg. extra support) for using only the built-ins.

Islandora Viewers don’t correspond to those media types

But we decided to force our files and viewers into those media types anyway. Islandora has a viewer or two for large images, but due to technical restrictions of the Image media type, we’re in the habit of putting these in the File media type. Similarly, we have PDFs, which (based on more decisions made in Islandora Defaults) are aligned with the File or Document media types.

The Old(er, maybe better) Solution

The original Islandora Defaults solution was to put a drop-down on the node, and through a Rube Goldberg machine of contexts and view modes, the Service- or Original file would be displayed to the user appropriately. I still hold that this is very opaque and hard to understand and troubleshoot.

The New(er) problematic Solution

But my solution, where the view mode override is on the media, is hard to use in practice. For adding individual objects manually, it works fine. But mostly we ingest large batches of content.  And here we’re stymied. Workbench does not support the adding of additional fields on Media. And, to boot, we need to set the view mode override on the Service File, and if that service file is created by a derivative, we have no way of telling it, in advance, what view mode override to have. 

So, what to do?

• We could leave things as-is, and let you set the media view mode switcher in bulk actions, post-facto (the status quo)

• We could look into tokens, or other methods of referring to something on the parent node to drive a view mode switcher.

• We could look into passing “extra field information” to derivatives. This would occur during ingest (i.e. before the derivatives are created) but end up on the derivative (e.g. service file). (this would require modifying code that probably shouldn’t be modified for this purpose). 

• We could revert to the View Mode via View Modes setup as it was before December 2022. 

• We could create new Media Types for PDFs and for Large Images, which would let them have happy default viewers, solving the first (mimetype-based) use case.
  
• We could leave the second (object-by-object) use case to be implemented by the adopter, with examples for how it could be implemented.
  

We discussed this a little during today's tech call, but this would be a large change so I'm bringing it to the community.

[Mark Jordan]

You're correct, Workbench doesn't support adding extra fields to media entities, but resolving that is what I am currently spending my "new feature" time on.

Note that this clarification is not an endorsement of a specific option you provide below, but if I may offer my opinion, figuring out which viewer to use is one of the most complicated things site admins need to do in Islandora. For instance, how does the node-level "Display hints" field relate to all of this?

Mark

---

From: isla...@googlegroups.com <isla...@googlegroups.com> on behalf of Rosie Le Faive <lef...@gmail.com>
Sent: Wednesday, March 8, 2023 11:24 AM
To: islandora
Subject: [islandora] View Mode Switching Issues

 

--
Learn more about Islandora in general at islandora.ca and join the community at https://github.com/Islandora/islandora-community/wiki
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/feb71576-44e4-452a-a808-03797aaaf899n%40googlegroups.com.

[Rosie Le Faive]

The node-level "Display hints" field is exactly the point in question.

I removed it from the Starter Site in December, and it looks like we'll be adding it back. However, Nat has prototyped a method that is a bit simpler, doesn't use EVAs and so skips the cluttering of (node) View Modes.

[iProtion HM]

1. Instead of EVAs, you may use the (views) Block to display media viewer (Open Seasragon, PDFjs, ...)

2. Then adding the Display Hint field back.

3. Then use Context (Display) to control how the media to be displayed based on Model and Display Hint.

In the Context, use Blocks reaction to add the (views) Block in Step 1.

With this way, we also get rids of (node) view modes ofc. And Workbench doesn't need to be updated to support your new extra field in media entities. And the (obecj-by-object) case is also solved. 

Simon.

[Simon HM]

The downside of switching EVAs to Blocks: 

- With EVAs, we easily control the order of media viewer between other metadata fields in (nodes) View Modes display.

- With Blocks, we are only able to assign the "media viewer" block into theme regions (Pre-content, content, sub-content, ....)

Well, but that's all we need. I don't think there is a case we want to display the media viewer in the middle of other metadata fields.

Simon.

[Mark Jordan]

Thanks for reminding me about removal of Display Hints Rosie, I didn't catch that.

iProtion we'll be adding the ability to populate fields on Media using Workbench anyway since eventually someone will want to do it for some other reason.

Mark

---

From: isla...@googlegroups.com <isla...@googlegroups.com> on behalf of iProtion HM <master....@gmail.com>
Sent: Thursday, March 9, 2023 7:54 AM
To: islandora
Subject: Re: [islandora] View Mode Switching Issues

 

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/c353249c-4939-4b9a-bf12-2f09f562855bn%40googlegroups.com.

[natk...@gmail.com]

Simon HM solution proposed above has been adopted here: https://github.com/Islandora-Devops/islandora-starter-site/pull/71.  It uses context with Display Hints (now called Viewer Override) field to set the viewer via context.  It a value for Viewer Override is not set, it will default to a viewer for that media type.

No need to maintain view modes with all the fields to switch media viewers. It gives us the ability to set the viewer at the node level.  Was straightforward to implement.  Additional details in the PR.