Closed mtias closed 1 year ago
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: https://github.com/WordPress/gutenberg/issues/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:
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?
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.
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.
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.
I had a quick idea for the Grid setup state and wanted to share:
Nice!
Here are some things we need to do:
We also need to explore here how adding existing template parts would work. Inserter? Special block?
After inserting/creating a cell, the cell becomes a button inserter. #20000 has some nice mocks of this.
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. https://github.com/WordPress/gutenberg/issues/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.
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.
Here are some explorations around the first step of this flow, where the user will pick a template to start.
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.
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.
@enriquesanchez nice!
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:
Some thoughts:
One of the harder challenges is working out what should be shown here.
Questions:
Some thoughts:
I'm not quite to the interactive prototype stage. In the meantime, here are a couple mockups iterating on what @enriquesanchez posted.
I've tried a few layouts and formats including lists and sidebar layouts, but I keep coming back to something like this:
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:
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:
Site title
, Site description
, and a Navigation
block that defaults to showing all the pages.Further expanding and iterating on the ideas above:
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:
I like it.
I liked the black basic templates, what is the difference between the normal state and the active/ selected state?
These iterations are coming along nicely!
Choose a template
I also wanted to link the work @dwolfe did earlier. https://github.com/WordPress/gutenberg/issues/20477 It might help think through other options. He focused more on a mosaic layout of templates.
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.
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.
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.
Here's a longer flow that walks through the creation of a blank template (the goal of this issue):
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:
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.
😍 Love it! I've got some feedback.
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.
I wonder if we could combine the dual-dropdowns and the document renaming within the Current Document UI proposed in #20877?
@shaunandrews I think that's a great idea.
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.
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.
This should be pretty familiar at this point.
Changes:
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.
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.
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.
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:
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?
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?
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: https://github.com/WordPress/gutenberg/issues/19254#issuecomment-661220403 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.
@mtias Just checking if this issue is still relevant in terms of improving the flow of adding new templates? Or is it covered elsewhere?
@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?
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 https://github.com/WordPress/gutenberg/issues/42385.
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 https://github.com/WordPress/gutenberg/pull/18600.