Edit Site: Creating a new template from scratch

[mtias]

The flow for starting a new template from scratch (for a page, home, archive, etc) is a good opportunity to image how theme creation could work from an editor-first perspective. For example, starting a blank template could likely expose a Grid block, where you can draw the main template part areas in a guided way (header, main, footer, sidebar, etc).

Drawing and laying these out would have both achieved an initial layout and established the necessary structure by creating template parts on the fly.

I think this could be initially a bit more exploratory and incorporate some of the work @epiqueras has been doing on #18600.

[mapk]

At this point, I'm just thinking this through out loud. Template layouts and Template parts feel like a different interface requiring a relevant Inspector that mimics the Block Inspector, but for Templates.

I haven't gone into explorations around a user's path to get to this screen yet, but there's some great exploration here: #19252 about how that might work.

I also took #18600 as a jump-off point with this initial exploration.

While thinking this through, I've come up with:

1. A grid system would be super beneficial for layouts and structure of a page.
2. The Grid block @epiqueras was exploring in Block Editor: Implement a responsive grid mode for InnerBlocks and a basic grid block that leverages it. #18600 could be imagined in these mockups below with this similar functionality: https://strml.github.io/react-grid-layout/examples/6-dynamic-add-remove.html
3. Similarly to the Editor's Document and Block Inspector, we might show something like a Template and Template Part Inspector.
4. The functionality I've included in these Inspectors are not complete.

Template

Template Part

[MichaelArestad]

Nice @mapk ! This is a great start that is getting me thinking.

One thing that sticks out to me is the way a user might add a Template Part (Template Area maybe?). You have it in the sidebar, but it seems to be we could use the block inserter for just this purpose. Perhaps with some premade Template Parts (Header, Footer, Sidebar, content, etc).

The other thing is how we could treat these Template parts nearly identically to blocks in how you select and manipulate them. It's already pretty close in your mockup. I think some minor additions like a block toolbar for changing centering or width along with selection indicators/etc. would do the trick.

What do you think?

[mapk]

Yes, yes, yes, @MichaelArestad, all that!
I was thinking through pre-made template parts as well. It's vitally important. It makes sense to utilize the block toolbar for some of this too! I mean Template Parts are really just blocks anyways, right?

Thanks for this! I needed that push to start going further.

[epiqueras]

Have you tested the current implementation for template parts?

They are blocks that first render a placeholder that lets you choose or create a template part to render.

[jasmussen]

I have some old mockups that are in almost every way obsolete, however they do touch upon the idea of creating new templates from scratch and using a grid. In case ingredients can be reuse in fresh ways, here are those mockups.

[shaunandrews]

I had a quick idea for the Grid setup state and wanted to share:

[epiqueras]

Nice!

Here are some things we need to do:

• We shouldn't limit the grid to inserting template parts. The grid should be a block itself like the columns or group blocks, and they should be nestable for creating complex layouts.
• A Grid block should allow setting a breakpoint at which its children go from adhering to the grid layout to just rendering sequentially. This is significantly easier for users to manipulate and pick up than dealing with different grid layouts at multiple different breakpoints. Most users will have simple designs with a stacked mobile view, but power users can still achieve complex designs by nesting grids with different breakpoints. We might also need a breakpoint at which a grid item is completely hidden.
• Gridlines should be draggable.
• Grid items should be resizable in a snap-to-grid fashion.

[mtias]

We also need to explore here how adding existing template parts would work. Inserter? Special block?

[epiqueras]

After inserting/creating a cell, the cell becomes a button inserter. #20000 has some nice mocks of this.

[mapk]

We also need to explore here how adding existing template parts would work. Inserter? Special block?

To help close the loop here, there will be special blocks for these template parts. They will have default content and will not be editable. #19256

I believe adding these from the Inserter is best. They'll be specific blocks that can only be entered in context of the template building process.

[mapk]

After a discussion with @MichaelArestad and @mtias, there was some consensus around having new templates auto filled with specific template parts like Header and Footer. These could always be deleted, but would give some foundation for building.

From: https://make.wordpress.org/design/2020/05/08/gutenberg-phase-2-friday-design-update-52/

Imagine creating a new template and seeing a screen that already lays out a Header, Content area, and Footer. Clicking on the Content area provides an option of a Sidebar or not.

[enriquesanchez]

Here are some explorations around the first step of this flow, where the user will pick a template to start.

Pick a template

The user would be presented with a variety of templates fo pick from. This would include basic ones included with core (Blank, landing page, etc), the ones provided by the theme, and also templates created by the user.

With the exception of the blank template, basic templates will come preloaded with some common template parts already in place, such as header, content, footer, sidebars, etc.

