Implement AMP Stories

[davisshaver]

ISSUE 1: As a WordPress author, I need to be able to manage content for AMP stories using Gutenberg.
Key PR: #1215

• AC1: I should be able to create between 1 and n pages for AMP stories.
  • At this time, n is assumed to be up to 20 pages (though this is not a hard limit).
• AC2: I should be able to rearrange pages inside AMP stories.
• AC3: I also, within each page, need to be able to create x number of layers (CTA, grid layer, etc).
  • x is assumed to be up to 5 layers at this point, but is not a hard limit.
  • Only one CTA layer is allowed, and the interface should anticipate this.
• AC3: I should be able to rearrange layers inside AMP pages.
• AC4: Within each layer, I also need to be able to set layouts (thirds, fill, horizontal, vertical, etc.)
• AC5: Also within each layer, I need to be able to add my own blocks which are allowed by AMP (e.g. paragraph, image, video, etc).
• AC6: I should be able to preview the AMP story within the editor. I should also be able to edit each page next to each other. The current mode should be obvious to the author (edit or preview).
• AC7: I need a basic way to set default animations on pages, layers, elements for an AMP story.
• AC8: Each setting panel for each level (page, layer, element) should be clearly labeled as a user navigates through and selects them. There should be an intuitive way to be able to navigate through them. There should be an intuitive way to move items through layers if needed.
• AC9: I need a clear way to understand what I’ve selected is being edited. For example, a border or shading around an HTML element clearly shows a web browser console selecting that DOM element.

AMP Dependencies

• Expose lifecycle of AMP components to enable constructing them dynamically Expose lifecycle of AMP components to enable constructing them dynamically amphtml#17548

Gutenberg Dependencies

• Nested blocks (see Blocks: Support block nesting (Add Columns block, InnerBlocks component) WordPress/gutenberg#3745 and InnerBlocks)
• Locked post type block templates
• Restricting blocks to given post type: Extensibility: Pass the post object to allowed_block_types filter WordPress/gutenberg#6208
• Child blocks: Introduce Child Blocks WordPress/gutenberg#5540
• Allow block to be constrained to only be used in root (when it has no parent): Allow block to be constrained to only be used in root (when it has no parent) WordPress/gutenberg#7845
• Default block, but only within a parent/outer block: Default block, but only within a parent/outer block WordPress/gutenberg#7573
• Default Appender that is not Paragraph Based: Default Appender that is not Paragraph Based WordPress/gutenberg#8589
• Blocks: Consider a "passthrough" supports for nested block wrappers: Blocks: Consider a "passthrough" supports for nested block wrappers WordPress/gutenberg#7694
• Show block breadcrumbs for selected block when inline toolbars are enabled: Show block breadcrumbs for selected block when inline toolbars are enabled WordPress/gutenberg#6459
• Promote table of contents for navigation of nested blocks Promote table of contents for navigation of nested blocks WordPress/gutenberg#9053
• Using dispatch( 'core/editor' ).selectBlock for a nested block focuses on its inner child instead: Using dispatch( 'core/editor' ).selectBlock for a nested block focuses on its inner child instead WordPress/gutenberg#9212

Resources

• Search Engine Land coverage
• AMP Story docs
• Example AMP Story from Washington Post

[westonruter]

Yes, this has just been talked about for the next major version, perhaps 0.8. In particular we're wanting to implement AMP Stories support via Gutenberg blocks. In short, we'd register a new amp_story custom post type. Then this post type would have a fixed template allowing for a single amp-story block. This block would be nesting, allowing for amp-story-page blocks inside of it. These blocks would then in turn allow for amp-story-grid-layer blocks.

[davisshaver]

Wanted to share what Mic product open sourced today. A story format in JSON. https://github.com/micnews/story-json

Not suggesting that we detour to their format. But they have built something very cool on top of this: a story JSON to video tool. https://github.com/micnews/story-json-to-amp

This could be a great feature for AMP WP too, or an extension plugin.

[davisshaver]

Example story via Washington Post: https://www.washingtonpost.com/graphics/2018/world/amp-stories/imprisoned-journalists-around-the-world/?hpid=hp_no-name_no-name%3Ahomepage%2Fstory

[westonruter]

Gutenberg dependencies (moved to description).

[westonruter]

Since AMP stories require that a singular <amp-story standalone> be located directly under the body as the only child, this means that whenever a proposed amp_story custom post type is being served we need to make sure we serve a custom template that lacks the header, footer and anything else which would normally get added to a template.

[postphotos]

Hi @davisshaver (great to see you at #wcpub, thanks for attending our workshop!!) and @westonruter:

1. just a heads up I've added a proper user story and acceptance criteria here.
2. Please note that in ticket [WIP] Introduce amp-story support via Gutenberg blocks #1215 we've got a very early prototype and UX work discussed.
3. As we continue development, we'll continue to update this epic ticket with additional WIP updates.

[postphotos]

@jwold - can you add your designs to this ticket?

[jwold]

Howdy! Wanting to share an update to the work that @postphotos, @westonruter and I have been working on for the past couple of weeks.

Last week we created a clickable prototype that outlines the following things:

• What an AMP Story admin interface would look like in a WordPress Gutenberg context
• How you would create pages in an AMP story
• How you would create layers, and add in elements
• How you would manipulate, add to, and delete parts of each of those.

You can view the prototype here: https://xd.adobe.com/view/a789ebeb-d577-4646-79f0-5db7bb4b5760-d1b8/

This assumes that all upstream dependencies (in the Gutenberg project as well as AMP itself) are unblocking this work.

We'd love feedback on this. @miina and @westonruter have started development work this week on implementing the features listed in the prototype. You can see updates to the PR on #1215 and #1347

We're considering gathering user feedback based on the proposed UI so far. From a UI perspective there are still items to work through, including the animations. We'll followup here with the next update.

cc @amedina

[davisshaver]

Super exciting :).

re: NUX, I had to google what a page/layer was in AMP Story format. Maybe the Gutenberg help tip UI could be extended to explain this on first use.

[jwold]

Thanks for the feedback! Help tips are absolutely needed. I started adding those into the Balsamiq sketch, but hadn't yet brought those over to the prototype (these are completely outdated, but they'll give an idea):

