Have script pull thumbnail from repo automatically about catalog

[dhimmel]

As per manubot/rootstock#267 (comment), would it be best to extract the thumbnail URL from the HTML metadata rather than the source repository?

I imagine we still want to keep thumbnail_url as part of the catalog.yml to override author-set thumbnails or for setting thumbnails that are not set upstream.

[vincerubinetti]

I think that is over complicating it. I think the catalog should have a nice image, and if the one upstream isn't good enough, it's on the author to incorporate the feedback from the catalog maintainers. And if there is no option for a thumbnail, then the manubot logo gets used, as it should.

If we have to make modifications to their thumbnails, that defeats the purpose of the guidelines, and also isn't sustainable. Also we'll end up with several images that are slightly different, which is just bad.

I think it should be simple. Just one image: thumbnail.png. You put it in your repo, and everything gets taken care of. We can look into how the typical thumbnail looks at favicon scale, but I think it will be okay.

And if it's not, we can do this: have the users also specify thumbnail-small.png, which would be a simplified version of the figure -- if they want to provide one -- that looks better at really small sizes. If they don't provide the small version, then thumbnail.png is used in places where the favicon is larger (android and ios app/bookmark icons, windows 10 start menu tiles, social media share thumbnail) and the manubot favicon is used in places where the favicon is very small (just browser bookmarks, really). If neither is provided, then the manubot logo is used for all of it.

[dhimmel]

I think the catalog should have a nice image, and if the one upstream isn't good enough, it's on the author to incorporate the feedback from the catalog maintainers.

If there is no way to set/override the image from the catalog.yml, that presents problems IMO. Since we don't control manuscript repositories we cannot actually require users to set thumbnails that meet our guidelines. We could not add manuscripts to the catalog unless they have a proper thumbnail, but I think we need to err on having the catalog be more complete than incomplete. Furthermore, there are manuscripts like the one added in #8 that don't follow the standard manubot workflow. In this cases, the easiest solution was to upload the thumbnail to a github comment and use that URL. It's not much added implementation complexity to support thumbnail_url overrides, but may come in handy in several places.

thumbnail-small.png for favicons and thumbnail.png for catalog and large previews makes sense to me.

[vincerubinetti]

I'd recommend just reinforcing the rules by not accepting manuscripts with bad thumbnails, but that is ultimately your call. As for the workflow though, that person would just have to put the thumbnail.png in that repo in the right location, as we'd just be scraping it from that... I don't see why that would be a problem with someone not using the manubot workflow.

Also it's probably better to have the image in the repo itself than in a github comment, imo.

[dhimmel]

As for the workflow though, that person would just have to put the thumbnail.png in that repo in the right location

Repositories like sbonaretti/FAIR_metrics don't follow the standard directory layout. The catalog contains old repositories that are no longer maintained, and thus are unlikely to have their source edited.

I'd recommend just reinforcing the rules by not accepting manuscripts with bad thumbnails

We will encourage proper thumbnails but if we're unsuccessful for a certain manuscript, I still want the ability to add it with either the bad thumbnail suppressed or set to a third-party location (like a GitHub Issue comment). Not ideal, but I'm hoping the incentive to have a nice thumbnail displayed when a manuscript is shared will help incentivize users towards the desired behavior.

thumbnail.png in that repo in the right location, as we'd just be scraping it from that

Were there downsides to scraping from the HTML metadata that we'll be setting? The benefits of using the HTML metadata rather than a file location is that it's more flexible by supporting manuscript-external thumbnails specified by URL, possibly works better for versioned manuscript links, doesn't require inspecting file contents of repositories (which can be more complex). The Manubot software would still look to a default file location to set the HTML metadata, but the end users would just read the URL path from the HTML.

[agitter]

I would also prefer to err on the side of accepting most manuscript contributions to the catalog and not let an improper or missing thumbnail be cause for rejection. I see the main purpose of the catalog as showcasing the quantity and diversity of Manubot manuscripts, including those that don't follow the canonical directory structure.