Support Basecamp

[alinaboghiu]

We now have several hundred structured recipes. Can we surface these on the website? @frederickobrien will organise a chat with WebX and CoPip - please raise your hand if you want to join (will also mention in stand up)

[cemms1]

Background info

The Basecamp team want to surface recipe metadata in a script tag in articles to improve their discoverability. The plan is to use schema.org so that Google search will show Guardian recipes as rich result cards.

There was an experiment to implement this with some static test data, so now that we have structured recipe data in CAPI (for the Feast app) we can take advantage of this properly. The aim is to reimplement this but in such a way that all articles with structured recipe data can benefit from the improved SEO on web.

The way we bring in schema.org data at the moment is via Frontend (link here). There's a question over whether it would be better to bring this into CAPI or not. The benefit of this is that the team with the most expertise in structured article data (CoPro) would be able to direct how this is done. The drawback is that this type of schema.org structured metadata is really only valuable for the web and thus might make most sense to be managed by the WebX team, in the repo(s) that are closest to where it's being used.

Implementation options

Option 1: combine with existing LinkedData in frontend

1. Retrieve structured recipe data in frontend via CAPI
2. Add recipe structure to LinkedData model
3. Add recipe data to LinkedData.forArticle method
4. DCR will automatically receive this through the linkedData object in the model (see here)

Option 2: pipe recipe data all the way through to DCR

1. Retrieve structured recipe data in frontend via CAPI
2. Send whole structured data through to DCR in the DotcomRenderingDataModel
3. Update DCR data model for frontend to consume this field and create the schema.org object as a new <script> tag in htmlPageTemplate

Option 3: create recipe metadata object in CAPI itself

1. Retrieve the recipe metadata schema.org object from CAPI response in frontend
2. Either steps 3) and 4) from Option 1 or steps 2) and 3) from Option 2

@frederickobrien

[paperboyo]

Yay! Just a note from someone who knows next to nothing, but Option 3 feels wrong to me: we already have other data passed from tools to page metadata (eg. IMDB, ISBN), and while some work and some do not (or haven’t survived migration to DCR), none of that has fully formed page metadata in CAPI. I guess it feels more correct, and better, for frontend/DCR to be responsible for (a common) shape for all page metadata.

[cemms1]

After a chat on 22/02, the confirmed approach is option 3 mixed with option 1:

• Retrieve the recipe metadata schema.org object from CAPI response in frontend
• Add recipe structure to LinkedData model
• Add recipe data to LinkedData.forArticle method
• DCR will automatically receive this through the linkedData object in the model (see here)

[davidfurey]

Is there a doc that explains the rationale behind this decision?

[frederickobrien]

Is there a doc that explains the rationale behind this decision?

The thinking on the CoPip side is best summarised in this Trello card comment written up by @fredex42 after discussions with @JustinPinner. If that's inaccessible I've made a copy of it in this Google Doc.

More generally the consensus seemed to be that taking care of this in CAPI then passing it along was preferable for a few reasons:

• As few additions to Frontend's workload/complexity as possible. It even lays the groundwork for other schema generation to be moved over in the future
• CAPI is already aware of the expected shape of recipe data, whereas doing the transformation in Frontend or Dotcom would mean they also have to be tuned in to the model. If we're handing over valid schema then the site can just render it