[AMP Stories] Research Reusable Blocks as they pertain to templates

[miina]

Understand the current state of reusable blocks, and what needs to be done to use them for Travel/Fandom templates.

Plan Sprint 4 Templates features.

[miina]

Notes from looking into reusable blocks for using templates, and looking into how other plugins that are using templates / template-like blocks.

On reusable blocks:
Reusable blocks don’t seem to be the best way how to implement templates, the purpose of reusable blocks is basically to give the user the ability to combine blocks that they use often so that they could reuse those combinations. Each reusable block is saved to DB as a post ("wp_block" post type) that can then also be deleted / edited by the user. This would mean that if we would add a reusable block with the plugin installation then these reusable blocks could still be modified / removed.

If we are looking to create predefined templates that would be static and always available then reusable blocks aren't necessarily a good solution for the AMP Story templates.

Other plugins

Plugins checked:

• https://wordpress.org/plugins/design/
• https://wordpress.org/plugins/otter-blocks/
• https://wordpress.org/plugins/ultimate-addons-for-gutenberg/: also checked this briefly due to its popularity, however, this has mainly only custom blocks and doesn't seem to be using nested blocks too much.

Design plugin:
How the templates work in this plugin -- it's basically creating sets of blocks which have predefined values. The Design plugin is only using the pre-existing core blocks and doesn't add any new custom blocks. This means that all the blocks added can be adjusted and removed, there are no fixed or forced sets of blocks and values.

These templates or predefined sets of blocks are available in the Plugin Sidebar (right sidebar in the editor).

Otter plugin:
This plugin creates both custom blocks and also templates, the same logic as the previous plugin -- sets of blocks with predefined values which can then be removed or adjusted, without having forced / fixed blocks / values.

The Ultimate Addons Plugin:
I looked at this since it had a higher number of downloads, however, this seems to mainly create custom blocks with a fixed set of inner fields.

Potential implementation for templates for AMP Stories.

1. The default Inserter in the upper Toolbar is quite empty right now, it only has one Page block and that's it, at the same time it's quite convenient for adding new items. One option would to create Page Templates as custom blocks -- one block could basically consist of a Page with predefined inner blocks (templates).

For example, we could rename the current "Page" block to "Blank Page" and then add (under relevant categories) other blocks, such as "Travel Map Page", etc.

2. It could be useful when starting a new AMP Story to create a few pages prepopulated with sample data if chosen.

For example, when the user first creates a new Story then the user could be asked if to start the AMP Story based on
a) Empty template,
b) Travel Template,
c) Fandom template,
etc., and then based on the choice, either an empty Page would be displayed (as it is now) or a few pages prepopulated with sample data which would form a starter story for the chosen category.
This could be done via just creating a set of prepopulated Pages with sample data (as the Design Plugin does for example).

For asking the user which templates to choose there are different options, among others:

• Displaying a modal ( <Modal> component) when landing on an empty story first;
• Displaying just a meta block with the relevant choices until the choice is made;
• Probably the least intrusive: having a button "Select Template" (potentially which could then open <Modal> for choosing the template.)

3. Additionally, we could use the Plugin Sidebar of the editor for adding the pre-defined template sections as it's done in some of the other plugins. The downside of the Plugin Sidebar might be that it's not so visible / discoverable, not sure how many people would realize it's there without knowing it before or without being pointed to that direction. Also, it needs more clicks for adding blocks, however, it can have a nice preview and good structuring, also can be used in combination with other options.

Thoughts?

cc @swissspidy @westonruter @kienstra

[swissspidy]

Thanks for looking into this!

Reusable blocks don’t seem to be the best way how to implement templates

I feared as much :/

If we are looking to create predefined templates that would be static and always available then reusable blocks aren't necessarily a good solution for the AMP Story templates.

I guess at some point we'd want to make these extensible, but a list of templates stored somewhere in a file is probably the most straightforward solution.

Templates will be created using the existing stories editor, from where we can use the resulting serialized HTML, plus a decent preview image.

