Gutenberg: Edit Site: Present "placeholder" blocks clearly

[mtias]

When using the edit-site editor, there will be many blocks that are "tokens" for content that is going to be loaded dynamically. This includes blocks like post-title, post-content, post-date, and so on, since there is no specific post to show when in template editing mode. The clarity of this design — which is different to the placeholders shown in content blocks like images or cover — is crucial to understand when you are _editing a template_ and _when a specific page_. This needs a few design explorations to see how close or how different it should be from current block placeholders.

[jorgefilipecosta]

Hi @mtias, I removed the Hight Priority label just because it is not blocking for the next WordPress release.

[mintplugins]

@mtias Just to clarify my understanding, are you are saying that placeholder blocks need to represented in a unique way that is different than non-placeholder blocks?

[jasmussen]

Just to clarify my understanding, are you are saying that placeholder blocks need to represented in a unique way that is different than non-placeholder blocks?

When we use the term "placeholder block", we usually refer to the gray blob you see when you first insert an Image block, it comes from the Placeholder component. This is also called a setup state, and is something that many editable blocks can benefit from.

In the case of these blocks, post-title, post-content, post-date when seen in a site editor context, these are different and more literally a sort of _placeholder content_, lowercase P. The text and content of those blocks won't be editable in the site editor, compared to things like headings and paragraphs. Therefore it seems sensible to explore a visual presentation that implies this.

[johnstonphilip]

Should we consider giving these blocks a unique name? I heard them referred to as "Full Site Editing Blocks" in the last theme-review meeting.

Here's a few other possibilities:

• Wireframe blocks
• Theme Blocks
• Template Blocks

[mapk]

While thinking about block placeholders today, I fiddled around with a variation in this Figma files: https://www.figma.com/file/hRTrdVwYqi0QwcSdo3gnZt/Full-Site-Editing-%E2%80%93-Post-blocks?node-id=95%3A0

I was thinking about the placeholder blocks and how they would differ from regular blocks (ie. more simplified, no user-generated content, basic) and also thinking how these might be explored in a template.

So in this prototype, I've basically added my placeholder blocks to my template and am now laying them out a bit.

Prototype
https://www.figma.com/proto/hRTrdVwYqi0QwcSdo3gnZt/Full-Site-Editing-%E2%80%93-Post-blocks?node-id=95%3A3913&viewport=880%2C105%2C0.5&scaling=min-zoom

[mtias]

That's an interesting approach but I think it deviates too much from the goal of having visual fidelity. It'd make it impossible to design the template without loading a post or page.

[shaunandrews]

Here's a mockup that goes from empty placeholder blocks, to blocks with content. When you select the content block (or one of its children) a search input appears that lets you select a post to show in the template. This is/was a quick mockup, but I could see there being some similarities with the new Link UI, following those patterns when searching for a post to show.

[jasmussen]

Your mockup skills are solid, Shaun! It's very helpful to convey the point.

This iteration feels like it well explores the idea that is _generic placeholder-esque template building blocks_.

Another approach that seems worth exploring is the same idea, but with _actual placeholder-content_. Real text, real images.

The latter potentially has the benefit of being a better live preview as you're building the template, instead of having to switch back and forth between preview and abstract block-architecture. It also addresses the challenge of hardcoded content — i.e. let's say I want every post to have social links at the bottom, preceded by a paragraph of text that says "Follow me on social media:" — that seems to be a situation that's worth thinking about.

[shaunandrews]

Here's an updated GIF, which shows the post selection within the Template toolbar (which I guess _is_ a Grid block in some ways) and uses placeholder content to help show a more realistic preview of the template:

[jasmussen]

This is really quite enlightening. It feels like you are zeroing in on the right puzzle pieces, and that some of the pieces are starting to connect.

I wonder, are we settling in on the grid-of-tiles way of creating these templates? If yes, what plan do we have for making this keyboardable / work for low-vision users? Are there other approaches to building a template?

That's not necessarily to say that this isn't the right way, just that it feels like due diligence to explore all avenues before settling on one.

[shaunandrews]

are we settling in on the grid-of-tiles way of creating these templates?

There's been a few explorations on the grid over in https://github.com/WordPress/gutenberg/pull/20000#issuecomment-589775867

On that thread, I touched on keyboard usability. Here's the concept I posted there:

One of the early designs used a more table-like UI that allowed you to interact directly with the gridlines.

Are there other approaches to building a template?

I think the grid-of-squares UI works well, but would be open to other ideas for building a template. In some ways, I'm thinking of the Template essentially being a Grid block with special powers.

[jasmussen]

The work you've done here, and the work that's gone into the grid block itself is beyond impressive, and it's very probably the right approach. My only hesitance is that there are layouts it can't accomplish, like overlap or crazy animated cells or other things. But arguably that's not the role of the grid block.

[mapk]

Overlapping functionality would be amazing here! For example, if I created a Feature Image section and then wanted to add the Post Author block to overlap it.

Maybe we need to think about a Placeholder block that works similarly to the Cover block in this case? One that would allow nested placeholder blocks.

[johnstonphilip]

One thing that I think is important to keep in mind with this somehow, is how responsive breakpoints might work. But I think that's probably a top-level thing we need to get a handle on site-wide, and things like this (and global styles) could utilize that where needed.

[mtias]

This is going a bit on a tangent. It is not about how to build or assemble a template, just about how the individual blocks present themselves when they have no user content loaded. Should it just have dummy content or descriptive content ("Post Title Goes Here")? Should it look exactly the same as it will look with real content? Should it always load the latest item (like a blog post)?

[shaunandrews]

This is going a bit on a tangent. It is not about how to build or assemble a template, just about how the individual blocks present themselves when they have no user content loaded.

I apologize for the tangent, but without understanding how the flow works (which includes building a template) its hard for me to design the placeholders in isolation.

Should it just have dummy content or descriptive content ("Post Title Goes Here")?

I think a mixture of both could make sense. For blocks that we expect would contain a small amount of placeholder content, we could be descriptive. This descriptive text can help people indentify the placeholders, avoiding confusion over what is _real_ content, and what is _placeholder_ content. For blocks that we expect to contain a large amount of content, we could start with a short sentence of descriptive content followed by some public-domain content (like a book or short story).

Another option is to use public-domain content and prefix with the word "Placeholder:":

Should it look exactly the same as it will look with real content?

I believe so, yes. As much as possible, the placeholder content should resemble _real_ content.

Should it always load the latest item (like a blog post)?

Its possible we could load the latest post automatically for the Post template, or the latest page for the Page template — but I think trying to be clever like that could actually be more confusing. The flow would be more consistent if we defaulted to placeholder content all the time, with an easy way to choose _real_ content to preview the template.

[mtias]

I apologize for the tangent, but without understanding how the flow works (which includes building a template) its hard for me to design the placeholders in isolation.

A good example would be loading a template the theme has defined for displaying posts in the site editor. The user didn't build anything, they are just looking at a template. What should they see?

[mapk]

A good example would be loading a template the theme has defined for displaying posts in the site editor. The user didn't build anything, they are just looking at a template. What should they see?

If this is the case, should the theme just provide the placeholder content? It would act similarly to a theme providing a block pattern. They would provide the layout of the pattern and the content to fill it.

I wonder if another case can be presented. Say I'm building a template from scratch. I want to layout a post template and use blocks to achieve the structure. I go to add an Author block, but because this isn't a true post, an author can't be identified. This is the part that is questionable. Does it just conform to dummy content as mentioned? If yes, maybe that should be the standard. In which case, we'll need to have all this dummy content defined.

Is the dummy content editable in the template building mode? If I add a Post Content block, and dummy content populates like a couple paragraphs and an image. Can I edit that content?

[mtias]

If this is the case, should the theme just provide the placeholder content? It would act similarly to a theme providing a block pattern.

