POC: Animate the editor areas (sidebar, footer) #60423
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
added
the
[Type] Technical Prototype
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +288 B (0%) Total Size: 1.73 MB
ℹ️ View Unchanged
|
draganescu
reviewed
Apr 3, 2024
| @@ -254,7 +254,6 @@ export default function Editor( { isLoading, onClick } ) { | |||
| ( shouldShowListView && <ListViewSidebar /> ) ) | |||
| } | |||
| sidebar={ | |||
| ! isDistractionFree && | |||
There was a problem hiding this comment.
man, we really meant to make sure ! isDistractionFree 😂
draganescu
reviewed
Apr 3, 2024
There was a problem hiding this comment.
I like this a lot. It is a good POC and we need to move into this direction. Evolving zoom out mode further requires the inserter to behave like all the other sidebars which only brings us closer to removing the blockers encountered here.
PS: Only in this PR I noticed that Editor: Unify the DocumentTools component has allowed the inserter in DFM :) and that made its way into WP 6.5 - nobody complained but the experience is not great, but not bad either, since the inserter self closes.
|
I guess we'll have to animate the width here too? I'm seeing some white "placeholder": Screen.Recording.2024-04-03.at.21.11.46.mov |
|
@ellatrix yes, it's related to the last point I make on the PR description. That said, this is not a PR that I plan to merge, there's still a lot of requirements to be met to be able to merge it. The sidebar refactors (bundling the complementary area API into the skeleton is the important one). It's more of a POC to explore the idea of the skeleton being responsible of the different areas and animating them as they open/close. Is this a good/valid concept ? |
|
Yes, I wanted to approve if not for this white background :D |
|
Here's a mockup demonstrating how things might work when these editor areas animate: animation.mp4Figma prototype here. There's a reduced speed version too which makes it easier to discern what is happening. |
|
Please mind accessibility here: https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html Want to make sure the prefers reduced motion setting is respected. Other than that, animate away. Thanks. 👍 |
|
closing as this #60561 landed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a POC to unify how the different UI pieces of the editor (left sidebar, right sidebar, footer, later the header) animate.
The editors already use
InterfaceSkeletoncomponent to render sidebars, headers... and the skeleton is "mostly" (we'll get to that later) aware when to show and hide the different pieces which means, it should be possible to animate these UI pieces as they appear/disappear.You can try the current state of the PR where you will see the left and right sidebars be animated and even showing/hiding the breadcrumb also animates.
But the PR is a POC for a reason, we have made a few decisions over time that make this hard to achieve consistently:
Most of the issues come down to the same problems: In order to animate properly, showing and hiding the UI should be handled by the
InterfaceSkeletonitself which is not always the case for us:ComplementaryArea.Slotthat hides stuff (we support showing different sidebars in the same area and switching between them). This is harder to solve because it basically means that we should "bundle" the complementary areas API into the skeleton. To be honest, I think it makes sense to be able to say: the "sidebar" area of the skeleton corresponds to the "edit-post" complementary area without necessarily rendering the slot or passing anything to the "sidebar" prop manually. It's doable though.The other challenge here is that you can see sometimes that the sidebars animate but the "main" area doesn't. We can solve that using framer motion's
layoutanimation potentially but it would create some distortion when animating. Maybe we can apply the same technique we use for the frame animation of the site editor though.