Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Starter Page Templates #18055

koke opened this issue Oct 22, 2019 · 5 comments

Starter Page Templates #18055

koke opened this issue Oct 22, 2019 · 5 comments


Copy link

@koke koke commented Oct 22, 2019

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, 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).

Screen Shot 2019-10-22 at 10 05 43 12133ccb41d2406aa887e198b5fd3565

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:

blueprint-starter-page-templates-android-i2 30648a03ae9a4746bb23c84a54060b46

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, 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 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 and set up the necessary systems to keep them in sync.

  • When a new page is created on a 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:

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.


This comment has been minimized.

Copy link

@retrofox retrofox commented Oct 22, 2019

It's a very nice feature and it worths the try 👍.
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


This comment has been minimized.

Copy link
Contributor Author

@koke koke commented Oct 22, 2019

@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?


This comment has been minimized.

Copy link

@retrofox retrofox commented Oct 23, 2019

@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.

@koke koke mentioned this issue Nov 13, 2019
2 of 5 tasks complete
@MichaelArestad MichaelArestad added this to Needs design feedback in Full site editing Dec 6, 2019

This comment has been minimized.

Copy link

@kjellr kjellr commented Jan 20, 2020

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.


This comment has been minimized.

Copy link

@jffng jffng commented Jan 20, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Full site editing
Needs design feedback
5 participants
You can’t perform that action at this time.