No, I don't think so, because a block might be used that the theme didn't account for. The theme could provide demo content and that could supersede whatever the default is, but we still need a default. ("Hello World", or something else.)

It might be interesting to consider also teaching how things work through this content. "This is the content of a post. Posts are published in chronological order and can be used to write a blog, journal, or news section of a site."

Can I edit that content?

No, dummy content should not be editable.

[mapk]

@mtias, you've helped both define the dummy content and answered the question about it being non-editable. That provides some direction for us, thank you!

Here's a list of dummy content that will be visible in the template:

• Post title: "Hello, World!" or something like "This is a heading"
• Post author: "WordPress Admin" or ?
• Post date: current day's date.
• Post content: Instructional text that helps teach. Add an image that's maybe a screenshot referring to the text.
• Post comments: The default comment that comes standard in all WP installs.
• Post comment count: 1
• Post comment form: the form

I can help get this content written. My other question is can we make this content generic enough so that it doesn't apply to a post or page, but can apply to both? I imagine I should be able to use the same template block placeholder for the title of a post that I use for the title of a page.

So instead, maybe it's:

• Title placeholder
• Content placeholder

[mtias]

Another thought, we could tie this "dummy" content with the example attribute, so it's the same that would show on the inserter preview when inserting one of these blocks.

[mtias]

Example of how it looks like at the moment:

[dwolfe]

I tried to approach this with a fresh mind, but I ended up covering a lot of the same ground that @shaunandrews did. I generally favor abstract, descriptive placeholders for simple fields (ex. "Post Title" for post title, etc.) and illustrative placeholders for complex and non-text elements (ex. anonymous avatar for author profile photo, the comment body from the example comment from the default install, etc.).

I did have one additional idea to share: the toughest content to represent in the abstract is the Post Content, because that could be literally anything. What if that's the one field we don't try to abstract? I wonder if that would be a useful place to allow the user to populate the template with actual content:

To be clear, those posts in the list would be the user's actual posts.

[mapk]

Interesting take, Dave! I was curious if updating the Post Content from the block would feel awkward when that content updated all other blocks on the page. It doesn't feel bad. I might have to fiddle with it myself. Do you have the prototype link?

What if that's the one field we don't try to abstract?
I think the other field that isn't being abstracted is the Post Date block, right? I think keeping the Post Date block visible as an actual date works well regardless of all other blocks.

Also, can you share how each of the Post blocks look without actual content (of course they can include the placeholder content whatever that may be). For example, I don't see the Post Featured Image block in the prototype above.

Maybe mockup how each of these placeholder blocks (without content) would look, one on top of the other similarly to the list Matias shared above.

• Post Title
• Post Featured Image
• Post Date
• Post Content
• Post Author

[olaolusoga]

Thanks for sharing @dwolfe .

Like the idea of inserting post content into the template, but also see the issue @mapk is highlighting on the jump feeling weird when a person moves from a post, to the post template. Seem like something worth exploring more down the road.

Till then we should consider strictly using dummy content. I think what you have in the mock above works well. The block content should be more instructional and/or contextual so it provides value and guidance, vs arbitrary text.

To get this issue read for dev, a few things we should land on:

• Can we define/design what each of the placeholders listed (Post Title, Post Featured Image, Post Date, Post Content, Post Author)above will look like with dummy content? This can be done individually—so share mock of each in isolation—then share a design with all blocks included in a template.
• When mocking up the full page with the blocks, it'd be great to see the dummy content included in the inserter preview. We only need to show an example of one block being inserted to capture the idea of the dummy content in the previewer.
• We should keep this scoped down to non editable block—so just dummy content. Though the live post content idea is great, that feels more birthday/wedding cake than cupcake.
• Let's get all those in this issue before EOD March 30.

@mapk @mtias do we know who will work on this on the dev side?

[MichaelArestad]

Maybe mockup how each of these placeholder blocks (without content) would look, one on top of the other similarly to the list Matias shared above.