[Calebj7]

@jwold I think the direction these designs are taking is excellent! I'd love to assist and lend my experience with the UI and animation aspects of this project. Let's connect later and discuss what that could look like!

[jwold]

@Calebj7 that sounds great! The next big piece is to nail down the animation part. What do we want animation to look like, what's MVP, and what are ways we could improve it.

[jwold]

Howdy folks! A few days ago I shared a link to an XD prototype, but would also like to include the .png files for easy reference. There are still some things to figure out, but this represents where we now stand on the UI.

Page 1 ^
The thinking for the UI is that it'd be a custom post type in WordPress/Gutenberg. When we go to the custom post type we're greeted an AMP Story page with some pre-added content (similar to the Gutenberg demo). There's a few elements that will immediately stand out to us. We can see the first page, and the layers within that page on the right hand side. We can also add a new page. If we tap on the background of the page, we'll be taken to Page 2.

Page 2 ^
Once we've selected the page we're shown a border show up around it, with a tag showing the top layer within it, along with the elements within that top layer being temporarily highlighted. The sidebar will also open, showing the options available to for animation and changing the layer. The basic thinking behind this layer structure is the little cards on the side of the page allow us to tap on that layer and then edit elements within that layer without it causing click confusing for elements on a layer above or below it. Now, if we tap on the "AMP Stories" headline, as the green circle shows, page 3 will show us what will happen.

Page 3 ^
Now that we tapped on the headline we'll be shown the sidebar options available to manipulate the headline settings, and we'll see that the top layer card is selected. If we then tap on Layer 1...

Page 4 ^
... We'll see the settings for that layer. Now that we're on Layer 1 notice how the text has disappeared, you're now just seeing the content on that layer, and the content in the layer above it is hidden. We can tap on the background again in Layer 1, and...

Page 5 ^
... we can now see the settings for an element, specifically the block cover image. If we then tap on "Page 1", which is shown as a card below the layers, we'll see...

Page 6 ^
... All of the settings for the page.

[jasmussen]

Thanks a lot, @jwold, for sharing those mockups. Very cool work!

The buttons on the bottom right — are those useful with the sidebar closed, or a different sidebar open? Or do they automatically open the sidebar if it's closed? If so, how does that work on mobile or in small responsive breakpoints?

I love your mockups, and I love they involve the main canvas. This solution feels a very tailored specifically to AMP stories, though — which is perfectly fine, but that means it should be implemented on a per-block basis. The reason I'm asking is because I'm looking for a solution that makes it easy to manage nested blocks for any block that has nested blocks, not just AMP Stories, and in this case the UI while intuitive for a very tall block seems to scale less to less tall blocks.

One of the things I explored in WordPress/gutenberg#9053 (comment) was the complete reliance on the sidebar for managing layers. The idea being that you can use the block without opening the sidebar, but advanced configuration requires it. That gives a little more space to work with sub-blocks/layers/child blocks.

Brainstorming a bit, another thing the block level allows us to, is to show additional content below the block when selected. Here's a dirty sketch:

Essentially when the block is not selected, you'd see more or less a preview of the block itself. As soon as you select it, you can see any child-blocks linked as "tabs" or quick thumbnails below, which you can then select to configure. Deselect the block again to preview.

Another option is to us a modal for this — add a button to the toolbar of any block that has child blocks and opt into this advanced selection mode. Then you can open the modal to manage layers/child blocks.

What do you think?

[miina]

Hi, @jasmussen, thanks for your comments.

On implementation of the buttons on the bottom right: At this moment the idea is to implement the buttons on the bottom right as part of the nested root block (Page 1 on the mockup). This means that it would be independent of the sidebar and always display the root block itself (Page 1 on the mockups) and it's first level children (Layer 1 and Layer 2 on the mockups). The buttons group itself would be implemented as a separate component which could be added to any block, this makes it possible to use it with any other nested block as well.