Because there's no need to have any tools or options on the editor toolbar at this point, I figured we could maximize space by placing the title of the flow there. Maybe we could even move the search field there if we wanted more space below.

I think that this thumbnail view encourages exploration and quick-finding. If the thumbnails are big enough, we might not need a larger preview, which would save steps and clicks from this flow.

Starting with a blank template

Assuming the user selected a blank template on the previous step, we'll need to present the user with a blank canvas and some guidance on what do to next. Knowing that the only possible and logical next step is to add blocks, patterns or template parts (I'm calling these "reusable" in this mockup), I figured it'll be useful to start with the block library already open:

I think this set-up state for the blank template, where the library is opened by default, makes it more obvious for the user to know what to do next and saves them a click.

---

I'll start exploring the flow for other scenarios where the user picks a pre-defined template, but in the meantime I'd love to hear what y'all think.

[MichaelArestad]

@enriquesanchez nice!

Choose a template to start with

This is a really important step that dictates the rest of the flow. A few examples that are top of mind:

If I select a completely blank template, what will I see in the editor?
If I select an existing theme template to copy, will the editor encourage me to duplicate the template parts as well?
If I select a basic template that isn't a theme template, will it have placeholder content for me to replace and modify?

I have done some similar mockups to yours that have similar design patterns. Instead of posting those (because yours convey the high-level ideas well enough), I want to ask some questions:

1. What should the top bar be used for? Should it even be shown?
2. Should previews have a maximum height?
3. Are the previews performant enough to handle 100+ templates at a time if a theme decides to provide a ton of options? If not, what are our options? Paging?

Some thoughts:

• The previews should be large to give us a sense of what the template will look like. Perhaps three column. I realize there is a temptation to fill the space, but having watched many people navigate grid layouts, it's more often than not an inefficient way to view items and often things get missed.
• There are parallels between this step and a potential template manager. While I don't think we should design the two flows to be identical, I do think it would be wise to keep a template manager view in mind when working on these flows.

Blank template

One of the harder challenges is working out what should be shown here.

Questions:

• Should we default the block inserter open? I lean toward yes.
• Should the canvas have a different visual treatment?

Some thoughts:

• I'm not sure should be encouraging the blank state in the UI at all. It should be very rare where a user wants to start completely over with a template. Instead, we could give them head starts with basic layouts prefilled with some basic content/blocks. Perhaps the blank option should be at the end of the list?
• I do expect to show the inline inserter as it's a familiar pattern.

[MichaelArestad]

Concept i2

I'm not quite to the interactive prototype stage. In the meantime, here are a couple mockups iterating on what @enriquesanchez posted.

Choose a template

I've tried a few layouts and formats including lists and sidebar layouts, but I keep coming back to something like this:

• It allows the user to start with a variety of starter templates, theme templates, and user-created templates all organized in a familiar fashion.
• The starter templates I kept a bit smaller and show basic shapes to give the user an idea of what to expect.
• The other templates will have large enough previews to show the user what they are picking.
• I positioned the "Empty" starter template last as I think that's the least likely to be used. At least for most folks.

Blank template

If the user wanted to, they could start with a completely empty template. In that situation, I think the editor might look something like this:

Starter template

If a user picked the "Single column" starter template (or any of the starter templates other than "Empty"), I thought it might be good to preload some content to give the user a head start. Perhaps something like this:

• The header is a super basic layout with the Site title, Site description, and a Navigation block that defaults to showing all the pages.
• The "Main content" block is really a template part where I was trying to give the user some options to give them a head start on building out a page.
• The footer just has a basic colophon.

[MichaelArestad]

Further expanding and iterating on the ideas above:

• The scrolling behavior is shown: Each row can scroll horizontally combined with normal vertical scrolling
• I made the height of the previews uniform. I chose a portrait ratio to display more of the template.
• I added the "Custom" group for user-added custom templates that aren't tied to a theme (or are they?).
• I moved the Basic templates to the bottom. The reasoning is it's unlikely users will want to start with an empty template when they could duplicate an existing template and customize it to their needs.

I also received some feedback that the dark tiles/layouts for the "Basic" templates looked a bit like the active state. Here are some alternate options:

Source figma file and frame

[carolinan]

I like it.

I liked the black basic templates, what is the difference between the normal state and the active/ selected state?

• There needs to be a way for screen reader users to skip to and past the different template groups.
  So that they don't need to tab through every template.

[mapk]

These iterations are coming along nicely!

Choose a template

• I like the concept of horizontal and vertical scrolling. It would translate well to mobile.
• The pathways for building a template look right to me:
  • Select existing theme template drops user on new template with theme's predefined layout and content.
  • Select a basic layout drops the user on new template with predefined header/footer, and a new section/template part ready to go.
  • Select a blank template drops the user on new template with nothing but an inserter and instruction to add a new section.
• Presenting the templates on a white background work well in relation to Gutenberg.
• The lighter grey basic templates feel stronger to me. They remind me of placeholder content, wireframes, etc.
• The topbar is good to keep because it provides a visual consistency, but I'm unsure what the Cog icon or ellipses would be used for at this point.
• The max-height for the previews seems to contain the right amount of visual elements. This one is going to be difficult to nail down without testing it in a PR with actual theme templates.
• Definitely need a "custom user generated" template group. Good call!

I also wanted to link the work @dwolfe did earlier. #20477 It might help think through other options. He focused more on a mosaic layout of templates.

[MichaelArestad]

I liked the black basic templates, what is the difference between the normal state and the active/ selected state?

@carolinan Good question. I haven't gone too far between the various states. There will be an active and a focus state. The focus state will be similar to elsewhere in Gutenberg where the border is blue and slightly larger so the shape and color will change when focused.

I also want to make sure there's a way for screen readers to skip sections. I don't want to make folks tab though them all. What would you recommend?

Thanks for taking a look!

The topbar is good to keep because it provides a visual consistency, but I'm unsure what the Cog icon or ellipses would be used for at this point.

@mapk Yep. I liked them, but I have no use for them at all in this flow... It just felt sort of empty/broken without them?

The max-height for the previews seems to contain the right amount of visual elements. This one is going to be difficult to nail down without testing it in a PR with actual theme templates.

I agree. I also looked into Dave's mosaic views, but I don't think it works as well in this context. I think a mosaic might still make sense when we get into a way to manage existing templates and template parts.

[carolinan]

Either have a visible menu/list of links to the sections below the "Choose a template" heading, as in #20477
or visually hidden skip links.

With lots of scrolling I would find the visible links useful.

[MichaelArestad]

Here's the latest mockup with the grey thumbnails and more labels. I also greyed out the settings and more menus. I think they serve as a nice landmark.

[MichaelArestad]

Here's a longer flow that walks through the creation of a blank template (the goal of this issue):

• For now, I want to initiate the flow through the Template dropdown in the top toolbar. I hope this will change when we progress on the wp-admin sidebar.
• There are various design patterns that this flow touches that I would like to see improved. For now, I stayed fairly close to what is in master.

Naming a new template

I added a naming flow that initiates here.

For now, I tried using an inline form similar to the one @shaunandrews mocked up for the block toolbar.

I have more questions than answer around this:

1. Should it be full width of the top toolbar?
2. Should it even be in the top toolbar?
3. Should the naming/renaming flow instead be part of the save flow? CC @noahshrader

Resizing template parts

I added designs for drag handles and on-demand grid lines very similar to the Layout Grid block and related to the explorations @ItsJonQ has been working on.

There are alternative proposals above that start with drawing on a grid. I think it might be smoother to instead let users insert blocks and resize them to a grid. I think discussion around this should be centered in another issue, but it was relevant to show here.

[mapk]

😍 Love it! I've got some feedback.

• Initiating the flow from the Template dropdown feels like an obvious location for users to find.
• I like naming the template directly in the topbar. However, seeing both a "Done" link and a "Save" button causes confusion. Maybe showing an overlay on top of all the other buttons in the topbar might help. Keep the input centered because that's where the user's focus is already. If the input shifts all the way to the left, it could get disconnected from the action.
• It's great to see a grid integrated. I believe that's needed when editing the structure of the document.
• Dropping in Template parts to create that structure, and then resizing them feels right.

---

This particular view feels awkward to me. I get that when I click away, the Header resumes position at the top. But if I'm just starting out and adding a Header Template part... and the Header is showing space above it in the doc... it leads me to think that it wasn't positioned quite right.

The space above the Header is visually misleading. Is there a way to edit a Header without having it jump down on the page? I think I've seen explorations with the toolbar below the block, or overlapping the topbar. Keeping proper positioning feels important here.

[shaunandrews]

I wonder if we could combine the dual-dropdowns and the document renaming within the Current Document UI proposed in #20877?

[MichaelArestad]

@shaunandrews I think that's a great idea.

[mapk]

In response to my earlier comment above about the space above a Header, I noticed in the current build, the toolbar overlaps a bit but the space is still there.

I think matching this particular mockup you did in the past works better. Although, I'm a little concerned the template part toolbar could get lost in the topbar.

[MichaelArestad]

