Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Social sharing of pub packages not as rich as sharing a github repo #7886

Open
sethladd opened this issue Jul 22, 2024 · 7 comments
Open

Social sharing of pub packages not as rich as sharing a github repo #7886

sethladd opened this issue Jul 22, 2024 · 7 comments

Comments

@sethladd
Copy link
Contributor

We noticed that there are some opportunities to improve the social sharing experience of a pub package hosted on pub.dev. Specifically: more auto-generated context and "splash image" of the pub package.

In comparison, here is what it looks like to share a github project (via X):

Screenshot 2024-07-22 at 10 23 20 AM

Note the large image with content around what the package is, contributors, stars, forks, etc (giving a more accurate impression about the status of the project).

Compare that with a social share from the same project's pub package:

Screenshot 2024-07-22 at 10 23 01 AM

Note the static stock image for "pub", with no package branding/identification/stats

To help people promote their awesome work as hosted on pub.dev, we should consider how to make a more rich "social share snippet image". We can use GitHub as the inspiration here.

Ideally, when sharing a package's pub.dev URL via social services like X, it would be good to:

  • auto-generate a snippet image
  • including the name of the package
  • including any primary image from the package
  • including a one-line description of the package
  • including some basic stats like stars, pub score

Thanks for considering!

@sigurdm
Copy link
Contributor

sigurdm commented Aug 1, 2024

@sigurdm
Copy link
Contributor

sigurdm commented Aug 1, 2024

Seems we are already creating these tags, but the content is not as precise as wanted.

'${urls.siteRoot}${staticUrls.getAssetUrl('/static/img/pub-dev-icon-cover-image.png')}',

We could specialize the image if there is one in the readme or perhaps use one of the screenshots.

https://robolly.com/open-graph-preview/?url=https://pub.dev/packages/retry

image

@halildurmus
Copy link

halildurmus commented Aug 1, 2024

I believe the best approach would be adding a new field to the pubspec.yaml, for example social_image, which would allow package authors to specify a preferred image for social previews. If omitted, an image from the screenshots or one embedded in the README could be used. In cases where no images are available, pub.dev could generate a preview image, similar to how GitHub does.

Alternatively, if the social_image field is omitted, the preview image generated by pub.dev would be used.

@isoos
Copy link
Collaborator

isoos commented Aug 2, 2024

I think we shouldn't add yet another tag into pubspec.yaml for this, as if you have a screenshot, you already order them by importance, and the first one will be the one displayed on the package listing pages. We should just reuse it for social media sharing.

@sigurdm
Copy link
Contributor

sigurdm commented Aug 2, 2024

and the first one will be the one displayed on the package listing pages.

However, the intended semantics of screenshots is to be ... screenshots - not clear that that is the same as a display image.

@sigurdm
Copy link
Contributor

sigurdm commented Aug 2, 2024

But I agree, adding yet another pubspec property just for this also sucks

@halildurmus
Copy link

and the first one will be the one displayed on the package listing pages.

However, the intended semantics of screenshots is to be ... screenshots - not clear that that is the same as a display image.

+1 to this. Also, the documentation of the screenshots property states:

Don't include logos or other branding imagery in this section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants