default facebook sharing opengraph og images for random pages and ascent facet pages

[brendanheywood]

What happened? If you share a random page on facebook, like my tick list, or Jakobs recent rocklands trip, then you just get the old logo. So we need to swap that out with the new logo but this is also a fairly low hanging fruit to make this a bit nicer somehow.

What you expected:

There is a specturm of options here. I think from the simplest low hanging fruit to some longer term stuff

• [x] have a default logo as worst case fallback for any arbitrary pages
• [ ] for facet pages set the og title and description properly so it's not grabbing random bits of text, like the first ascent markdown
• [ ] for ascent facet pages, or route facet pages, create a summary image. This could be as simple or as complex as we want, like it could contain the avatar of the person, a simple bar chart of the grades of the ascents or routes. The main technical restriction is that it must be served as an image, and ideally because facebook will be scraping this on demand it needs to be very snappy.

So I'm leaning towards the og images being stateless, ie everything they need to generate the image is in the url, and this is populated by the facet page. og images are usually cached indefinitely, so if the contents change then we need to change the url, ie with new content query params, or with a version cache buster param. This way the image url will need no sessions or db lookups or whatever and it just render stuff real fast. Very similar to the google charts static image api. I don't think anything that pipelines via phantom or does some sort of conversion from the templates or svg into a png will be viable, we need to render this in raw perl using GD or something similar. So I'm leaning towards very simple stuff which is styled similarly to the templates.

So some very rough ideas, something like this (also needs the logo somewhere and a bar chart of the ticks)

Other ideas

• [ ] if it's a date range, then the days is important, ie 50 boulders in 3 days
• [ ] have a donut circle for gear style
• [ ] have a donut circle for grade difficult? or bar chart

Side issues

• [ ] face a preview in the facet itself
• [ ] have a 'share on facebook' button to make it easy
• [ ] have a cache busting param (date based) so if you share your profile FB gets the latest version

Good test candidates:

• https://www.thecrag.com/ascents/between/2017-11+2017-11/by/woody2788/

Some examples in the wild which I like:

https://www.urbanclimb.com.au/member-interview-urban-climb-west-end-ben-reid/

Random stuff from the wild:

https://www.strava.com/activities/1487340328 https://www.strava.com/activities/1487340328/shareable_images/map_based?hl=en-US&v=1522772839

[scd]

Do you mean something like:

https://www.thecrag.com/climber/brendanheywood?card=ogimage

where the card creates an ogimage version of the page.

[brendanheywood]

Yes, but because it's stateless the url will be something vaguely like:

/image?s=700x370&title=55 Ascents by Brendan&bigstats=hardest:V7:gb4,onsighted:V3:gb3,ascents:55,distance climbed:241m&gearband=boulder70trad20sport10&avatar=someurl

The intention here is to make this image endpoint completely generic so we can use it for other things besides facebook, each network has their own sizes and dimensions etc

I can almost do all this myself, the only tiny missing piece of the puzzle is that a facet is paginated, and some of these stats are totals or max for the whole set. But we can cross that bridge when we get into it.

[scd]

OK, I missed the stateless bit.

Pagination of facets should not be a problem as it is already solved for CPR charts. Ahh, but performance might be a problem for the large facets. So yes you are right, there could be an issue here.

[brendanheywood]

I've had a wee break from other things and had a quick crack at a basic stateless image serving script. Here is an example with just the big stats component working:

/chart/chart.php?bigstats=4:hardest:V7;3:onsighted:V3;:ascents:55;:distance%20climbed:2,041:m

There is some minor font rendering differences if you are looking hard, but I'm quite happy with this. It probably only another few hours to get this into shape for prod, the missing part now is being able to generate these summary stats for any facet in the template data, regardless of how many pages there are. I'm happy to be pragmatic here and use a similar rule to the pagination bar, ie if there is more than X records it just caps it. We could possibly even combine the summary sql with the same pagination count sql

[scd]

In regards to integrating to all ascent facets there are a couple of thoughts.

