opds-community / drafts

Contains all the current drafts for the OPDS specifications
36 stars 10 forks source link

OPDS 2 - Optional images for navigation links #64

Open fillito opened 1 year ago

fillito commented 1 year ago

Some content servers (Komga, Kavita, Codex, LANraragi,...) that support OPDS 1.2 can provide images for the different publication containers (folders, series, collections, arcs, ...). These containers are represented as OPDS navigations. But they don't support thumbnails or images. This is mostly fine when the client shows a list if navigation links. But when the representation is more visual, clients are forced to use generic folder images or similar approaches.

It would be great if Navigation would support an optional Images structure that clients can use to render nicer navigations.

I'm pretty sure the idea is clear, but I'm attaching an example of how the JSON would look with a navigation item supporting images, and another one not doing so.

{
    "metadata":
    {
        "title": "Example for navigation"
    },
    "links":
    [
        {
            "rel": "self",
            "href": "http://example.com/opds",
            "type": "application/opds+json"
        }
    ],
    "navigation":
    [
        {
            "href": "/new",
            "title": "New Publications",
            "type": "application/opds+json",
            "rel": "current"
        },
        {
            "href": "/popular",
            "title": "Popular Publications",
            "type": "application/opds+json",
            "rel": "http://opds-spec.org/sort/popular",
            "images":
            [
                {
                    "href": "http://example.org/cover.jpg",
                    "type": "image/jpeg",
                    "height": 1400,
                    "width": 800
                },
                {
                    "href": "http://example.org/cover-small.jpg",
                    "type": "image/jpeg",
                    "height": 700,
                    "width": 400
                },
                {
                    "href": "http://example.org/cover.svg",
                    "type": "image/svg+xml"
                }
            ]
        }
    ]
}
gotson commented 10 months ago

@HadrienGardeur do you have any thoughts on this? This was a pretty big limitation in opds 1, and still is in 2.

Any server allowing for browsing content by series will have that limitation. It also impacts any kind of browsing by category, publisher, or other kind of grouping container.

It echoes to https://github.com/opds-community/drafts/discussions/69 and it feels like navigation is always a second class citizen compared to publications.

HadrienGardeur commented 10 months ago

This is something that we explored at some point but we never really turned that into a spec. Here's the document where I explored these options: https://github.com/opds-community/drafts/blob/master/docs/presentation/ideas.md

The main problem with visual navigation from a client perspective is that you could get images with very different ratio and/or resolution. This makes it difficult to design something that looks nice.

gotson commented 10 months ago

The main problem with visual navigation from a client perspective is that you could get images with very different ratio and/or resolution. This makes it difficult to design something that looks nice.

It seems like a client issue though. In css it's easy to have a fixed size image container and make the image inside fit to the box.

Since an image collection can contain multiple images with different size, the client could choose the one that fits best.

gotson commented 10 months ago

The main problem with visual navigation from a client perspective is that you could get images with very different ratio and/or resolution. This makes it difficult to design something that looks nice.

Wouldn't that be the exact same situation when browsing a publication feed though?

HadrienGardeur commented 10 months ago

Apps have to deal with similar problems with publication covers but they're already designed with that in mind.

OPDS 2.0 already goes beyond what 1.x could do thanks to groups but I'm open to exploring the idea of adding additional visual representations (as illustrated in the presentation doc from… 5 years ago). This would allow us to create a full Netflix-like experience with hero banners and visual navigation for pretty much everything.

HadrienGardeur commented 2 months ago

I would group this issue with a few others for discussion in a future monthly OPDS call. Opening up a discussion might be worth it too.

If a string (title) and an expected number of items (numberOfItems) are not enough, we could also explore adding support for: