Try: Obscure edit-ability of post content blocks in the template editor #31461
Conversation
jameskoster
added
Needs Design Feedback
|
Size Change: +373 B (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
|
I kind of dig this! It's a small change, but in context it does feel right:
Don't mind the crash at the end, I know this is a draft branch and mostlly a proof of concept (though that crash might be in trunk too). I especially like that content inside isn't selectable. I was actually thinking we shouldn't allow the text inside the title to be selected either, when it isn't editable. But on the other hand, that might be a separate conversation. I think this might also be an opportunity to give you a "way out" — we might actually want an overlay with an "edit" button somewhere, which takes you back same as the back button does. But just as a quick smell test, I think this one might have something to it. |
Agreed. I tried to spoof this with
Totally. |
Got it working with the |
|
I added an overlay effect, inspired by the click-through pattern being explored: overlay.mp4It may be a step far, but I think it works quite well. |
|
These blocks are also used inside Query block, I feel some alignments in behavior for that context is needed if we go this route. |
|
Looks interesting! |
Iirc this actually came up in the go/no go call last month. Editing post content inside the query block can be overwhelming. So we can potentially apply this same treatment there. |
|
Love where this is going. A few thoughts:
|
|
I want to note that I appreciate, Jay, that you've been taking the very long view on this all along. I see the steps that have led to this design across your tickets, with this one notably being where the gray canvas (also present when viewing tablet or mobile breakpoints) comes from. That vision helps show the north star. But the north star star is 323 light years away, so we'll have to aim for it and start walking. I sense that in this PR as well, steps towards it. In that vein, I was skeptical that this would work — if you can edit the contents of a paragraph in one context, why can't you in the other? These are the same challenges that led us to drop the initial implementation of the clickthrough interface. Yet it's coming back with what we've learned. And in just trying this PR, it feels better than I had expected. I think it can work.
I think this is a good point, but also one that we should be careful of. The block toolbar has come to mean "you can edit properties of the block you're selecting". Changing the appearance of that is likely going to simply confuse: why is it different now? Especially in context of us separately exploring making the select mode the default in site editors, and potentially this context. I wonder if it would be confusing for that tool to be switched to when you enter the template editor — it'd suddenly show the black toolbars and blue hover outlines, which would be a clear change of context. Would it work? |
|
I don't have anything to show yet, but I'm increasingly optimistic that whatever UI element we introduce to "unlock" edit-ablity in this context will aid the distinction between states. I agree that a double-click is probably table-stakes, but we'd likely need something visual to accompany that. Whatever we come up with, it's important to acknowledge that this UI may need to be bidirectional. It will not only need to facilitate unlocking content in the template editor, but potentially unlocking template (part)s in the content editor as well down the road. In #29864 Matias shared some concepts with a lock icon in the Toolbar:
I'm drawn to the flexibility of this concept as an avenue of exploration here. |
|
That lock icon is a great idea, and offers a space for a tooltip 👌 . |
|
What about just a simpler version of this:
|
I don't think we can put the edit button on top of the overlay, as it will feel very cramped with smaller blocks like Post Date. So we'll need to explore how it can be integrated with the toolbar. Probably something like the lock icon. I'll work on that ASAP.
💯
I think there is room for both. The unlocking UI will assist newer users, and the double-click can be a short-cut for power users. |
|
Couple of options: Edit buttonedit.button.mp4Simple and effective, but I don't think it will scale down very well. Lock icon in toolbarlock.icon.mp4Possibly too in-your-face? The double-click pattern works well here. Unlock in ellipsisellipsis.mp4A less prominent option. This can work well if we anticipate the locking interface being present in list view:
|
|
I prefer the lock icon in the position shown in #31461 (comment), |
|
One issue with that solution is that in this case we still need to display the movers. So in reality it'd be more like:
Which looks a little funky to me. There's something awkward about the lock icon being adjacent to all those unlocked tools 🤔 I do acknowledge that the separate toolbar in #31461 (comment) is also awkward though. For this reason I am leaning towards the ellipsis currently. With an explanation of this concept in the welcome guide, and the double-click behaviour, I think it covers most bases. |
|
That (the lock next to the movers) is also a solution that involved some block editor API because that part of the toolbar is not controlled by the block itself, so personally, even if potentially the best option, I'd leave for a bit later. |
|
If a developer has time to take this over I think it would be cool to see this built out properly, with edit access available to users via the ellipsis: ellipsis.mp4Or list view: unlock.mp4Or by double-clicking the locked block. |
|
Shouldn't we disable the other settings as well in such a mode? For example Inspector Controls and other Toolbar controls? |
|
Good question. I don't think so because in this case the block is part of the template and serves as a vessel for the content. I should be able to update the text justification on the Post Title block in my Page template and know that all pages will reflect that change when I save. Also worth pointing out that these blocks (Post Title, Post Content, etc) cannot actually be selected in the post editor yet. So if the Toolbar / Inspector options weren't present in the template editor then there would be no way to control their appearance in the UI. |
|
There are a lot of alternatives here. Some are easy to find others are more hidden away. Primary action Secondary action Third level action Looking at how important an action is and from there define how visible or hidden it should be. If it is important for the user to locate a specific action then adding it to the toolbar is the primary place to add the action. |
|
Regarding the lock icon.
Let's say that I mix the above with what exists in WP 5.7 and we might end up with something like this from the following issue: #31163 Here we circle back to protecting the contents inside. Adding edit or in this case a lock icon which openly protects the contents inside. The user has to take the deliberate action of clicking the lock icon to unlock the contents for editing. The lock icon is easy to notice. The lock also gives the impression of something being protected. Unlock-to-edit-Reusable-block-contents.mp4 |
Looking at it this way I am not 100% sure that the toolbar is an appropriate position for this affordance. Thinking about a user flow like adding a Query block to a page, primary actions are likely to be:
Editing the content of those posts is unlikely to be a primary action. The same can be said for something like a Post Title block while editing a template. Changing the position, or switching from It's worth remembering that the purpose of the locking mechanism in this scenario is to draw clearer lines between local and global editing contexts. If the lines aren't strong enough I worry that the desired UX will not be achieved. |
|
Closed in favor of #42767 |
Upon engaging the template editor, it is possible to continue editing the post content. This experience can be a bit overwhelming, and blurs the lines between post editing and template editing.
In this (incredibly hacky) PR I am obscuring the edit-ability of blocks like the Post Title, Post Content etc with some CSS. The purpose is to serve as a proof of concept that explores how it feels to make these blocks semi-inert in the template editing context.
content-in-template.mp4
To test:
cc @jasmussen