nextstrain / nextstrain.org

The Nextstrain website
https://nextstrain.org
GNU Affero General Public License v3.0
89 stars 49 forks source link

Add Open Graph and Twitter Card meta tags for rich embeds/previews #134

Open tsibley opened 4 years ago

tsibley commented 4 years ago

Open Graph is a microformat that specifies <meta> tags which can be added to the <head> of pages in order to provided structured data about the page. Apps like Facebook, Twitter, and Slack will look for these tags and use them to provide richer embeds/previews when someone links to the page.

Twitter Cards build upon Open Graph to provide some extra Twitter-specific information. These may or may not be necessary in our case.

By setting this up for nextstrain.org pages, links in social apps will display a better preview. Doing so will require changes to both Gatsby and the Nextstrain extensions to Auspice.

One challenge will be picking an appropriate "cover" image, since nearly all of the fancy visuals of Nextstrain are dynamic and not static. A first-pass option might be to use the pathogen cards on the front page of Nextstrain. Later, if desired, we could provide an endpoint which generates screencaps of the tree or map or something (probably with significant caching).

victorlin commented 4 years ago

It seems like these tags for the nextstrain.org static site have already been implemented by SEO.js + SiteConfig.js. See this Open Graph Check of https://nextstrain.org - the tags are there. It's worth noting that this seems to be outdated and the og:image points to a non-existent file.

The problem is when linking to a page for datasets or narratives. Examples:

Since these are generated by auspice (the HTML base seems to be auspice/index.html), I believe this issue should be moved over to that repository, unless you all would rather track it here.

psthomas commented 4 years ago

I think the og:image file is missing because the siteLogo url in siteConfig.js points to the location in the repo ("/static/logos/nextstrain-logo-small.png") rather than the public location after the static site is built ("/logos/nextstrain-logo-small.png"). I think this is due to the way Gatsby handles absolute links to static files.

Twitter cards should fall back to Open Graph tags if Twitter tags aren't present, but I don't think this is working. Their card validator finds the meta tags but doesn't render a preview, so it might just make sense to add the Twitter tags as well. I can experiment and make a pull request.

Do you have a preference for the "Summary", or "Summary with Large Image" cards? I like the low-key look of the Summary card more but it's up to you. cards

tsibley commented 4 years ago

Thanks @psthomas! I too have a preference for the more condensed "Summary" cards. We'll try to review your PR soon.

psthomas commented 4 years ago

Ok, thanks! The approach I took was to read in the url and splash image relationships from the Cards, and then export a react component that uses them to sync the tags in Auspice. This component could eventually point to screencaps if you used something like Puppeteer to create them during the build.

I've tested all of the static site tags and they work, and the Auspice tags work locally. The main question I have is whether the Auspice tags will be visible to social media bots because some of them aren't rendered on the frontend until after the dataset loads. This would mainly be a problem for the description tags, which are taken from the metadata after it loads.

genehack commented 1 month ago

Currently, the OpenGraph meta-elements are only appearing in fully hydrated pages, which is generally not the version of the page that is seen by OpenGraph-consuming applications (e.g., Twitter, Facebook, Mastodon, etc.)

The proper fix here, it seems to me, is getting the metadata to be available in the "un-hydrated" version of the page (i.e., the page version that you see when running curl against the site, not the page version that you see in a browser's web inspector). From what I can tell by experimenting with a small demo Next.js app, the currently "correct" way to do this is with the Metadata API, which is only available when using the App Router.

Consequently, I am going to build on my recent metadata for feed auto-discovery PR and convert the blog over from the Pages Router to the App Router, fixing the OpenGraph meta tag generation along the way. Since we will still, at that point, have some pages using the Pages Router, the changes in the feed auto-discovery PR will still be relevant (hence, why I'm going to do this work on top of that branch).

Hopefully this also gives some idea about how much additional work it will be to switch completely to the Apps Router...