Gutenberg: Starter Page Templates

[koke]

We are building a template selector for new pages created on the mobile apps. We have already started working on our first version, but I think this could be an interesting feature not just for mobile, but for core as well.

Earlier this year, WordPress.com developed and launched a similar feature, via the full-site-editing plugin (There’s a good walkthrough of the broader project and lessons learned in this comment).

I believe this feature makes sense in Gutenberg/core, and would allow third parties to then offer more templates as an added value.

What we are building on mobile

We are trying to start simple to see if the feature is useful to our users and continue from there.

User flows

Designs by @iamthomasbishop:

Phase 1 MVP (milestone)

When a new page is created:

• Initially we’ll start with two templates available: About and Contact. These will be simplified versions of the existing ones in WordPress.com, with only blocks that are currently supported in the apps. We need to find a way to localize these templates.
• We will be developing new blocks in parallel, so depending on the available blocks we’ll likely ship more and better templates on this stage.
• We expect to have Media & Text (shipping on 13.5), Gallery, Spacer, Group (in progress), Columns, and Button (not started). This would enable all of the templates existing in WordPress.com today except:
  
  
  
  • Contact wouldn’t have a contact form
  
  
  • Portfolio would use an image or video block instead of a Youtube embed
  
  
  • Blog won’t be available
  
  
• The editor will show a list of available templates with a series of buttons.
• These buttons will be visible while the post content is empty. If the user starts creating content, they will disappear.
• When the user taps on one of the templates, we will show a non-editable native preview of the template. The user can dismiss or create a page with this template.
• If the user chooses to create a page with this template, the post content will be replaced with the template and the preview dismissed.

Phase 2

In this stage, we expect to have enough supported blocks to have a better offering of available templates.

• The button list will be scrollable, and have a “••• More” button at the end.
• That button will open a full screen selector with all the available templates.
• The user will be able to switch to a different template from the preview screen.

Phase 3

In this stage, we complete the set of existing templates in WordPress.com and set up the necessary systems to keep them in sync.

• When a new page is created on a WordPress.com site, we offer an API-based set of templates, depending on what’s available for that site.
• We will come up with a process to ensure that the apps continue getting updated templates, while ensuring that we only offer templates with supported features.
• A card will be shown in the page management screen announcing the new feature to users. We will consider adding more hints in the onboarding process or Quick Start.

What this could be in core

I think the main idea of the feature would remain the same. Larger screens would benefit from a different UX, since there is enough room to show a preview alongside the templates list.

But more important than UX, I think the bulk of the extra work for core is making this extensible. We would need new API endpoints to expose these templates. We would need hooks for themes and plugins to define their own templates.

We also need to see how this feature fits in all the existing “template” features:

• The current discussion around block templates in #17512 (which are more like template files).
• The existing API to define templates for Custom Post Types or blocks.

In our MVP I started with About and Contact because they feel the most universal of all templates, but this requires more thought and discussion, as I'm not sure what's the right balance for a set of templates bundled by core.

[retrofox]

It's a very nice feature and it worths the try :+1:.
What point that I'd like to suggest is to analyze the previewing performance. Right now the <BlockPreview /> previews just a couple of blocks as maximum. (block styles, live preview in the main inserter).
But for templates, maybe the amount of blocks to preview gets concerning, to the point to make the feature unfeasible.
Take it as simple advice. I don't want to be a killjoy :-D

[koke]

@retrofox thanks for the tip. We don’t plan to use live previews for now, just a modal when the user picks a template. Did you identify what made the previews slow?

[retrofox]

@retrofox thanks for the tip. We don’t plan to use live previews for now, just a modal when the user picks a template. Did you identify what made the previews slow?

Not completely sure why it happens and but it takes the same time to render the blocks into the Editor if I'm not wrong. We're talking about ~2 or ~3 seconds per template depending on how many blocks it has. The problem gets evidence when you have fifteen templates, and twenty-five blocks per each one for instance. Preview all of them increase the time which the process takes.
If I should start to work in the performance, one of a task to I could start to research is a preview mode for each block, getting rid off those elements which are not necessary for the preview (inserter, drop zone, etc) and their functionality.

[kjellr]

Just wanted to note that as @jffng and I have been experimenting with the block-based theme spec over in the theme-experiments repository, we're frequently noticing that we have ideas that will benefit from this concept. Here's a simplified example:

I recently rebuilt the Gutenberg Starter theme to use the new block-templates structure. I'd like to bundle an example layout with it.

My first thought was to bundle this as starter content. This works, but starter content code is a little unwieldy, since it's full of post-content HTML inside of php. Twenty Twenty's Starter content is a good example of this.

To get around that, I thought I'd just have the starter content reference the demo layout as a block template part. This works, but it has two downsides: First, when a user goes to edit the page, the content isn't _really_ there. It's just pulled in from a the file (and currently only displayed with a placeholder, though I know that will change). What I really want is for the content to be imported into the post. The second (and more major) downside is just an inherent problem with starter content: it can really only be pulled in once, when the site is fresh.

This would be much better suited to a "page Template", as described in this ticket. I've been digging around for documentation on adding new templates, but I haven't found anything yet... is it possible for themes to include these at this point? I can see these being really helpful in cases where a theme wants to include some pre-built page layouts to the user.

[jffng]

I also wonder if this could be conceived of as a part of the template creation flow being discussed in #19254

[MichaelArestad]

CC @dwolfe since this relates to the mosaic view.

[mapk]

It appears the UI for displaying the theme templates and generic layout templates is being explored here: https://github.com/WordPress/gutenberg/issues/19254 especially with this comment.

Should this issue also remain open?

[MichaelArestad]

@mapk I think so because I'll be exploring the templates themselves here in detail. It'll help focus conversations.

[noahtallen]

I want to mention that semantics around "template" can be weird.

We are building a template selector for new pages created on the mobile apps.

I believe that the "template selector" outlined in the post refers to different options for default page content. E.g. you have several different options to select from for "about pages" or "contact pages". Selecting an option just changes the post_content of that individual page. The feature shipped to WordPress.com contains what we have now started calling "page patterns" to differentiate from FSE template. (FSE templates define the structure of site pages, rather than content).

I like mentioning these semantics when I see conversations about "templates", because it's very easy to mean different things when we say "template" :)