I backed up a bit with this next prototype. I decided not to focus on the steps to create a template as much as creating the template itself. This is because there are a number of approaches for initiating the flow and I don't want to get in the weeds there just yet.

Concept i3

This should be pretty familiar at this point.

Changes:

• Template parts are inserted at wide width within the editor. I would expect the same of any block inserted at the top level in the site editor.
• Naming and renaming of template parts takes place in the block toolbar.
• I am making a presumption that template parts retain their size preference when being dropped in. In this case, the header is full width.

Further concerns

It is unlikely for folks to start with template parts. Experienced themers and editors will have a good grasp, but most folks will likely start with blocks first. In this case, it needs to be easy to transform a selection of blocks into a new template part similar to the "Group" functionality. Dragging and dropping into and out of containers will also be key to getting blocks into template parts.

Suggested blocks. When in the block editor, it would be useful to suggest blocks like Site Title, Site Tagline, Site Logo, Post Title, Post content, etc. This could reduce the chance of adding a Heading to use as a site title.

Putting variable-width blocks next to each other isn't currently possible. For example, there is no way to put a Site Tagline to the right of a Site Title in a flexible way. I would expect to be able to do that and, if I edit the Site Title, I would expect the tagline to move left or right depending on the length of the title. @enriquesanchez opened an issue here exploring that idea.

Layout Grid

There is a plugin called Layout Grid that allows for similar functionality to columns, but with better controls and a column grid to align content to. I did work with that to create layouts. It may work in the meantime or perhaps even be the basis of what I'm proposing at a document level.

Further recommendations

It is going to be complex to build a template truly from scratch even if all the tools work as expected. There is a high learning curve to understand how to layout the blocks and how templates function. Because of this I recommend we encourage folks to edit existing templates or fork a template when needed. Adding a set of core-provided templates as a starting point would also be valuable.

[jasmussen]

Nice mockups, cool to see work happen. It does seem like the more this gets iterated, the more gravity certain behaviors get, and the less they change between mockups. It seems like embracing the verticality but still leveraging a layout grid is solidifying. Thanks for your perseverence, Michael.

I wanted to raise a transversal topic that is highlighted by this mockup, the need for a color that we know will always work on any color background. In the above mockup, it's the blue gridlines that appear on a yellow TwentyTwenty background, that's fine. But are they also blue on a theme that has a blue background? Currently we are limited to providing colors that are aware of whether the theme is light or dark, and we use these colors in a number of places:

• Spacer background color
• Cover image padding indicator overlay

There are other places where color can be useful to overlay to indicate various actions or behaviors. It would be nice if we could leverage the contrast checker functions to offer an on-the-fly contrast color so we'd know it would always be visible. @jorgefilipecosta absolutely zero urgency here, but I recall you working on adjacent features, do you have any insights on the feasibility of this, and would you like me to create a separate ticket for it?

[carlomanf]

What's the plan for setting the placement of the newly created template in the hierarchy? How will it be done especially in cases where it's not a direct override of a theme template (for example, creating a template for single-post when the theme only provides single?)

Obviously this is all controlled through the slug of the template but I imagine the plan is to provide a more user-friendly mechanism than just a text box? At the same time, given the complexity of the template hierarchy, user-friendliness might be a tall order?

[paaljoachim]

There are a lot of great design iterations happening!
(I have fairly quickly browsed through the various comments.)

Thinking out loud....
What if we had three tabs in the settings sidebar:
Page/Post - Block - Template.

Let's say that I am creating a new page.
I go into the blank page. Click Template tab to switch over to template editing. The focus changes from page over to full site editing. There would be a few options in the template options.
Among them create new template.

The question that comes up what kind of template?
Do I want a page content template?
A site editor template?
Template part template?

Clicking the button to create a new template could then open a template overview such as seen in Michael's above comment: #19254 (comment)
In addition the user would in the new template screen need to choose what kind of template is to be created.

User selects a template and the view would then switch over filling in the template selected.
One begins to fill in what is needed. Then saves the template.
Save as Page template, Page content template, parts template etc.

Being able to by default select page content template, page site template, etc.
One could have the default page template that contains the specific sidebars, header and footer and page content template.

[jordesign]

@mtias Just checking if this issue is still relevant in terms of improving the flow of adding new templates? Or is it covered elsewhere?

[jasmussen]

@jameskoster given the age of this one, and some of the mockups I've seen you create around a pattern assembler for creating new templates, I tend to think we should close this one and revisit grids and template creation as two separate things. What do you think?

[jameskoster]

The template creation experience was improved significantly when we exposed the closest template in the hierarchy as a starting option. Helping further, any patterns associated with that template should appear too.

So yes, I reckon we could close this. Grid layouts are potentially captured in #42385.