fixthestatusquo/proca

Evaluate share native

tttp opened this issue · 9 comments

tttp commented

For visitors coming with a mobile phone

X+

Not urgent but can you put this somewhere in your pipe?

tttp commented

Bit of context, the share text is relying on a library that composes the right url to share with the chosen social media.

share step, click on the next button on the top right corner to reach it without having to sign the petition
image

The problem is that we can, obviously, only share with the social media that offer an api like to start a share, and some, like signal, don't

However, there is a better way for the users on a smartphone:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_API
https://css-tricks.com/how-to-use-the-web-share-api/

so the goal would be:

  • check if the browser offers a share api
    if it isn't the case, put a bit share button (layout to be finetuned) that starts it
    if it isn't leave the share as today

there is a bunch of magic about which text is available for which social media (right now, we tend to suggest different texts for different social media, eg on twitter, we'll put hashtags but on whatsapp, we'll have a more personal tone), right now, we need to check if it's possible to use that api, and we can finetune later.

1v4n4 commented

About PR #780
To run localhost on https: HTTPS=true yarn start (42).
I tested this solution for my phone's share options and it works.
I'm not sure about the format of the URL and the catch error method in the shareWebAPI promise.

tttp commented

We have to solve an impedance mismatch between the messages we have/store and those that are used by the api

api params:

  • text
  • title
  • url

image

It's not crystal clear for me which combo os/browser/share medium takes or ignore, but:

  • url: always used
  • text: supposed to be the long one, sometimes ignored
  • title: supposed to be the short one, sometimes ignored

on the proca side, we have

  • name of the campaign
  • share.default
  • description

@1v4n4 could you try to see if there is a doc on which share media takes what? (on chrome)

most importantly:

  • signal
  • whatsapp
  • email
  • instagram

?

1v4n4 commented

chromeAndroid

FirefoxAndroid

tttp commented

Amazing!

so title is hardly used, and when it is, it's in a rather dumb way (eg when sharing by mail, it does put both title and text in the body, rather than putting the title in the subject and text in the body)

in view of that:

  • we put share.default into the text
  • the url (obviously)

and we don't use the title

tttp commented

Hi,

one user reported that the share native is displayed on windows/chrome

The issue is that the share pop-up on window is horrible and doesn't make any sense, because most/all the social media aren't apps on windows

I can think of two fixes:

  • display only if share API AND isMobile is false (we have two isMobile functions, one based on the width of the screen, the other on the agent, I'd use the first one)

  • always display the "old" share buttons AND display the native one if it is available

I don't have a strong opinion either way, but in any case, I'm wondering if we shouldn't add a native click handler on the image+text if native share exists so even with folks with fat fingers, they can hit it more easily ;) (the normal button is probably worth keeping in any case)

1v4n4 commented

table update
share1
share