Improve social media share preview: title, description & image

I am generally happy with the appearance of shares from iNaturalist to Discord and other social media platforms (e.g. Facebook) for a wide variety of URLs. I understand this is principally achieved through the use of Open Graph meta tags. Sharing a taxon page or an observation page, for example, works well, with meaningful titles & descriptions relating to the content, as well as an appropriate image.

However, I am somewhat frustrated by having to always manually delete previews from my shares whenever these tags only contain the barest minimum of information (just the site name & logo). So, for example, while the social media platform’s link preview for a search of your own observations is decent, the preview for a search of all observations is … underwhelming. Let me give you two example URLs.

For this use case, I am a “power user” who would like to see the mayflies found in April and discuss this with my friends on social media, and I know how to format a reasonably compact URL to do this, which is nice for bookmarking & sharing on social media. Entering this URL for my own observations produces a useful preview describing the content, giving it a title, and selecting a preview image (thumbnail of the 1st observation - normally the most recent, so not a bad choice):

https://www.inaturalist.org/observations/benarmstrong?taxon_name=Ephemeroptera&taxon_id=48011&month=4

image

However, I more often than not am sharing links that aren’t specifically from my own observations, as I can gain broader insight into the iNaturalist data by looking at all the observations in the geographic region, or across a project, etc. Therefore, if I change the above link to a search of all observations, not just my own (I am switching it to user_id=benarmstrong here simply to show a search with exactly the same results) I get a default title & default image for the preview that pretty much tell me nothing more than just reading the URL would tell me, i.e. “this is a link to some page on inaturalist.org”. Therefore, I need to make an extra effort to delete these whenever I share such a link, as it just adds “noise” to my post, and my link lacks the pizzazz and ease of use that comes from having a useful preview:

https://www.inaturalist.org/observations?user_id=benarmstrong&taxon_name=Ephemeroptera&taxon_id=48011&month=4

image

The culprit here is these two Open Graph tags, unsupported by any additional og: tags that would be preferred by social media sites, as they provide useful preview content (as in the previous example):

    <meta property="og:site_name" content="iNaturalist"/>
      <meta property="og:image" content="https://static.inaturalist.org/sites/1-shareable_image.png?1573071871"/>

By contrast, the good preview first example has these:

      <meta property="og:site_name" content="iNaturalist"/>
  <meta property="og:title" content="Observations by benarmstrong">
  <meta property="og:url" content="https://www.inaturalist.org/observations/benarmstrong?taxon_name=Ephemeroptera&amp;taxon_id=48011&amp;month=4"/>
  <meta property="og:description" content="benarmstrong&#39;s latest observations on iNaturalist">
      <meta property="og:image" content="https://static.inaturalist.org/photos/69127078/medium.jpeg?1587892661"/>

So if the same useful og:* tags could be provided here, that would be great! Or if not, then remove the not very useful existing tags (though that feels like a step backwards).

I’m sure there are other cases I’ve seen before that could use similar treatment, but even handling this one case would measurably improve the user experience sharing iNaturalist pages to social media platforms.

The reason there aren’t good Open Graph tags here is because there’s no reasonable and translatable way to summarize all the many things that could make an obs search URL unique, unless you think something like this is reasonable:

Observations between 2020-02-05 and 2020-06-01 of nudibranchs but not the genus Cuthona in California but not Los Angeles identified by Ken-ichi and observed by Tony where the rank is between subfamily and tribe ordered by date observed descending that have not been reviewed by me that have CC0-licensed photos in My Special Project"…

etc., i.e. something practically unreadable in English and almost impossible to translate properly into other languages (complexity of translation seems to be something like [number of language] * [number of variables]). I can set og:title to “Observations” and maybe set a reasonable description for some of the more common search cases, but there will still be a lot of cases where a really good description isn’t possible.

i don’t think it’s necessary to handle every variant of what could be queried, but it might be nice for that page to be able to handle at least certain parameters like user, taxon, and place: [user’s] observations [of taxon] [in place].

3 Likes

Well, obs search now has og:title, og:type, and og:description, but for reasons I’ve yet to determine neither the Facebook Sharing Debugger or the Twitter card validator are picking up the description.

1 Like

That’s a bit of an improvement:

image

The og:description isn’t shown on Discord either, though.

I notice in my “good” example it’s a twitter gallery card, but the observation search is a twitter summary card. Maybe for the gallery card, they accept og:description but the summary card needs a twitter:description instead?

I still feel showing the first image is more interesting/informative than just the iNat logo, as well as consistent with how the user’s observation page is previewed.

Do you have any idea why? I’m not sure what’s up with that. I don’t think it can be related to the Twitter tags since, theoretically, both your Discord parser and Facebook’s should just ignore those.

I agree the image would be nice, but we’re trying to avoid actually performing a query there, since the page already runs the same query in Javascript when a client running Javascript loads that page. Some scrapers who look at those og tags run JS, so it’s hard to target the ones that don’t, but I’m open to suggestions. There’s also the issue of dynamic content, which seems like more of an issue on obs search than on obs detail.

1 Like