Site Editor: Improve template part visibility #22064
Comments
|
Agreed. It's very hard for me to tell whether the content that I'm adding belongs to the template part or the regular page content. I usually have to resort to scanning the block breadcrumb at the bottom or the block navigator. I was thinking that something like spotlight mode could work, but that's already taken and works on a block level. We probably need a different visual indicator for this that will allow us to easily discern that we are editing a reusable/global area. I think it should only be toggled when blocks that belong to template part are focused. |
|
I wonder if the same sort of style used in 'spotlight mode' would work well for this (or maybe that + an extra border/outline)? Say that for template parts, the spotlight wouldn't be a toggle setting and that style would always be triggered with the template part selected. Then if the user chooses to enable spotlight mode as well the border would still give some sense of the template part visibility. |
|
@Addison-Stavlo This is something I'm exploring, but it's not my highest priority yet. I would like to see template parts built to function like the prototype here first. Not being able to select the block is a problem with more than just the template part block as well. Really any parent block. There are a few features that have been added to help (like the parent selector) and I've even proposed a persistent sidebar for the block navigator that would aid greatly. What I'm exploring is more around stylistic differences to potentially help communicate the user is modifying something different than the usual block. |
|
Now that we have the inserter design mostly working like that, do we have any more ideas about how to improve visibility?
It's definitely very tough to tell which entity you are editing between page content/template/template part, so I definitely agree that a broader change might be helpful 🤔 |
Not yet. I've experimented with some color changes, borders, and intermediary states (like an edit button), but nothing I've worked on feels quite right just yet. |
|
Spent a moment creating a prototype of how this could work. This leverages bits from Gutenberg—spotlight mode, select mode pattern—and introduces a new mode: Here's a link to a GIF that shows all the elements at work—it was too large to add to GH. Here are static shots of hover states for template parts (header/content/footer) Header Content area Footer Editing template part selection Again, here's a link to a GIF that shows all the elements at work—it was too large to add to GH. Things happening in GIF
A few more things are added to the prototype
On color:
|
There's an existing issue for a Browse mode, which is unrelated to what you're suggesting. It seems you're describing Select mode, and your screenshots/GIF seems to reflect the visual design of blocks in Select mode. |
Yeah. What's in the GIF is the select mode pattern activated on hover, not click. Thanks for sending over a link to the Browse mode issue. It is unrelated. We need to figure out a more seamless way to handle switching between these mode. The mode in the work above is a step between select and edit mode. It needs a name. Hover mode? Ideally hover is just baked into edit and select mode where a person can be in edit mode, hovers over to another block which displays the block label using the select mode pattern , selects it, and lands in edit. So edit, hover, and select work in concert. |
|
These are really great explorations @olaolusoga, thank you! 🎉
Would I only be able to hover over template parts in this mode? If I want to select an inner block, I'd have to click on the template part first? I do agree that visualizing the template parts helps tremendously, and being able to "zoom into" a template part and go into "spotlight" mode feels right, but I do worry that there'll be a lot of clicking in order to be able to edit something, as opposed to just a direct click-to-edit anything. But maybe that's OK and provides the necessary affordance for folks to understand that they're editing inside a template part? If we do some kind of spotlight mode though, would you still be able to drag a block from one template part to another? Re: the "select mode" selection style, I do like that reusing it here avoids the need to learn yet another focus/selection type. I'm however concerned that this could break user expectations, given that "select mode" is a different thing in the editor. If we lean toward a spotlight effect, we could consider using that as the hover interaction as well? Something like this:
|
My concern here is that spotlight mode may already be enabled in a user's editor preferences. In which case only the selected block inside the the template part with be spotlighted (not the entire template part).
This means that leveraging spotlight mode to improve template part editing visibility will only be effective when the user is not using the current 'spotlight mode.' How do we want this to behave when spotlight mode is turned on?
One basic idea would be to cast a semi-transparent box-shadow from the selected template part. This would both help to highlight the template part and still play nice with the current implementation of 'spotlight mode':
Although this may not be very visible with darker themes, in which case we may need to adjust the color/transparency value of the shadow based on the theme's background color. 🤔 @olaolusoga - any thoughts about how enabled spotlight mode would conflict with trying to use the same mechanism to highlight template parts and other options to get around this? |
Depends what layer a person is viewing. Template parts are essential grouped blocks, or a container for blocks that can be used "globally" (across multiple layouts/pages). IMO, template parts are a step above blocks in hierarchy, and having the click-in interaction denotes that order. If we lean into entropy, meaning there is no order, then I don't see the value of a template part—if all blocks are selectable at all levels. We can always build this to feel it out, and iterate. At the moment we have no order, which is leading to a lack of visibility in hierarchy, so we should lean towards introducing hierarchy, which is what the "click-in" step does. In terms of the hover mode, that can be applicable across all levels, meaning I see value at a block level of having hover mode. Reason: "hover" is pretty much "select" mode without the click.
Yup, affordance is key. Entropy is hard to contextualize. We should lean toward affordance, hierarchy, learnable patterns—anti-entropy.
Maybe we don't need spotlight mode. It does help with isolation, but it does make movement between templates more tricky. We can remove spotlight mode idea, while retaining the rest.
Yeah, I think we need to think through the modes more. What is the use case for select mode? What value does it provide users? atm, I don't know/see what use case it's solving for, and it seems low value.
Adding spotlight during hover feels heavy. Would rather not use the spotlight mode than put it into hover. Also, the placement of the label container in what I shared was intentional. It follows same placement of select mode. I think we need to decide if the label container is outside the frame, or inside, not in between. We also need to solve for when a person hovers over the header template part or any block that's flush with the topbar. There was an exploration that bumped everything in the editor down, but we should not do that. |
|
I really enjoy the border around the template part on hover. That said, once a user gets into "edit" mode, that would go away (right?). Should this hover/select mode be always turned on for things like the template part block? E.g. I'm editing my header, but then mouse over the footer. the footer, being hovered, still shows a border and label even though we are not in select mode any longer |
this can also describe "spotlight mode", since very often you aren't focusing on a single block, but a group of blocks at once 🤔 Why would I just want to focus one single paragraph of my essay, fox example. |
|
For now I intend on leaving the modes and other behavior as close to "as is" as possible while improve the Template Part visibility. (In the background I've been looking to potentially combine the modes and improve the block highlighting, but that's for another issue.) Let's start with:In Select mode In Edit mode Notes
Here are some other explorations we should discuss and potentially prototype up to see how they feel:Less intrusive selection label Focus/Spotlight mode Template part notice There's a lot of different combinations here, so there's always the possibility to mix and match. Also it'd be great if we could get a prototype/PR and tweak it as we go. I've prototyped a bunch but it's hard for me to emulate the editor properly. The approach was to start minimally and reuse as much as we can, then build from there. So if we find that things aren't clear enough, we can add to it. Would love feedback and thoughts on this 😃 |
|
In "edit" mode, is any interaction shown when hovering over the header block? I feel like it could be confusing to not have that. Also, in "edit" mode, is the "focus" state for the template part block activated when clicking the block for the first time? I think typically, it by default focuses wherever you click rather than the parent block. Also, I really like the "less intrusive label" and the notice about changes applying everywhere :) I think the default of select mode makes a ton of sense in the site editor (which is more about layout than content), but I do worry that after the user starts editing things, it would be hard for them to get back into select mode. So I definitely look forward to seeing more iteration on that in the future too. Great stuff, though! |
|
I started working on template part notice design # 2 today and saw a UX oddity when rendering notices alongside the template part name panel. It seems like information is duplicated for the user.
It looks like the preference might be to remove and relocate template part name functionality, as described here, and I wanted to call this out to keep everyone in the loop. @dubielzyk |
|
Totally agree. Somehow the hover name and rename panel need to be combined to make things consistent and to avoid duplication |
|
Yeah. As mentioned above we should start with just the border hover and active states. Issue (#23871) kinda sorts the label situation already, but I didn't know when it'd be implemented so I made the label explorations as a backup. The idea was that the label would morph into the block toolbar, but for now, just remove the label :) |
|
Thinking more about the notice options listed in - #22064 (comment): I think the preferred notice format would be the 1st, the snackbar style notice. Attaching notices to the bottom of the template part could be problematic as it may not be visible in a handful of circumstances. Consider scrolling down to start editing the first few blocks in a large footer, the user may leave the bottom of the footer still scrolled off the screen and the notices would never be seen. Similarly, if there are excessively long template parts that have height greater than that of the editor, it would not be likely that they would be scrolled down for the bottom to be visible to see the notice when they start making edits. This may also be the case for similar blocks like Post Content that may require similar notices. The snackbar style is also part of Gutenberg's notices package, and there would definitely be some benefits to use this package and improve on it with extra options where necessary. |
|
Looks like the label and border is introducing more issues than it's solving. Can we try and create a PR with the spotlight mode instead? No label, border, or notice :) @noahshrader @jeyip @Addison-Stavlo Thoughts?
|
Could you clarify the pictures and what you mean by spotlight mode here? Your picture on the left is the box shadow, and the picture on the right is the opacity reduction as enabled by spotlight mode. Do we want both of those to happen at the same time? We did try this previously and I thought the argument was that it was too 'heavy handed'. |
|
Apologies. In both versions I've used a scrim/overlay on top of the content. Left one uses dark, right one uses light. You can achieve a similar result to the white by reducing the opacity like you mention. So there's technically three solutions:
I assume that todays Spotlight mode works by reducing the content (?). If it's easy to code the three scenarios up, we could try them out and figure out which work best. I personally prefer the dark scrim, but I'm assuming that it might make more sense to use Spotlight mode since that's something we already have in place. Does that make sense? :) I made a prototype of the dark and light scrim, but this is one of those things where it's better to make a decision when you can test it in the product :) |
Yeah, it sets the opacity to |
Ah, thanks for clarifying. When I mentioned trying 'both' before, that was dark scrim + opacity content reduction (using a non-sustainable 'hack' on spotlight mode for testing):
Not necessarily. Although it does apply an opacity reduction, spotlight mode is designed to work in a different way across blocks. So if we really wanted to use it here, we would basically have to re-implement it and probably remove the standard spotlight mode from the site editor as it would conflict in behavior.
I agree the scrim highlights the area best, is a bit more simple in theory, wouldn't conflict with spotlight mode, and could work well if done right. But I think we need to think beyond 'dark' and 'light' scrim. The visual effect the scrim has on the content depends on the background and font colors in the editor. Just trying 'color A' and 'color B' against the standard white background will only give us an idea of how they work on a white background. But then if the themes background is gray, tan, black, etc., with different font colors it will not have the same effect. If we really want to use a scrim, I suggest we come up with a way to determine the color as a static setting will not work well across variety. The scrim that is applied's color could to depend on the background color, could be the same as the default font color (as the dark scrim in your example), or perhaps the same as the background color (as the light scrim in your example). If we have a couple ideas of how the RGB values should map from the font/background to the scrim, we could try those across multiple backgrounds/themes to see what works the best. This would be a neat exploration! However, with all that said, that might be a bit to jump into considering there was still a bit of debate concerning whether or not applying these types of backgrounds is too heavy handed (as noted by @jameskoster here - #24557 (comment) - as well as others elsewhere). Similarly, discussions regarding the need for visible indicators (such as the label) seem to be advised to be 'on hold' until the persistent block navigator is in place and its effectiveness can be determined alongside the other tools in the editor. |
This is the main reason I keep referring back to the existing Spotlight mode, which reduces the opacity of elements, rather than a scrim. |
|
Really good point @Addison-Stavlo and yeah, what @shaunandrews is saying makes sense. Spotlight mode will work for all colors and also not clash with the current Spotlight mode, so let's try that out 😊 |
I mean, it will "not clash" if we take the current mode out of the site editor.. which it sounds like we might be ok with? 🤔 I will say the scrim does have the benefit of better highlighting the template part's area (which I do like), while the opacity reduction on its own is a bit more 'fuzzy'. That is, its clear by the reduced opacity that a block is not part of the template part, but is not clear where certain things may take effect such as changing the background color in or around the template part, etc. |
I'm not sure if we should mess with the current Spotlight mode for now. What benefit do we get from removing it from the site editor? I don't have enough context to make a decision in removing it personally.
100%. I personally prefer the dark scrim for this reason too, but I think there's a few others who think it's heavy-handed. Would love to get @shaunandrews @jameskoster @MichaelArestad @olaolusoga thoughts on which of the spotlight modes you prefer. Dark scrim or light scrim/spotlight mode? |
|
If we've decided to go with a spotlight-esque execution then I think the existing spotlight mode effect of reducing the unfocussed blocks opacity seems to be the most flexible - as @shaunandrews mentioned above. It is the most sympathetic approach considering the rainbow of colors that might exist on the canvas. We could do something like use the One concern for me is that if we implement the spotlight-mode effect here, might the purpose of this feature (highlighting a template part) be easily missed by those who already have spotlight mode enabled? What affordances can we make to ensure the effect is just as clear regardless of whether you have spotlight mode enabled or not? I can't help but wonder if there are still unexplored design patterns we might employ here 🤔 |
How about something like #25085 |
|
Can we start with spotlight for now, and improve over time? If we begin with spotlight, we'll then need to respond to any issues that come up as we use (good thing). Also using spotlight seems to be a recurring theme (see comment here from Jul ). If we polled, sentiment would be in favor of spotlight first, and then iterating over time.
That looks good—the spotlight mode usage. Left some feedback . |
Yes, however with every time it is proposed this conflict is raised:
Using the spotlight effect will not play nice with spotlight. There is already 'spotlight mode' so using its visual effect to highlight template parts will conflict unless there is a consensus that we can remove the mode setting altogether. |
|
Yeah I think the breadcrumb template indicator in the top bar would be a requirement for total clarity when spotlight mode is enabled. But if implemented as per @shaunandrews' design, I think we could close this issue? :) |
|
@Addison-Stavlo brings up a good point. We need to address the dynamic when spotlight mode is active and inactive. If inactive, using spotlight feels in conflict with the setting, and vise versa. |
I think there are some other aspects here that are still difficult to work with. For example, how do you know where the template part begins and ends? There would be no indication of this while editing other than directly clicking every block to figure out the first one which is under a different parent. I actually think some of my thoughts in this comment could be helpful. TLDR is that we could rework the block inserter that shows up "at the end of the current block container" to also indicate more clearly where the end of the container lies. Additionally, we don't plan to revisit spotlight mode at this time, nor borders/labels/etc, since we are mostly blocked by discussion. I'm beyond happy to see discussions and design prototypes continuing in issues like this, though! I really think we need to continue iterating to grow consensus before we continue coding. FSE is a tough concept. Unless our users have a good grasp on how it technically works, I worry that they will be thoroughly confused by our current and even upcoming UX. (And we already know that people including ourselves are completely confused by the current UX.) Most people won't have that sort of technical grasp without a lot of research and education. I'm really not seeing us make strides towards UX which is easier for new users to understand. I think we are erring towards not showing information with the goal of a less-cluttered interface. My personal opinion is that we should be showing more information so that folks understand what they are working with. That was the motivation for things like the border, label, spotlight mode, and other experiments. :) At any rate, @Addison-Stavlo, @jeyip, and myself will start looking into the document settings in the top toolbar (#20877). We'll also look into @shaunandrews' design in #25085. Our hope is that these changes (along with the possible persistent block navigation sidebar) could help clarify some aspects of template part usage. As a result, we'll still be making progress on this issue even though we'll be focusing on other things. |
|
There are a lot of great ideas here! It would be great to create a PR with a MVP and get it out into the wild for testing and feedback. As it would make it possible for a broader range of people to test it out. Is it possible to create a kind of gutenberg.run where one tests out multiple draft PR's to gather feedback? Kinda like a prototype car. One can probably drive it and in general test it and it might or might not get into the general production. Having a kind of gutenberg.run to test out multiple features being built would be very helpful and make it easier for additional people to test out the draft features that will likely in one way make itself into the general Gutenberg plugin. |
|
Note: when I say we, I mean myself, @Addison-Stavlo, and @jeyip. We are working together as a squad. :) @paaljoachim we've created multiple PRs to test these ideas over the past several weeks :)
This PR combined several of the ideas into one "prototype car," as you say: #23406 A lot of folks gave feedback on those prototypes, and we weren't able to get enough consensus to move forward with most of the propositions. So we're going to look at the document settings in header proposal in hopes that:
|
To illustrate the boundaries of the template part, it looks like a spotlight effect is employed when blocks inside are focussed. |
|
Sounds like we're more in agreement that spotlight mode is a better solution to this problem. I agree with @noahtallen that it's still not 100% clear where the boundaries of the template part begin/end. Is it possible to get a PR with what we've discussed above? That way we could all have a play with it and hopefully reach a conclusion? |
|
A rough spotlight mode version was implemented in #23406 which theoretically still works :) So I think you could use that to play with it. "proper" support for this interaction would take a lot longer, and we're shifting to a different project so I don't think we can commit to that right now. I'm not convinced we'll be able to reach consensus on a spotlight mode solution at this point, especially since other improvements (like the document settings in the header) aren't in place yet. So it would be tough to see how it fits in. But obviously, if anyone wants to pick this up, go for it! |
Is your feature request related to a problem? Please describe.
When editing a full page template, it is not possible to see where a template part begins and ends.
When adding new blocks or moving blocks, the only way to know for sure that you are editing the correct template part, is to hover over the preview in the template part drop down menu.
I would like to be able to move blocks with ease by just dragging them from one template part to another. This is nearly impossible today.
Describe the solution you'd like
Add a border to indicate where the template parts are.
This needs to be visible but not distracting, and it needs to work with themes with different background colors.
Describe alternatives you've considered
Selecting a template part and editing that alone is an option, but it is slower and it does not give you the overview of the full page.
The text was updated successfully, but these errors were encountered: