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

Reusable block: Adding more functionality to Settings #30357

Closed
critterverse opened this issue Mar 29, 2021 · 7 comments
Closed

Reusable block: Adding more functionality to Settings #30357

critterverse opened this issue Mar 29, 2021 · 7 comments
Labels
[Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.

Comments

@critterverse
Copy link
Contributor

Hi all, I’m looking into a couple of different issues that are currently being tracked in Improvements to Reusable Blocks #27890:

Reusable blocks are both a post type and a type of block. Typically, the options for each are separated in the Settings sidebar via a content/theme type tab (left) and a block tab (right). The functionality proposed in the above issues (Revisions, “Move to trash”) is usually shown when viewing options for a content/theme type, such as a Post or a Template.

Options shown in the Settings sidebar for a Post and Page
Options shown in the Settings sidebar for a Template and Template Part

Note that theme elements like Templates and Template Parts currently show these options when accessed via the management screen in wp-admin, however not when accessed from the FSE navigation.

A common thread is the "Status & visibility" panel but those options feel sort of confusing in the context of Reusable blocks (and possibly Template Parts). I wonder if there could be a different panel shown in these instances that emphasizes the custom name field and other locations of the given block (and other options if needed):

advanced-panel.mov

The existing tab logic in the Settings sidebar works well within a proposed isolated editing view, where the Reusable block can be viewed as a content/theme type:

Isolated editing view for Reusable block

It gets a little weird when the Reusable block is viewed in its regular context as a block — but maybe RB's are a special case in which panels usually related to a content/theme type (like Revisions) also appear as block inspector panels.

In that case, the division/hierarchy between primary and secondary tools when editing a Reusable block could be:

Reusable block selected with ellipses popover menu open from the toolbar and location menu open from Settings

Toolbar (primary)

Inspector (secondary)

  • Advanced panel
    • Custom title
    • Location menu
    • Manage Reusable blocks
  • Revisions
  • Move to trash

I tried separating out the “Move to trash” item at the bottom of the inspector to see if that reads as a more universal action. Note that this would take the user to the post type management screen, where they can undo/recover items from the trash.

Here’s a Figma prototype stitching everything together.

Open questions:

  • The "Move to trash" action mirrors the current behavior of deleting a content/theme element but maybe it's not necessary to take the user back to the post type management screen if there's a snackbar that allows for an immediate undo/recover from trash
  • Is having links to "Manage Reusable blocks" in both the ellipses menu in the toolbar and in Settings overkill? Both are one-click removed from the default view so I included it in both locations for increased discoverability 🤔
  • Thoughts on the ability to view other locations of the given block as a part of Settings vs. within the post type management screen? The thinking was that this could be another opportunity to reduce the back and forth between the editor and wp-admin.
@jameskoster
Copy link
Contributor

I still don't think that converting to regular blocks is a primary action, but it's not a hill I will die on :D

maybe it's not necessary to take the user back to the post type management screen if there's a snackbar that allows for an immediate undo/recover from trash

I think the snackbar approach would feel more streamlined. Especially if you consider situations where there are unsaved changes to the document. If we were to send folks to the RB list view on trash, we'd first have to ask them if they want to save their changes. It could all get very convoluted very quickly.

Is having links to "Manage Reusable blocks" in both the ellipses menu in the toolbar and in Settings overkill?

I think this is fine :)

Thoughts on the ability to view other locations of the given block as a part of Settings vs. within the post type management screen?

Despite breaking a convention (somewhat – it's not really a setting), this doesn't feel un-natural. Then again I wonder if there's all that much value in displaying the actual entities. Are there any common flows that would lead a user from editing one post consuming the RB, to another?

Taking another step back, when is it important to know how many instances of the block exist? I'm probably missing something, but I think I'd be most interested in this when trashing the block – I'd want to know how many posts/pages will be affected. If the value is minimal then perhaps its not worth breaking the convention?

@critterverse
Copy link
Contributor Author

I did some further exploration based on helpful feedback from @jameskoster about it being slightly weird to highlight the other locations of the given block directly from the inspector (as it’s not actually a setting).

I imagine the most common flow for the location menu would be to do a gut check across other instances to make sure that the changes you’ve made to the Reusable block in one location look ok elsewhere. Maybe a better placement for this menu is the top toolbar within the isolated editing view (typically used for template information in the FSE)?

isolated-top-toolbar.mov

As for the remaining functionality in the Settings sidebar, I tried out a fun idea that incorporates the custom name field into the block description area (for Reusable blocks and/or potentially any block with custom naming ability). Borrowing the “ellipses” treatment proposed by @javierarce in issue #29575 [comment], additional actions could be incorporated into this area via a popover menu:

rename.mov

There could potentially be multiple ways to access the live text area — by a “rename” action in the ellipses menu and by double-clicking (similar to the way custom naming works in Figma, Photoshop, etc). This could help to integrate the custom name field (which is currently kind of an outlier/doesn't appear within a panel) while tying it to other global options that appear in the popover menu.

Lastly, I looked at the “Moved to trash” snackbar approach, which seems to work well for the main editing flow. (However, I wonder if it does still make sense to send the user to the post type management screen when trashing the block from an isolated view.)

trash-snackbar.mov

Here’s a prototype looking at all of this together.

Other notes:

@jameskoster
Copy link
Contributor

Putting the consumption locations in the top bar works quite well. I can see the same pattern being used while editing a template part to outline the top level templates that consume it. I wonder if the labels could use a little more clarity though?

Ellipsis and trashing seems good too. I'm just a little anxious about not having some kind of confirmation upon trash. Is it clear and obvious enough that this will affect other content?

@jameskoster
Copy link
Contributor

Just driving by to add weight to the idea of putting the consumption locations in the top bar. I've been exploring something similar to indicate which items of content use the template being edited:

Screenshot 2021-04-15 at 10 39 03

@critterverse
Copy link
Contributor Author

Thanks @jameskoster, moved this discussion over to #30622 for the potential Reusable blocks and Template Parts implementation 🚀

@skorasaurus
Copy link
Member

re: Toolbar convert to regular block - there's an issue for that at #30993

@jordesign
Copy link
Contributor

Closing this issue as so much has changed in the form of Reusable Blocks/Synced Patterns that much of this seems to be resolved. With no further discussion in 2 years - any remaining issues can be opened again referencing the current state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

4 participants