samvera-labs / nectar-iiif Goto Github PK

Description

Support level 0 according to IIIF image API specification

Done looks like

• Thumbnail supports level 0 images
• Tests in place for thumbnail

• Create <SeeAlso/> component in vane of <Homepage/>

Description

Let's double check the TypeScript types are being exported as part of the bundle?

Description

After a Lighthouse audit in [Digital Collections}(), image optimization was a frequently suggested solution. Perhaps it'd be worth investigating srcSet, responsive images for what Nectar delivers? Assuming images are being served from a IIIF image service, would it be as simple as requesting various dimensions at the image's scale?

https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

Done looks like

• Is this do-able, and/or worth the effort?

Description

From Lighthouse reports, it's complaining about some missing alt tags...

Done looks like

• All images verified to have alt attributes

Inspired by https://github.com/nulib/repodev_planning_and_docs/issues/3321

Allow multi-value metadata text to be displayed vertically or horizontally. Current horizontal values might be a little hard to read...

Description

Docs for nectar should be as clean as possible, so maybe we should use markdoc to help polish them out.

• Docs are using MarkDoc

Problem:

Say you have a metadata property resembling:

[
  {
    label: { none: [ "Genre" ]},
    value: { none: [ "paintings (visual works)" ]}
  },
  {
    label: { none: [ "Record" ]},
    value: { none: [ "00001234" ]}
  },
  {
    label: { none: [ "Subject" ]},
    value: { none: [ "Buddhist art" ]}
  }
]

A consuming application using Next.js wants to create a custom patterns wrapping the rendered value for specific labels, Subject, and Genre so that those values are rendered within a next/link <Link> component.

Potential solution?

This pattern would target matching labels and render their value as they are entered as the children of the <MetadataPattern>. It would allow for a React component to be rendered within <MetadataPattern> including <Link>.

import { Metadata, MetadataPattern, MetadataValue } from "@samvera/nectar-iiif";
import Link from "next/link";

const WorkMetadata = ({ manifest }) => {
  return (
    <>
      <Metadata metadata={manifest.metadata}>
        <MetadataPattern label={{ none: ["Genre"] }}>
          <Link href={`https://next.site/search?genre=${MetadataValue}`}>
            <a>{MetadataValue}</a>
          </Link>
        </MetadataPattern>
        <MetadataPattern label={{ none: ["Subject"] }}>
          <Link href={`https://next.site/search?subject=${MetadataValue}`}>
            <a>{MetadataValue}</a>
          </Link>
        </MetadataPattern>
      </Metadata>
    </>
  );
};

OR?

import Link from "next/link";
import { Metadata } from "@samvera/nectar-iiif";

const WorkMetadata = ({ manifest }) => {
  const customValueContent = [
    {
      matchingLabel: { none: ["Genre"] },
      Content: (
        <Link href={`https://next.site/search?genre=${Metadata.Value}`}>
          <a>{Metadata.Value}</a>
        </Link>
      )
    },
    {
      matchingLabel: { none: ["Subject"] },
      Content: (
        <Link href={`https://next.site/search?subject=${Metadata.Value}`}>
          <a>{Metadata.Value}</a>
        </Link>
      )
    }
  ];

  return (
    <Metadata
      metadata={manifest.metadata}
      customValueContent={customValueContent}
    />
  );
};

DOM Output

Note that in this scenario patterns matching label patterns have their sibling values rendered in the default method.

<dl>
  <div role="group">
    <dt>Genre</dt>
    <dd>
      <a href="https:/next.site/search?genre=paintings (visual works)">paintings (visual works)</a>
    </dd>
  </div>
  <div role="group">
    <dt>Record</dt>
    <dd>00001234</dd>
  </div>
  <div role="group">
    <dt>Subject</dt>
    <dd>
      <a href="https://next.site/search?subject=Buddhist art">Buddhist art</a>
    </dd>
  </div>
</dl>

At UTK, we don't necessarily have a set size for thumbnails. Our current practice is to generate thumbnails that are at least 400 pixels wide. That being said, Nectar always takes whatever the thumbnail is and degrades it to 200 pixels wide in useGetImageResource. This has several negative effects in my opinion.

1. You can't use your thumbnail in its native size. It will always be downsize to 200 pixels.
2. If you're using something like Bloom that leverages Nectar, it too follows this same practice. This can lead to some weirdness since Bloom initially will make use of the thumbnail associated with an item in the collection in its native state and then onHover reduce that thumbnail to 200 pixels wide.

In my opinion, nectar should leverage the width property from resource and pass it with service since it is a required property in 2.0, 2.1, and 3.0.

if (Array.isArray(resource.service) && resource.service.length > 0)
    imageService = service[0] as ImageService;

Is there any reason why width should not be leveraged from resource and used in place of size here?

  if (imageService) {
    if (imageService["@id"])
      return `${imageService["@id"]}/${region}/${size}/0/default.jpg`;

    if (imageService.id)
      return `${imageService.id}/${region}/${size}/0/default.jpg`;
  }

I noticed that nectar returns wrong lang on elements when getLabelEntries returns values not matching requested language.

On this english page, https://chc-web.vercel.app/en/id/ubb-ms-0008, i am fetching a Manifest with metadata missing "en" values. Nectar shows the norwegian values in this case, but the html markup assumes that there will be values in the requested language. Example below.

<div role="group" data-label="subjects">
  <dt lang="en" class="nectar-c-PJLV">Subjects</dt>
  <dd lang="en" class="nectar-c-PJLV">
    Reiseskildringer,Reisebeskrivelser, Søvæsen vedk., Kapervirksomhet, Tyrkia, Journal of a priveteer, Avskriftssamling fra 16- og 
    17-tallet, Russland, 1700-tallet, Sørøvertogt, Pirater, England vedk., Krigshistorie, Dagboksoptegnelser, Sjørøveri
  </dd>
</div>

I believe the components should use the correct lang tag, when the Manifest have missing language values.

Long-term, we may want to dereference the rights uri. For now, create a component that renders rights as an anchor.

Add <Logo/> component to support logo in Linking Properties.
See: https://iiif.io/api/presentation/3.0/#logo

The value of this property must be an array of JSON objects, each of which must have id and type properties, and should have format. The value of type must be “Image”.

Labels and Values might contain HTML. See https://figgy.princeton.edu/concern/scanned_resources/678fb869-c5de-4e5a-a1b7-2cd71ff663ec/manifest where a metadata entry is represented as:

   {
      "label": "Identifier",
      "value": [
        "<a href='http://arks.princeton.edu/ark:/88435/fx719n84d' alt='Identifier'>http://arks.princeton.edu/ark:/88435/fx719n84d</a>"
      ]
   }

• Use https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml to render HTML.
• Consider defensive sanitization.

Per Lighthouse recommendation, we could add width and height to the Thumbnail component.

https://web.dev/optimize-cls/?utm_source=lighthouse&utm_medium=devtools#images-without-dimensions

Consider bringing more complex components to map partOf and provider entries.

<PartOf partOf={manifest.partOf}>
  <PartOf.Entry>
    <Homepage>
      <Label as="h3" />
      <Thumbnail alt="my-dumb-alt" />
    </Homepage>
  </PartOf.Entry>
</PartOf>

<Provider provider={provider}>
  <Homepage>
    <Label as="h3" />
    <Logo alt="my-dumb-alt" />
  </Homepage>
  <SeeAlso />
</Provider>