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

Add rough animation to navigation and links #46342

Merged

Conversation

artemiomorales
Copy link
Contributor

@artemiomorales artemiomorales commented Dec 7, 2022

What?

This pull request is an exploration of how we might add animation to the navigation block and related links in the off canvas editor, related to #45884

Why?

The slide animations can help with the orient the user and overall provide a better experience.

How?

Currently, this PR adds a very rough implementation of the animation using Framer Motion so we can have something to look at as we continue discussions.

Testing Instructions

  1. Open the Full Site Editor
  2. Open the Navigation block
  3. In the off-canvas editor, click the edit button on one of the navigation links
  4. Click the back button on the navigation link's Block Card

Testing Instructions for Keyboard

I believe the same as above, except tab over to the buttons. Since this is just for a user test though, I can look at accessibility more closely once we have a better handle on the approach we're going to take.

Additional Notes and Question for Discussion

Note: The code currently activates the animation whenever the previously selected block is a navigation block, navigation link, or navigation submenu, so it's not a real implementation yet, so the code is very rough, though I'm happy to take any suggestions.

That being said, I'm looking for feedback on the animation itself — is this how we want it to look, or do we want to show an exit animation on the previously selected block before showing the entry animation of the newly selected one?

Screen shots or screencast

Screen.Recording.2022-12-06.at.9.02.07.PM.mov

@draganescu
Copy link
Contributor

From the video it looks like a very good start. It's a bit jarring that we have a blank intermission, that is the present screen disappears too quickly and the future one comes from too far away. To guide in terms of animation tweaking use the global styles animation as a reference:

gs-animation.mp4

@scruffian
Copy link
Contributor

The video looks promising. I tried to run this branch but I couldn't get it to run. Is it based on an old version of Gutenberg?

@getdave
Copy link
Contributor

getdave commented Dec 7, 2022

From watching the video this looks really great 👏 Nice work!

As @draganescu said let's be sure to sync the actual animation timings and functions with those used in Global Styles panels.

I'll take a look at the implementation to see if I can come up with ideas to decouple the blocks from the block-editor.

Comment on lines 184 to 197
const { parentNavBlockClientId } = useSelect( ( select ) => {
const { getSelectedBlockClientId, getBlockParentsByBlockName } =
select( blockEditorStore );

const _selectedBlockClientId = getSelectedBlockClientId();

return {
parentNavBlockClientId: getBlockParentsByBlockName(
_selectedBlockClientId,
'core/navigation',
true
)[ 0 ],
};
}, [] );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In #46058 I tried to make the whole "Back button" thing universal with the only exceptions being the Template Part and Reusable Blocks.

If we were to persue that route we could remove this code and make it generic to the "nearest controlling parent" right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option might be to investgate whether we can configure the animation based on information passed via block editor settings.

Here's some prior art on that one.

So you could have a setting which determines the specific blocks that will exhibit the special "back button" behaviour.

This is all to avoid coupling a block to the block-editor package.

@artemiomorales
Copy link
Contributor Author

From the video it looks like a very good start. It's a bit jarring that we have a blank intermission, that is the present screen disappears too quickly and the future one comes from too far away. To guide in terms of animation tweaking use the global styles animation as a reference.

@draganescu Ok I modified the animation to more closely resemble the global styles animation. How does it look now?

The video looks promising. I tried to run this branch but I couldn't get it to run. Is it based on an old version of Gutenberg?

@scruffian Hmm it's been rebased on the latest version of trunk, so it should be working.

Another option might be to investigate whether we can configure the animation based on information passed via block editor settings.

@getdave I added a rough implementation of a block editor setting as you suggested. I'm still trying to make the animation occur only when when the navigation link edit button or back button are pressed.

Overall question: Should the animation still occur when blocks are selected via the Document Overview Panel or the canvas?

@artemiomorales
Copy link
Contributor Author

For reference, this is what the animation looks like at the moment:

animation-edit.mov

Copy link
Contributor

@getdave getdave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work iterating on this.

I think we should seek input from designers as to whether it's worthwhile to just enable the animation for all panel interactions?

Of course if we need specific directional exceptions for certain blocks then perhaps the config coming from the settings will work well.

@jasmussen might be able to offer an opinion.

@@ -376,3 +376,23 @@ function gutenberg_disable_tabs_for_navigation_link_block( $settings ) {
}