Can we define/design what each of the placeholders listed (Post Title, Post Featured Image, Post Date, Post Content, Post Author)above will look like with dummy content? This can be done individually—so share mock of each in isolation—then share a design with all blocks included in a template.

I definitely agree with that route. I would stick to just placeholder content in a block context (each item is a placeholder block).

When mocking up the full page with the blocks, it'd be great to see the dummy content included in the inserter preview. We only need to show an example of one block being inserted to capture the idea of the dummy content in the previewer.

I agree, but I think that's a future task.

We should keep this scoped down to non editable block—so just dummy content. Though the live post content idea is great, that feels more birthday/wedding cake than cupcake.

Viewing live post will likely be the default in most scenarios. Placeholders are sort of an edge case when creating a new template or working with a template that lacks any page/post content to populate it.

[mtias]

I've pushed these to the current title, content, and date blocks to get things moving:

[dwolfe]

Do you have the prototype link? (@mapk)

Figma is here.

I think the other field that isn't being abstracted is the Post Date block, right? (@mapk)

"Abstract" wasn't the best word. Maybe what I should have said is "try to represent authentically". Showing today's date in the Post Date block lets you see what that content will look like, just like (any) text in the Post Title block will. I only meant to suggest that maybe we shouldn't try to represent the Post Content, because its infinite variability makes it unique.

Also, can you share how each of the Post blocks look without actual content (@mapk)
Can we define/design what each of the placeholders listed (Post Title, Post Featured Image, Post Date, Post Content, Post Author)above will look like with dummy content? (@olaolusoga)

Yep, coming right up! A couple of notes about the mockups below:

• You'll see an icon at the end of the placeholder content in its unselected state (), which I thought would help differentiate these fields, which can't be edited, from hardcoded content that _is_ editable, like @jasmussen's "Follow me on social media" example earlier in the thread. I think it works well enough for the examples below, but there are definitely fields for which it doesn't work as well, like Author Avatar. Just an idea.
• I've followed the current behavior of the editor with respect to block controls and borders in the selected state. Just to focus the feedback, this work is about the content of the fields.

Post Title

I'm assuming that the user could transform the Post Title into whatever text block they want to use - paragraph, heading, etc. But it's most likely that it'll be a heading, no? I've shown it here as a heading block, as a default.

Post Author

In the Twenty Twenty theme, Post Author is one item in an inline list which also includes the Post Date and the Comment Count. But If the user is inserting it from the block inserter, outside of any containing block, I think a paragraph block makes the most sense, because it doesn't presume how the user wants to use it.

Post Date

A few of us now have suggested that this should default to today's date.

Post Excerpt

This is my one attempt at educational/instructional text, which also happens to be a good stand-in for live content. This is 55 words long, which is the default for automatically generated excerpts.

Featured Image

Wireframe-y image placeholder - I'm assuming it would be resizable, and that the dimensions shown here in the label/overlay would update as the image is resized. As a default size, I used the width of the content area in the Twenty Twenty theme (610px), and a 16:9 aspect ratio.

Categories

When laying out and/or styling a template, I think it would be useful to see multiple items for list/group fields, to show spacing between the individual elements. Styling here is the default for the Twenty Twenty theme.

Tags

Same as Categories, styling is from Twenty Twenty.

Post Content

Explained in previous comment above.

[dwolfe]

Note: Please ignore the block toolbars in the examples above - I didn't think very much about what those should contain, I just wanted to include _a_ toolbar to show the selected state. The block toolbar discussion is happening on this issue, and the above isn't a proposal for that.

[mapk]

@dwolfe, I believe what you have here is good to get into a PR. My biggest question is around how it feels to manipulate the blocks without editing the content. This experience would be best in a PR. Once we get these in, along with the toolbar questions figured out, we can determine if more needs to be done to signify these are just placeholders and not actual content... until content gets added of course.

Because the toolbars aren't dialed in yet, there still remains some questions around things like the Post Author Placeholder block's avatar. I imagine I should be able to turn on the avatar in the placeholder block and just get the generic Gravatar image.