When you select a template, the serialized HTML is parsed and the resulting blocks are inserted on the page. After that, you should be able to customize the blocks just as if you built the page on your own. (see #1902)

NB. This might involve uploading images from the template to the media library as well, not sure.

For asking the user which templates to choose there are different options, among others

I think we have explored this already a bit in the mockups. On a fresh post with an empty page, there should be a button to select the template.

Also, the inserter in the top right corner of the editor area would be modified to show a list of templates to choose from, in addition to a "Blank Page" template.

We can further discuss the UX part with @dawidmlynarz on Slack.

[miina]

Templates will be created using the existing stories editor, from where we can use the resulting serialized HTML, plus a decent preview image.
When you select a template, the serialized HTML is parsed and the resulting blocks are inserted on the page. After that, you should be able to customize the blocks just as if you built the page on your own. (see #1902)

Do I understand correctly that you're thinking that we could manually create the templates (using the editor) and then use the HTML of those blocks to create static templates for the users?

[swissspidy]

Do I understand correctly that you're thinking that we could manually create the templates (using the editor) and then use the HTML of those blocks to create static templates for the users?

I think so, yes.

[miina]

Based on our last discussion it seems like we are looking for an experience where the editor would have some static templates available (either multiple pages or single page templates or both) and in additionally they could use reusable blocks to create their own templates.

For the static templates we could use a modal as shown in the mockups, probably it would be ideal if the user saved templates would also appear there, under a different category for example.

Considering the timeframe we have then perhaps we could approach the templates as a step-by-step iterative process and break it into different issues? For example, the first step could be just the single-page static templates, the second step could be adding reusable blocks which would also be pulled into the templates interface, the third step could be adding multi-page static templates (which likely wouldn't be technically more complicated than single-page but would take some time to think through the preview and creating the templates from a Story / UX perspective so that they would make sense to the editor).

This way we can continue the discussion and figuring the best way out while we're already building the first part of it and would ensure that we have at least part of the templates working well in time.

Let me know if breaking the templates into different tickets/iterations makes sense to you.
cc @amedina @swissspidy @westonruter

[swissspidy]

Oh yes, totally needs to break it down into smaller, more actionable issues.

So far we only have #1902. But there need to be issues for finalizing the templates, actually creating them (using the editor), the functionality to insert them into the editor, etc.

For the static templates we could use a modal as shown in the mockups, probably it would be ideal if the user saved templates would also appear there, under a different category for example.

There's also an inserter component in the mockup that includes a search form. I think that one would make sense as well from a user perspective, as it's closer to the existing insertion UI in the block editor.

[miina]

There's also an inserter component in the mockup that includes a search form. I think that one would make sense as well from a user perspective, as it's closer to the existing insertion UI in the block editor.

Agreed, especially if we have a lot of templates or if the user can add their own templates.

How about the following issues? Breaking this out now will make it easier to discuss each part under the relevant ticket, e.g. missing blocks, the approach for reusable blocks, etc.

For the basic static templates, first step:

• Create custom blocks needed for the templates (likely to have sub-tickets) (Issue [AMP Stories] Editor includes all additional blocks to satisfy the Fandom and Travel story creation needs #2007);
• Show list of templates and allow selecting and inserting templates from Modal (doesn't need to include final static templates yet, could include sets of blocks created via createBlock as a proof of concept), basically [AMP Stories] Show list of templates to use when inserting a new blank page #1902;
• Implement missing features required for the templates (perhaps background opacity, text rotation, etc., likely to have sub-tickets) ([AMP Stories] Add any missing features necessary for templates #2013)
• Create ready static templates based on design, the initial ticket could have only a few templates (would include creating the final templates + preview in the template inserter + categorization possibly) ([AMP Stories] Create the base templates for Travel and Fandom #2010);

For the reusable blocks, second step:

• Allow the user to save custom templates (e.g. leveraging reusable blocks, this would include the custom templates showing up in the template inserter) (Editing/removing templates (Reusable blocks) #2011);
• Add search functionality which displays results for both static and user-created templates (Allow searching templates #2012);

For when we still have time after the reusable blocks:

• Add more static templates;
• Add multi-page templates;

Some of these already exist as notes, I can convert those to issues for enabling discussion.

Thoughts?

[swissspidy]

SGTM!

[miina]

Added #2007, #2013, #2010, #2011, #2012.

[westonruter]

Reusable blocks don’t seem to be the best way how to implement templates, the purpose of reusable blocks is basically to give the user the ability to combine blocks that they use often so that they could reuse those combinations. Each reusable block is saved to DB as a post ("wp_block" post type) that can then also be deleted / edited by the user. This would mean that if we would add a reusable block with the plugin installation then these reusable blocks could still be modified / removed.

What if the templates provided by the plugin don't work for me? What if I want to change something about them? Or what if I don't want all of the templates and I want to remove some? Those all seem valid to me. There could be a way to re-import reusable block story templates in case the user needs to go back.

I like that with reusable blocks there is a clear mechanism for users to add their own templates using the existing infrastructure.

But I see you're still suggesting to use reusable blocks for user-generated templates, so I think we're on the same page.

[miina]

What if the templates provided by the plugin don't work for me? What if I want to change something about them? Or what if I don't want all of the templates and I want to remove some?

If the user would want to change something about the templates it would, for example, be possible to add a template, modify it, and then save as a custom template (reusable blocks). Do you think that would make sense?

In case of wanting to remove some: one option could be to use similar logic as there is for managing blocks now: WordPress/gutenberg#14224. Initially, we could just add a checkbox "Hide default templates". Do you think this would make sense from UX perspective?

[amedina]

Let's sync before making a final decision on the path to be followed. The fact that reusable blocks can be modified or removed may not be a good enough reason to discard their use for implementing templates. Even if we have other options, reusable blocks still may be a good use case.

[amedina]

If the user would want to change something about the templates it would, for example, be possible to add a template, modify it, and then save as a custom template (reusable blocks). Do you think that would make sense?

Yes; that makes sense. That would satisfy both having a set of fixed templates, and also provide the flexibility of reusable blocks for user-generated templates, or modifications to the static ones.

In case of wanting to remove some: one option could be to use similar logic as there is for managing blocks now: WordPress/gutenberg#14224. Initially, we could just add a checkbox "Hide default templates". Do you think this would make sense from UX perspective?

This part I am not sure. If we give the user the ability to remove static templates, then why not having them as reusable blocks to begin with?

[westonruter]

If the user would want to change something about the templates it would, for example, be possible to add a template, modify it, and then save as a custom template (reusable blocks). Do you think that would make sense?

Yes, that would be fine. Only slight painpoint would be the potential for templates being listed which I don't want anymore.

In case of wanting to remove some: one option could be to use similar logic as there is for managing blocks now: WordPress/gutenberg#14224. Initially, we could just add a checkbox "Hide default templates". Do you think this would make sense from UX perspective?

I suppose there'd either be a checkbox to hide the defaults or for there later to be a button to restore the default templates. I'm not sure which is better. My guess is that a user would more frequently want to modify a default template for their needs, and that they would rarely need to re-import the original story templates.

So personally I think it would be better if everything was a reusable block and then if the user messes up the story templates and wants to get them back, they can just click the “Manage All Reusable Blocks” link in the inserter:

And then they can be taken to this admin screen where we could have a new button to Re-import Story Templates like:

Aside: If a user tries to open one of the reusable blocks there to edit, they'd probably get an error because they'd be trying to edit story blocks outside of the amp_story post type. That would be complication of using reusable blocks for story templates. Perhaps the solution would be to allow story blocks to bootstrap when editing the wp_block post type in addition to the amp_story post type.

[miina]

This part I am not sure. If we give the user the ability to remove static templates, then why not having them as reusable blocks to begin with?

It could be a Toggle for hiding the default templates, e.g. if the user is working on a Story and has created a bunch of templates to work with and the Template Inserter is overloaded with all the templates, then the user might click "Hide default templates" for "cleaning up" the Inserter view.

However, when the user would then start another Story and would want to see the default templates again as a starter, "Hide default templates" could be turned off to choose from examples.

This way the user can hide the default templates but doesn't lose these in case of starting a new Story and needing those again. (Just an idea, I don't feel necessarily strongly about it.)

So personally I think it would be better if everything was a reusable block and then if the user messes up the story templates and wants to get them back, they can just click the “Manage All Reusable Blocks” link in the inserter:

Sure, that's fine, too. Maybe the link for managing templates could be in a more accessible place to make it more intuitive. Also, the user should probably be able to filter the Reusable Blocks then by templates and "normal" reusable blocks? I'm a little bit concerned about making the process confusing for the user, maybe there is a way to simplify it, e.g. if everything would be linked from the editor's templates modal ( edit / remove icons per each template preview which would then directly link to the right page instead of the list view of Reusable Blocks). Thoughts?

Re-Import would then add the default templates again in addition to the already existing ones, right? Or well, any template where the content isn't equal.

[miina]

Are you thinking that the user should manually import the initial default templates as well? Meaning that by default there would be no templates in the Template Inerter except for the Blank Page?

[westonruter]

This way the user can hide the default templates but doesn't lose these in case of starting a new Story and needing those again. (Just an idea, I don't feel necessarily strongly about it.)

Yeah, I don't know. Hiding the default templates doesn't seem so necessary. The user should know which templates they created so they should easily be able to identify which templates are the defaults.

Re-Import would then add the default templates again in addition to the already existing ones, right? Or well, any template where the content isn't equal.

That's right. It could just re-create reusable blocks for any that don't exist in identical form.

Are you thinking that the user should manually import the initial default templates as well? Meaning that by default there would be no templates in the Template Inerter except for the Blank Page?

No. I think the default templates should be automatically inserted. But just that if they want to restore the initial default templates, they could do so via that screen.

[miina]

The user should know which templates they created so they should easily be able to identify which templates are the defaults.

That might depend on how many templates we'd want to add by default 😄

[miina]

Closing this issue since it looks like we have come to a conclusion and also planned Sprint 4.

Feel free to open if it feels like we should discuss more.