Updates the template mode canvas padding and adds a back link #30658
Conversation
youknowriad
added
[Type] Enhancement
|
I think the next step after this PR is going to be improvements about the saving flow. It seems based on the mockups and also because it does feel right that we'd want to keep the saving flow similar between the default mode and the template mode, because we can just go back and forth between the modes, so probably just use the "multi-entity" saving flow in both cases if there are multiple entities to be saved. |
|
Something we might want to start thinking about in terms of design is how to unify the "template" in the sidebar with the original template selector we have in the "page attributes" panel of the sidebar. These are ultimately the same things and we need to unify somehow. |
|
Size Change: +367 B (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Thanks for working on this Riad. In general this works as advertized and might just need some design input.
What this testing of the PR made me think about more, is the issues with saving flow in relation to the history (undo/redo). They are unrelated to the PR but they need more work.
packages/edit-post/src/components/header/template-title/index.js
Outdated
Show resolved
Hide resolved
Some explorations for this can be found in #27850.
Totally. On a somewhat related note, with the introduction of the <- Back button inside the frame, we can probably remove the "Cancel" button from the Top Bar. I think there's a lot of value in the Top Bar remaining consistent as one flips between the two editors which means the primary button should have the same label wherever possible, and the Preview menu should be added when editing a template. There is also the question of whether the "Template" tab from the site editor should replace the "Post" / "Page" tab in the Inspector accordingly. I appreciate these changes will need to happen in follow-up PRs but figured they were worth noting none-the-less. |
There was a problem hiding this comment.
In terms of actually merging this PR, I think it would be good to implement an interaction where clicking the frame deselects all blocks.
Edit: We also need to consider what to do when the background color is close to (or the same as) the frame color. Something like a subtle shadow, or a stroke can help:
A more extreme option would be to allow users to manually select a color of their choosing.
|
It does feel like the frame is a bit too dark too (especially behind the back link) so maybe we should consider restoring the higher one @jasmussen |
|
Agreed. I think we can tune things. I'd love a @mtias sanity check as well. |
|
I've updated the PR, used a lighter background and added a light shadow as well. clicking the frame also deselects the block and I removed the "cancel" button. This is ready for another review. |
|
Joen and I did a bunch of exploration around colors for the frame on Friday (figma) and settled on the following:
With this configuration the edge of the canvas is always visible, even when the theme background matches the frame background or the canvas border. It also has a very small footprint in terms of introducing new UI since the border color matches other UI elements. As an acid test I mocked this up using all the various designs we've shared in recent weeks that include the frame concept. I used the Eskell theme as an example, and tried an inverted version as well:
You can take a closer look in the figma file here. This is by no means presented as a final design. But it feels like a solid foundation upon which we can build and iterate. |
Yep, by "settled on" I'd like to clarify that we explored numerous options. White background, black background, drop shadows, various colors, all of them came with opportunities and tradeoffs, and none of them solved the problem in a blanket way. The black/dark background did look promising, especially when bleeding in to the top toolbar. But when the inspector was then opened, that needed to invert as well, just like the toolbar. Which is to say that's an exploration we can still do, but it's a much bigger mouthful. Before proceeding, I'd love thoughts by @mtias as I think he's thought about this lately. |
|
I applied the suggested colors, the border colors feels a bit off to me though, I'd prefer a darker one or a shadow. This feels a bit blurry. |
youknowriad
force-pushed
the
update/template-mode-canvas
branch
from
f04e511 to
b3ff8bc
Compare
|
I guess, there's no perfect solution, the blurriness is visible in a theme like 2021 with the green bg but it's decent in a white bg theme. |
|
For me this is good :) Let's see what Matias says. |
|
I still want to try the darker background which I think offers a stronger separation, but we can do that separately. The placement and the wording of the "Back" button doesn't seem great to me. One thing that jumps to mind, is that when switching to template editing, the inspector should switch from "page" to "template": Current: Ideally: |
|
One other thing: this treatment should also be applied when editing a template part in isolation. (I still see the current no-canvas approach there.) |
Yes this feels very important. I'll open an issue.
This is one of many changes proposed in #29148 |
|
One more issue: "select" mode seems to not be working as expected here (single click enters into edit mode sometimes). |
|
That may be a broader site editing issue. There are few quirks with Select mode there (click-through pattern doesn't work at all). |
|
🎉 |
|
Ok let's get this in. I'll be working on more follow-ups. |
|
One thing I'd love to see us try is animating the background when entering this mode so that you can see the canvas going smaller. :) |
This is a small iteration towards a better block template mode in the post editor like shown here #27849 (comment)
This does a few small things:
This probably need some design polish.