• Other than a facet for a single account, what other ascent facets would this be relevant for
• I think it would be potentially confusing if we presented a group function which did not cover all ascents in the group.
• The way facets currently work is that there is an overall limit on the number of records counted and a smaller limit on the number of records returned. So facets are done in a single query and we have worked it out to be fairly performant. If we were to hook into this single query then we would have to abandon the one or both of those limits.
• This is a somewhat simplier version of a group function then the cpr curve, but we should implement the group functions in the same way. Ie embed a group aggregate function for the whole query. The pattern is in the system already.

We do not have to embed in the profile page but I highly recommend we embed in the facets.

[brendanheywood]

I'll leave the internals up to you, I'm am not fussed if the summary functions are prefect for large facets or not, it just needs to be good for ones which a only a couple pages or a single page. I'm also flexible about what summary stats we provide.

The candidates that I'd want to be able to show, but happy to just do the low hanging fruit here:

Ascents facet:

• [ ] total number of ascents
• [ ] total distance
• [ ] hardest tick
• [ ] hardest onsight / flash - low priority and doesn't make sense everywhere
• [ ] date period, ie what is the latest climbed on date - the earliest date climbed on, which is different to the facet date between filter.
• [ ] unique days that were climbed on. Eg so I can say '800m climbed over 4 days'
• [ ] breakdown of ticks by grade band
• [ ] breakdown of ticks by gear style
• [ ] lowest level common node - this is distinct from the reference area

Routes facet:

• [ ] total number of routes
• [ ] total distance
• [ ] hardest route
• [ ] most popular route
• [ ] top 5 most popular areas inside reference area
• [ ] breakdown of routes by grade band
• [ ] breakdown of routes by gear style

Some stats are in the reference area object, but these won't be filtered.

[brendanheywood]

Other than a facet for a single account, what other ascent facets would this be relevant for

I think something we've learned over and over is that people end up doing unforeseen cool things so I don't want to limit it at the low level tech layer, ie I want to be able to run this for a crag, or for a group of a few climbers, or by gender or whatever

BUT as I'll repeat again below, speed is the main thing that matters - so I'm am more than happy to initially restrict this to certain types of facets in order to keep it fast, eg we could have a simple heuristic like if the 'by' filter is set then show it, other wise don't.

The way facets currently work is that there is an overall limit on the number of records counted and a smaller limit on the number of records returned. So facets are done in a single query and we have worked it out to be fairly performant. If we were to hook into this single query then we would have to abandon the one or both of those limits.

One key difference between this and the aggregate functions is that this image is stateless by design and for good reasons, the data is encoded into the url so the calling page needs to know the data up front. So it all needs to be dirt fast as it's in the first initial request, we can't offload it into an iframe if it's a little slower. But correctness is not that important, if we get to large numbers I am super happy to just say things like "1000+ ascents" or "10km+" or whatever the limits end up being. In fact I'm happy to adjust what data I present in this summary based purely on what's fast and easy to access. I'm also happy to adjust what is show based on whats easy for this particular facet, so for instance if the facet only has one page then we can do it all in perl land with zero new sql and with perfect results. But if there is more than some limit (only one page?) show a different type of summary which is only the types of things we can in sql land min() max() etc.

[scd]

FYI I originally played around with GD for all the charts and it was not very impressive. I think all the charts on the old statistics page are GD generated charts

https://www.thecrag.com/climbing/australia/arapiles/statistics

So one chart looks like:

https://www.thecrag.com/chart?NC=1&C=customBarAreaGradeProfile&T=gif&P=11740915&S=YDS&X=0.467868804275167

They are all generated via the Portal/GenerateChart function. I don't think the framework is perfect and is not stateless.

[brendanheywood]

Another use case I hadn’t thought of is the home page itself should look broadly like the header that Ulf just posted

Also a route share should hhave an og image of the topo, but cropped down fairly tight to just that route and a bit of margin

[brendanheywood]

Another example in the wild I liked

[brendanheywood]

The infrastructure for this is now in place, and will it be slowly rolled out across the site so keeping this open for a bit longer.