Improve social share properties of individual blog posts #30
Comments
|
One preliminary note: We can create distinct twitter cards if we have a distinct URI that's being shared. Hashes in URLs do not meet that requirements, as in hxxp://foo/#item-two the same in twitter's share-card eyes as hxxp://foo/#item-three . |
|
What about query parameters? Right now, the liveblog links to, eg, |
|
Query parameters would work! I took a look at NPR's 2016 elections live blog and there's a "Copy this link" link on each entry, which returns a query param link such as https://www.npr.org/2016/11/08/500427835/live-blog-election-night-2016?post=key-takeaways-from-tonight-97 . |
|
Best as I can tell, twitter is pulling the metadata for its twitter card from the To make this work we would have to be able to edit those elements on the backend on render when the post param is present. |
|
Re-reading your issue Miles I now see that's what you were saying in the first place. |
|
Since the liveblog is iframed in (going with the 2016 election example, https://apps.npr.org/elections16-liveblog/child.html is the iframe'd URL), we have a couple of options for delivering liveblog post-specific meta information to twitter & facebook:
|
Probably a non-starter, since the Seamus team has extremely limited time to work with us this election cycle.
Oof, I think this may be out of scope, and this non-native approach to social tagging may mess with some of our existing analytics or social strategies? Not sure off the top of my head. @alykat, since you've got exposure to Seamus, do you know if social-share properties have to be set within Seamus, or if we've hacked around it before (either how Joe describes, or otherwise)? |
|
Not possible w/ Seamus, AFAIK. There's a "teaser" field that's set for each story page. Unless it's possible to change it w/ javascript and have TW/FB respect that, I think we're out of luck w/ option 1. Option 2 is really interesting if we don't get penalized for the redirect. |
|
So the biggest danger with option 2 is the URLs we create get indexed by search engines -- which is something we can address. Here's how it would work: We'd write a script that creates and deploys a flatfile for each liveblog post, for example, hxxps://apps.npr.org/elections16-liveblog/post-example.html post-example.html would be the smallest html file, here's a rough mock of the markup: <html>
<head>
<title>Example Post</title>
<meta name="robots" content="NOINDEX">
<meta property="og:title" content="LIVE BLOG: Example Post" />
<meta property="og:description" content="Example Post description" />
<!-- ...more social-specific meta tags ... -->
</head>
<body>
<h1>Example Post</h1>
<p>If you are not redirected, <a href="https://www.npr.org/2016/11/08/500427835/live-blog-election-night-2016?post=example-post">visit the NPR live blog here</a></p>
<script>
document.location = 'https://www.npr.org/2016/11/08/500427835/live-blog-election-night-2016?post=example-post';
</script>
</body>
</html>We'd have to figure out how the meta title and description content would be administered. |
|
From Patrick:
|
|
That makes sense -- we can test javascript-built redirects and see what we need to do to make sure the bots don't notice / honor them. Not all redirects are equal, and I'm fairly certain the twitter / fb bots are not particularly sophisticated. |
|
If it seems like this is going to be a ton of effort (>2 days of work, including planning+research and deployment+testing), we can loop back to Arnie and confirm that he wants us to sink time into it. I expect he will, but he should be aware it might cause us to scale back one or two other issues. What's your time estimate on this issue as a whole right now? |
|
10-15 hours of dev work. If everything goes smooth it would be ~6 hours of work.
|
mileswwatkins
added
effort:heavy
|
After talking with Sara G. and Arnie S., they indicated they were okay with the social share card title pulling directly from the liveblog post title, and the social share care description pulling from the first paragraph of the liveblog post. The social share image will be the first image in the post, however, we might get into a situation where the dimensions of that image don't play well in social share cards. |
|
I did a proof-of-concept test of the sharecard plan on twitter here (on the twitter account I use for testing such things): https://twitter.com/dpotest/status/1039945466748854272 , it passed the test. |
…n the social sharecard flatfiles, update sharecard view to pull in post-specific data
|
As of this morning right now this is what's left on the social sharecard flatfiles:
|
|
Re deploying to s3, I stumbled across this file https://github.com/nprapps/liveblog/blob/master/fabfile/flat.py , which isn't called anywhere, but might do what we're looking to do. |
…blog post doesn't have a image in it, also, improve image src parsing in cases where the image doesn't exist
|
Note: Per analytics, URLs with query params ("utm_source=blah") will need to be passed on to the parent liveblog URL. Example: http://apps.npr.org/elections18-liveblog/sharecard/{{post-slug}}.html?utm_source=facebook Needs to redirect to http://www.npr.org/path/to/parent/article?utm_source=facebook |
…ng into why images deeper in blog posts aren't getting pulled
|
Upload working now: and on subsequent runs: And those cards are working exactly as intended, once on S3. The last thing to handle is testing and debugging how the images and descriptions show up on Twitter and Facebook. |
|
|
Images that can't cop well to the expected sharecard size come up janky, but there's no good way around this, within scope. Eg:
|
Right now, each liveblog post has a share URL, which deep-links to that point in the liveblog timeline. But these posts don't have Twitter cards or related properties for social sharing.
The text was updated successfully, but these errors were encountered: