Amp-wp: Discovery of what/where/how of edit-ability related to supporting AMP Story Page attachments

[MackenzieHartung]

[miina]

Starting to look into this.

[westonruter]

As we chatted about last week, the MVP for this could be to just allow a given page to link to another post/page at the story page level as an attachment, and that when the story page is viewed the content from the linked post/page could then be displayed as a story attachment. This would avoid the user from having to leave the context of the story to access the desired content. If this were done, then the embedded post/page content would probably need to be explicitly embedded inside of a blockquote with a cite attribute and link at the bottom pointing to the original location. This would avoid duplicate content warnings, and an added benefit would be that it would more easily allow direct linking to the attached content.

[westonruter]

If we take the subsequent step of allowing attachment content to live inline with the story page itself, then this could be done in addition to a previous ability to link to an existing post/page as attachment content.

[miina]

Maybe it would be good to make the Page Attachment already live within the page itself since that's likely something we'd like to provide in the future as well, considering that Page Attachment allows all kind of different 3rd party video embeds and social media embeds, etc. Note that both the CTA Layer and the Page Attachment have to be the last elements of the amp-story-page so we could do the following:

• Add a new Page Attachment block which could be available only if the CTA block hasn't been added.
• This block could have the available options for the Page Attachment as sidebar settings: title, theme, CTA text
• We could replicate the looks of the Page Attachment in the editor, display it in the bottom of the Page with the Attachment's CTA visible. If it's clicked on, the Page Attachment opens and covers the relevant page.
• Additionally, the Page Attachment block would have an inner block for embedding other posts/pages from the site, this could, for example, appear when the Page Attachment is open.

We'll likely want to allow adding other inner blocks for the Page Attachment in the future as well, this way we'd already create the basis for that, however, we could start with just this one embed option as @westonruter suggested (Edit: meaning here as the only option for inner blocks).

Thoughts?

cc @swissspidy

[miina]

This is currently a discovery task only. Is there a preference for creating a separate issue for the actual implementation or could we just adjust the same issue for that once the what-where-how has been confirmed?

[swissspidy]

Some links for reference:

Documentation: https://amp.dev/documentation/components/amp-story/#amp-story-page-attachment
Best Practices: https://amp.dev/documentation/guides-and-tutorials/develop/amp_story_best_practices/#add-additional-content-with-attachments

---

I'm wary of just adding a page embed option somewhere as it would be a rather bad user experience.

I like the suggestion of creating a proper new block for this. Its functionality is similar to the CTA one, so we can re-use most of the logic there.

Examples of the page attachment feature show that there can be lots of content in it. It almost feels like opening a new web page. That's where such an embed option makes sense. However, there could also be just a single video in the attachment for example.

If the content is simple enough, that would be a case for inner blocks where one can add all sorts of texts and images. Probably in a linear way and not drag & drop, which could be quite challenging to implement.

So focusing on an embed option first sounds good to me. The question is just how that would work in detail.

The risk of duplicate content has been mentioned. Perhaps we could avoid that by providing a separate post type for attachment contents? A post type that would likely only allow a subset of block types.
Also, how is the embed information stored? Should it just save a post ID in a block attribute and then we display the_content() dynamically?

Perhaps we can find some stories in the wild and see how they use the feature? That would give us a better idea of what authors would expect.

tl;dr:

• Creating a proper block makes sense either way
• Start with a simple embed option, but find out how to best implement that.
• Let's do some research

[miina]

The risk of duplicate content has been mentioned. Perhaps we could avoid that by providing a separate post type for attachment contents? A post type that would likely only allow a subset of block types.
Also, how is the embed information stored? Should it just save a post ID in a block attribute and then we display the_content() dynamically?

In case of embed it should probably be the post ID for storing, initially, we could just display the excerpt + featured image for example. The full post content wouldn't fit anyway (most likely) (EDIT: looks like it allows scrolling endlessly, so anything would fit). Later we could also give the editor a setting of what to display, as a setting, e.g. content / featured image/excerpt, or some template-like options.

Let's do some research

👍

[swissspidy]

Is there a preference for creating a separate issue for the actual implementation

I would say so, yes. Makes things less noisy.

[miina]

Let's do some research

I was trying to find some live examples of AMP Stories using Page Attachment and couldn't find any really. Looked ad CNN, Telegraph, Washington Post, PCGamensN and some other sites that came up in the search as using AMP Stories but couldn't see any using this feature.

This is a relatively new feature, perhaps it's not in use yet? Let me know if you should find any.

Otherwise, we could use

• Title + featured image + excerpt (for giving more control to the editor / avoiding duplicate content).
• Or as Weston suggested:

explicitly embedded inside of a blockquote with a cite attribute and link at the bottom pointing to the original location

[swissspidy]

Let me know if you should find any.

Asking on the AMP Slack channel...

[swissspidy]

Got some nice feedback!

Here are a few examples of stories with attachments:

• https://www.washingtonpost.com/graphics/2019/lifestyle/travel/amp-stories/a-locals-guide-to-what-to-eat-and-do-in-new-york-city/
• https://www.nationalgeographic.com/amp-stories/stonewall-riots-50th-anniversary-lgbt-gay-pride-stories-resistance-resilience/ (swipe up to watch videos)
• https://tappable.co/s/tokyo/story.html
• https://foodaciously.com/amp/recipe/black-beans-and-sweet-potatoes-falafels/story (swipe up to get nutrients information and detailed ingredients list)

The Foodaciously story is interesting because it shows the same ingredients list on multiple pages, always also linking to the full recipe page:

The WaPo story uses it to show some details for the currently shown place:

Whereas on Tappable the attachment content is way longer:

[miina]

Awesome, thanks for checking, @swissspidy!

Based on the examples, it continues to seem to me that perhaps for starting we could use the title, featured image, and the excerpt of the post for embedding, also linking to the full story. Excerpt would give more control to the editor, also, most of the Page Attachments don't seem to include too long content.

However, that's something that could be changed relatively easily -- to display the full content within cite instead so maybe that's something that we can figure out on the way, that doesn't change the general approach of implementing Page Attachment.

To conclude, we could:

• Create a custom block for Page Attachment.
• Replicate the looks of FE in the editor.
• Selecting the Page Attachment block in the editor would open it (the same way as in FE) and reveal the inner blocks.
• Add block settings for title, CTA text, theme.
• Allow just one inner block for now: post embed (search input, will store the ID)
• The embed will display either full content in cite or some selected data, e.g. title, featured image, excerpt.

[swissspidy]

Sounds good to me.

We'd render the embedded post dynamically anyway, so this could use a template that can be overridden by theme authors.

@miina Can you create a new issue with this summarized approach that we can use for the actual implementation?

[miina]

Looks like we already had an issue for that, added the information to there (#1973).

[swissspidy]

Excellent. Totally forgot about that one. Marking this discovery ticket as done.