add_filter( 'block_editor_settings_all', 'gutenberg_disable_tabs_for_navigation_link_block' );

function gutenberg_enable_animation_for_navigation_link_inspector( $settings ) {
$current_tab_settings = _wp_array_get(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does $current_tab_settings need renaming?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching this! That variable has been renamed.

@jasmussen
Copy link
Contributor

Can look more in depth tomorrow and review, but my first instinct is that this should use the same component as the global styles inspector uses:

inspector

I don't think it's necessarily urgent that this happen, but it seems like we should avoid drift? I recall there being a ton of focus issues needing to be worked out for the Navigate component, it'd be good to avoid those by rebuilding it.

@scruffian
Copy link
Contributor

I think the animations are happening in the wrong direction. In Global Styles the panels enter from the right and leave to the right, whereas here they enter and leave from the left.

@artemiomorales
Copy link
Contributor Author

I think the animations are happening in the wrong direction. In Global Styles the panels enter from the right and leave to the right, whereas here they enter and leave from the left.

@scruffian Thanks for catching this. I accidentally switched it as I was cleaning things up yesterday; the animation should move in the right direction now.

Can look more in depth tomorrow and review, but my first instinct is that this should use the same component as the global styles inspector uses.

I don't think it's necessarily urgent that this happen, but it seems like we should avoid drift? I recall there being a ton of focus issues needing to be worked out for the Navigate component, it'd be good to avoid those by rebuilding it.

@jasmussen If we decide to go through with this experiment, using the <Navigator> component and modifying it for this use case may be worth looking into. I did try using it already though and my impression was that it doesn't work well with the block inspector logic.

If we do use it, I would want us to modify it so use of its history stack is optional, as in this scenario we only need the animation logic. But with that being the case, I think accessing the Framer Motion functionality directly, coupled with a standard way for implementing animations via block settings, may be an alternative way to prevent drift as well as keep the implementation simple.

The <Navigator> could still play a role in that, though its requirement to contain all JSX to be declared upfront seems relatively inflexible and difficult to implement for this use case at the moment. Would love to hear any additional suggestions or thoughts folks may have.

I also haven't looked at accessibility considerations with this animation experiment yet, so to @jasmussen's point, there may be additional points to consider there.

Additional Thoughts

  1. I believe this pull request may be at the stage that we can use it for user testing. Please note though that lint-js fired the following errors for me, which I overrode for now. Is it alright to go ahead with these errors for the purpose of this experiment, or should these be remedied?
  24:1   error  'framer-motion' import is restricted from being used. Please use the Framer Motion API through `@wordpress/components` instead  no-restricted-imports
  24:1   error  'framer-motion' should be listed in the project's dependencies. Run 'npm i -S framer-motion' to add it                          import/no-extraneous-dependencies
  1. Currently, the animation is only visible in the Site Editor. Should I implement it in the Post Editor as well?

  2. Should I look into accessibility considerations?

@jasmussen
Copy link
Contributor

Thank you for the clarity Artemio, much appreciated. I can't speak too deeply into the underlying technology and will refer to you and others, though I would love input from @youknowriad or @jorgefilipecosta if they have time. The key concen I want to voice is:

  • This experiment is so far working great, I would expect it to graduate.
  • For that reason, we should think in terms of re-usable componentry across blocks. For example I expect this same innerblock-drilldown mechanism to apply to contentOnly locked patterns.
  • Since we already have a Navigator component for global styles, it seemed like the better long term approach to refine that component and reuse it here, rather than write new unique code.

@youknowriad
Copy link
Contributor

Personally I tend to agree with @jasmussen here that we should try to consolidate by using the Navigator components. If we're not using it here which seems to me like a perfect fit, it may mean the component is not good enough (or there's no point in having it in the first place).

I think we already discussed some of that in one of @getdave's navigation block off canvas follow-up issues. and yeah it doesn't have to be in this PR.

@scruffian
Copy link
Contributor

Thanks for all your work on this.

Please note though that lint-js fired the following errors for me, which I overrode for now. Is it alright to go ahead with these errors for the purpose of this experiment, or should these be remedied?
24:1 error 'framer-motion' import is restricted from being used. Please use the Framer Motion API through @wordpress/components instead no-restricted-imports
24:1 error 'framer-motion' should be listed in the project's dependencies. Run 'npm i -S framer-motion' to add it import/no-extraneous-dependencies

You should change the dependencies as suggested in the error, and then it will go away.

Currently, the animation is only visible in the Site Editor. Should I implement it in the Post Editor as well?

I think that's ok as a known limitation, given that this is purely for the sake of running a user test.

Should I look into accessibility considerations?

Again, given that this is purely for the sake of running a user test, I think we can delay addressing these until we are ready to commit to the experiment.

It would be good to followup on the original issue (#45884) that we have implemented this as a quick fix but that it needs revisiting, and giving details on what the known limitations are.

@artemiomorales
Copy link
Contributor Author

@scruffian Great, the dependency errors have been fixed. I'll change the PR from 'draft' to 'ready for review.'

Personally I tend to agree with @jasmussen here that we should try to consolidate by using the Navigator components. If we're not using it here which seems to me like a perfect fit, it may mean the component is not good enough (or there's no point in having it in the first place).

I think we already discussed some of that in one of @getdave's navigation block off canvas follow-up issues. and yeah it doesn't have to be in this PR.

@youknowriad Got it. As per @scruffian's suggestion, I can follow up with additional thoughts and we can continue the discussion related to the Navigator in the original issue #45884

@scruffian
Copy link
Contributor

Looks like you have some linting errors that need addressing.

@scruffian scruffian enabled auto-merge (squash) December 12, 2022 23:20
auto-merge was automatically disabled December 12, 2022 23:37

Head branch was pushed to by a user without write access

@artemiomorales
Copy link
Contributor Author

@scruffian All checks have passed. Just let me know if this needs anything else!

Copy link
Contributor

@getdave getdave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First up great work on finding an expedient solution to the immediate problem of animation.

That said it's a tricky one, because if this gets merged then it's a change that's bleeding outside of the nav offcanvas experiment by getting into the block settings as an experimental prop which will then need to be managed and removed/stabilised by the time WP 6.2 comes around.

As has been suggested we could use the <Navigator> component and extend it to be used in the inspector controls, but that would still leave the problem that we probably don't necessarily want to apply this animation to all inspector controls.

In the interests of expediency (i.e. improving the Nav offcanvas experiment) I'm in favour of merging this one but on the following provisos:

  • @artemiomorales and the contributors working on the nav offcanvas experiment commit to managing the __experimentalBlockInspectorAnimation property for the WP 6.2 release cycle.
  • we follow up to investigate the possibility of utilising <Navigator> in the Inspector Controls as suggested by several folks here and elsewhere.

What do we all think?

Thanks again @artemiomorales for continuing to work on this one 🙇

}
return null;
},
[ selectedBlockClientId ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blockType.name is used within the select but is not listed in the deps.


const blockInspectorAnimationSettings = useSelect(
( select ) => {
if ( isOffCanvasNavigationEditorEnabled ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used within the select but is not in the useSelect dependencies.

Comment on lines 249 to 252
<BlockInspectorSingleBlock
clientId={ selectedBlockClientId }
blockName={ blockType.name }
/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block of code is duplicated as the default return statement.

Could we consider conditionally wrapping the default return in the motion div and avoid the duplication?

Copy link
Contributor

@scruffian scruffian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good to me. Just a couple of cleanup things Dave suggested and I think we can merge it.

@getdave getdave added [Package] Block editor /packages/block-editor [Type] Experimental Experimental feature or API. labels Dec 14, 2022
@artemiomorales
Copy link
Contributor Author

@scruffian @getdave Ok I added a wrapper for the motion div to avoid duplication and added the dependencies to the useSelect. How does that look?

Currently trying to get all the checks to pass.

Copy link
Contributor

@scruffian scruffian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good for a quick fix for now. Let's get it in and then look at what it would take to refactor it to use the Navigator component next.

@scruffian scruffian merged commit b856a3f into WordPress:trunk Dec 14, 2022
@github-actions github-actions bot added this to the Gutenberg 14.9 milestone Dec 14, 2022
dmsnell pushed a commit that referenced this pull request Dec 15, 2022
* Add rough animation to navigation and links

* Add support for configuring animation in block settings; revise animation implementation

* Fix animation direction; do code cleanup

* Add framer dependency and disable import restriction

* Fix linter errors

* Limit scope to fix tests

* Add wrapper for animation logic, update useSelect  dependencies

* Fix dependency declaration that was causing tests to break
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Block editor /packages/block-editor [Type] Experimental Experimental feature or API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants