Improve social share properties of individual blog posts

mileswwatkins commented 6 years ago

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.

freejoe76 commented 6 years ago

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 .

mileswwatkins commented 6 years ago

What about query parameters? Right now, the liveblog links to, eg, https://apps.npr.org/liveblogs/foo/index.html?post=test-post-2

freejoe76 commented 6 years ago

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 .

freejoe76 commented 6 years ago

Best as I can tell, twitter is pulling the metadata for its twitter card from the <meta property="og:title" content="LIVE BLOG: Election Night 2016" /> and <meta property="og:type" content="article" /><meta property="og:description" content="As America goes to the polls, NPR's politics team brings you up-to-the-minute results, news, analysis and views from around the country." /> elements in the head on https://www.npr.org/2016/11/08/500427835/live-blog-election-night-2016?post=key-takeaways-from-tonight-97 .

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.

freejoe76 commented 6 years ago

Re-reading your issue Miles I now see that's what you were saying in the first place.

freejoe76 commented 6 years ago

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:

Write backend functionality into seamus that delivers what we want to the post-specific URLs.
Write backend functionality that deploys to apps.npr.org with the desired metadata, delivers that metadata to the twitter / facebook scrapers, and when readers visit that URL issues a javascript redirect that sends those readers to the correct www.npr.org URL.

mileswwatkins commented 6 years ago

Write backend functionality into seamus that delivers what we want to the post-specific URLs

Probably a non-starter, since the Seamus team has extremely limited time to work with us this election cycle.

Write backend functionality that deploys to apps.npr.org with the desired metadata, delivers that metadata to the twitter / facebook scrapers, and when readers visit that URL issues a javascript redirect that sends those readers to the correct www.npr.org URL.

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)?

alykat commented 6 years ago

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.

freejoe76 commented 6 years ago

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.

mileswwatkins commented 6 years ago

From Patrick:

For the analytics issue, I’d defer to Dan Frohlich in AIR. But overall, I’d say watch out for the redirects. I believe Google, FB and Twitter bots all follow redirects and cache the final destination’s metadata, ignoring the intermediate page’s metadata. So, you wouldn’t be penalized, but you probably wouldn’t get them displaying what you want either. Worth testing in the Facebook debugger, for instance.

freejoe76 commented 6 years ago

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.

mileswwatkins commented 6 years ago

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?

freejoe76 commented 6 years ago

10-15 hours of dev work. If everything goes smooth it would be ~6 hours of work.

We'll have to hook into Google Docs liveblog and use that as the admin interface for the social share metadata. This may include updates to liveblog-addons, which I'm quite familiar with now.
The hook will include writing and deploying flatfiles to EC2.

freejoe76 commented 6 years ago

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.

freejoe76 commented 6 years ago

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.

freejoe76 commented 6 years ago

As of this morning right now this is what's left on the social sharecard flatfiles:

[x] Figure out how to integrate the URL of the lead image in the liveblog post.
[x] If there's no lead image, figure out what the alternative is.
[ ] Figure out if it's worth cropping the lead image to conform to the ideal social share image size ratio (2x1, 1024px x 512px ideally).
[x] Pull the lead sentence of the liveblog post in to use as the meta description.
[x] Render the page as a string.
[x] Generate a filename (based on the post slug) and write that string, with boto, to the Amazon S3 bucket.
[x] Create a sharecard directory on the S3 bucket.
[x] Update the liveblog per-post "Copy link" functionality to point to the new social sharecard URL. This pattern will work the same as the previous pattern, it will look something like http://apps.npr.org/elections18-liveblog/sharecard/{{post-slug}}.html

freejoe76 commented 6 years ago

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.

freejoe76 commented 6 years ago

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

mileswwatkins commented 6 years ago

Upload working now:

INFO:fabfile.flat:2018-09-24 16:47:50,283: Uploading .liveblog/sharecard/test-5.html --> liveblogs/20181106-elections/2018-09-24-16:47:49-liveblog/sharecard/test-5.html
INFO:fabfile.flat:2018-09-24 16:47:50,326: Uploading .liveblog/sharecard/test-post-2.html --> liveblogs/20181106-elections/2018-09-24-16:47:49-liveblog/sharecard/test-post-2.html
INFO:fabfile.flat:2018-09-24 16:47:50,435: Uploading .liveblog/sharecard/foobar-2.html --> liveblogs/20181106-elections/2018-09-24-16:47:49-liveblog/sharecard/foobar-2.html
INFO:fabfile.flat:2018-09-24 16:47:50,568: Uploading .liveblog/sharecard/post-haste-3.html --> liveblogs/20181106-elections/2018-09-24-16:47:49-liveblog/sharecard/post-haste-3.html

and on subsequent runs:

INFO:fabfile.flat:2018-09-24 16:47:59,259: Skipping .liveblog/sharecard/test-5.html (has not changed)
INFO:fabfile.flat:2018-09-24 16:47:59,277: Skipping .liveblog/sharecard/test-post-2.html (has not changed)
INFO:fabfile.flat:2018-09-24 16:47:59,295: Skipping .liveblog/sharecard/foobar-2.html (has not changed)
INFO:fabfile.flat:2018-09-24 16:47:59,314: Skipping .liveblog/sharecard/post-haste-3.html (has not changed)
INFO:fabfile.flat:2018-09-24 16:47:59,331: Skipping .liveblog/sharecard/jw-stream-test-6.html (has not changed)
INFO:fabfile.flat:2018-09-24 16:47:59,351: Skipping .liveblog/sharecard/test-post-1.html (has not changed)

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.

mileswwatkins commented 6 years ago

[x] Validated the Twitter cards using Twitter's validator https://cards-dev.twitter.com/validator
[x] Validated the Open Graph properties using Iframely http://iframely.com/debug
- [ ] Facebook has an Open Graph validator too, but NPR Visuals doesn't have an account (and neither do/will I) https://developers.facebook.com/tools/debug/

mileswwatkins commented 6 years ago

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:

nprapps / liveblog

Improve social share properties of individual blog posts #30