tasking-manager
tasking-manager copied to clipboard
hotosm
Twitter and Facebook card look and info
Currently we only expose the description and overall site title to Twitter cards and Facebook previews:
It might be nice and useful when a task is shared that there is engaging information or look on the preview. The goal would be to provide more information about the current task or a visual that takes advantage of the preview space Twitter and Facebook offers.
What would be useful information to add? Are we constrained by the frontend architecture on what we can show?
From the Twitter card validator:
From the Facebook Debugger:
@smit1678 Very helpful information. Could you add it to the existing issue #776 ?
I thought I did a proper search for previous issues.
We should either close this out and rewrite the others or close the others out and use this one.
Hey @smit1678 and @bgirardot ! I am trying to contribute to this project and just to understand the nature of the problem here, you want the facebook/twitter sharing card to a particular task's description, associated image, etc. right?
@TheChirpyWitch For sure we would like the title of the project and some text from the Description field (Short description often has some tasking manager specific text in it) instead of the generic HOT Tasking Manager description. Also cool might be the %Completed. Not sure about a graphic, we do not currently have a spot for a graphic specifically. but it would be great to have something, even if it was just one image for all the tweets/fb.
I am aware that this doesn't seem to be a high priority issue, but if no one else is working on it, I'd love to give it a shot.
I have had some problems getting everything up and going (I intend to open up an issue on it next week with more details), but I'll add a draft/WIP PR as soon as I have something more concrete.
I am not really convince this is should be tagged as Difficulty 1.
The TL;DR is that right now neither Facebook nor Twitter supports updating the <meta ...> tags with JavaScript for the preview in cards.
The most common solutions are either pre-rendering content or server-side updating of the tags. There were a similar discussion regarding the hrmi-dataportal.
The current <meta> tags can be improved with pre-rendering but without knowing what serves the SPA it would be hard to keep the projects up to date with this approach.
I am currently assuming server-side rendering is not an option.
@k3KAW8Pnf7mkmdSMPHz27 feel free to propose a solution. You're right, SSR is not an option. We use that library to update the title tags of each page https://github.com/rstacruz/react-meta-elements, maybe it can solve the problem.
react-meta-elements can definitively be part of a solution. The only issue is that it does not update/delete meta tags by default, but that should be possible to work around.
As for solutions, some sort of pre-rendering must be done. At the moment, I am looking into react-snap as it seems to be the more maintained pre-render/snapshot solution mentioned in the create-react-app docs, and it does not require any Webpack configuration changes. It produces the correct title and meta-tags for index.html, and unfortunately, some strange visual glitches. I'll need a bit more time to fiddle around with the configurations to see if the issues disappear. If they don't, I'll try some other pre-render technique 😃
My current goal is to get /about (a page with very few dynamic elements) working with Slack preview (which has the same meta-tag issue as Twitter/Facebook but benefits from a solution using oembed, which is likely useful to #3554).
If there is something that isn't clear, feel free to ask. I am new to this subject so, if I am doing something incredibly stupid, there might be something obvious that I have missed 😱
"P.S." I am also assuming that using a paid third-party service is not an option 😛
@k3KAW8Pnf7mkmdSMPHz27 It's a nice proposal. As an open source software, we try to keep it simple to other organizations to deploy, so we avoid third-party services. I've pushed some little improvements on #3590
@willemarcel thank you for your comments (and the link), I'll be using it while debugging.
we try to keep it simple to other organizations to deploy
This clarifies the restrictions to me. For now, I am mostly attempting to get something working, but I'll see if I can find a solution that is easier to debug and less complex than react-snap.
The nutshell version is that the react-snap method can work, but it comes with some limitations,
- The server must look for
index.htmlfiles based on the URL (e.g.,https://tasks.hotosm.org/projects/8863->https://tasks.hotosm.org/projects/8863/index.html). This appears to be the default on most static web hosts (including S3). It works withserve(without the-soption). You can see this redirect in action in the card validator images below. - All dynamic pages must be reachable through crawling (e.g.,
/projects/*is reachable through/explore/). You can set several starting roots (e.g.,/and/api-docs/). - As all information information will be in static
index.htmlfiles, they have to be updated with new information. Which means, crawl the webpage withreact-snapand then sync/upload the new/changedindex.htmlfiles with the static web host.
As 3. in particular will make it harder to deploy TM (and is as far as I can tell unavoidable), this might be a good time for me to stop looking at this issue. If, despite these limitations, this is something TM wants, I can look into how to
- make this an opt-in feature in
tasking-manager.env(similar to service workers) - integrate it into the AWS setup (e.g., crawl and update the site daily/weekly etc.)
"P.S."
I used the organization image as it is intended as a proof-of-concept. Perhaps the zoomed in map-view could be used.
@k3KAW8Pnf7mkmdSMPHz27 thanks for the awesome research! Yeah, I think the effort to make it possible would be too big for a non critical issue...
@willemarcel that seems likely. I appreciate that you have taken the time to respond on a low priority issue!