Resizing animation / transition in Gutenberg for WP 6.2 RC too long & slow for efficient daily design work

[porg]

Animations in Site Editor — This needs an URGENT fix prior releasing Wordpress 6.2

WP 6.1.1

• 👍 Smooth but fast enough to not disturb working efficiency. Just right!
• UI reacts instant
• Viewport Switching instant
• Only subtle transitions in the content (via the CSS transitions which are part of the theme)

WP 6.2 preview (WP 6.1.1 with plugin Gutenberg 15.3.1)

👎 So slow that it feels like a "laggy app" which makes daily web design work very inefficient.

• UI panels feel like having a 500-2000ms transition after each window resizing. Nightmare!
• Viewport Switching also too slow. Tweak a block attribute, preview mobile, preview tablet, tweak again — This can be 20-30 interactions easily until the design is right, waiting 1-2secs extra each time — Inacceptible!

Screen recording with audio

• Compares the situation between 6.1.1 and 6.2 preview (WP 6.1.1 with plugin Gutenberg 15.3.1)

https://user-images.githubusercontent.com/737143/226930698-b4a61f24-a0fd-44db-aba6-2eaf61e554e3.mp4

Environment info

• WP 6.2 preview (WP 6.1.1 with plugin Gutenberg 15.3.1)

Related

• 46354

[glendaviesnz]

There is a 0.5 transition delay on the site editor transitions here - reducing this to 0.2 did make things feel a bit snappier, but I am not aware of the design decisions around this timing, so will let one of the design team respond to this.

[porg]

My input as a Senior UX designer (10+ years experience)

• Rule of thumb on animation: Animation durations for FX on frequently used actions are usually 200-300ms max!
• Problem 1: 500ms itself is already way above that. → Certainly shall be reduced to 200ms.
• Problem 2: On top of problem 1 what seems to happen here also is cumulative addition of animation effects!
  • When you resize a window, this likely does not happen in a clean single mouse move, but with 2-3 intermediary micro stops of mouse movement while dragging, which potentially all cumulatively add up!
  • Hence the whole operation delay easily "feels like 2-3secs" which feels really laggy and slow.

Recommended changes

• The Editor UI FX does not provide any real benefit:
  • CSS transitions in the content area are anyhow played back normally independent from Editor UI FX.
  • Nothing or not much of the Editor UI needs smooth layout reflows — mostly fixed width/height panels/bars! 1) I strongly urge to drop the Editor UI FX altogether. 2) or put it very low 200ms and if cumulative FX is a problem introduce mechanisms to suppress cumulative effects (again more technical debt!):
  • a) event triggering treshhold (only if you stop at least e.g. 500ms a new 250ms FX can even get triggered)
  • b) mechanism which aborts/expedites the current animation (not so easy to do this right either)

[porg]

@glendaviesnz (or other devs): const ANIMATION_DURATION = 0.5; At which filepath in the readily-built production plugin on my WP installation can I tweak that variable constant to try it out myself?

[glendaviesnz]

const ANIMATION_DURATION = 0.5; At which filepath in the readily-built production plugin on my WP installation can I tweak that variable constant to try it out myself?

In the production build it is hidden away somewhere in the bowels of a minified javascript file, at a quick look I couldn't track it down - someone else may be able to, but your best bet for playing with this would be if you can checkout this repo, change the value here and then run the local dev version of the plugin. Let me know if you are interested in doing that, and if you already have node/npm and docker installed locally or not I can then point you to the relevant instructions for setting that up.

[porg]

1) For the time being I'm not willing/able to setup a dev-environment to test Gutenberg.

2) What I know as a UX designer from some web developer colleagues is that when they inspect .min.js minified JavaScript files in the web browser's DevTools, it shows them the original files by help of .js.map source map files.

• But in the case of the Gutenberg production plugin, no source maps seem to be offered. Why?
  • Performance gains of minification would still be there. (That one source map reference line with ca 100 bytes does add up almost nothing)
  • And secrecy is not necessary as WordPress and Gutenberg are both FLOSS.
  • You know the reasons why?

3) Could you or someone else with a dev environment please be so kind and video record

• these scenes:
  • a) Toggle left sidebar on/off
  • b) Resize screen smaller. Then larger again.
  • c) Cycle Preview: Desktop, Mobile, Tablet, back to Desktop again.
• with ANIMATION_DURATION at 200ms? If possible also at 100ms and 250ms?
• And share these as separate clips, or one video clip with clear pauses/inserts here in this issue?

[glendaviesnz]

@jameskoster do you have any background on why the 0.5 rate was chosen for these animations?

[jameskoster]

It was discussed a bit here, without any resolution.

[porg]

@jameskoster: In your inline code comment you shared video recordings how different animation types and durations affect the left side bar toggling. My judgement:

• The "Anticipate" movement is horrible as it introduces not only a delay per se, but first one animation vector, then another.
• The last "Ease in out" (no duration stated) is somehow ok (if it has that timing not only on high end devices, but also on contemporary mid/low end devices).

You only recorded toggling of the left side panel.

• Please state the duration of that last "Ease in out" preset
• Please state what device / browser you recorded on (low / mid / high end device).
• Please also record the user events:
  • Toggle the right side panel (block/page settings or global styles)
  • Cycling through the Preview: Desktop, Tablet, Mobile, Desktop.
  • Resizing the browser window (please place an about:blank window behind the recording window)

[scrobbleme]

It was discussed a bit here, without any resolution.

It would be much better

• if the animation would only be 1-dimensional, so no zoom is involved…
• and faster (I personally wouldn't need an animation at all)

[porg]

Pro/Cons:

• Getting this animation right is hard.
• Getting this animation wrong is easy: Finding acceptable values sure possible with best practises. But as the DOM is quite heavy in the Site Editor that timing may break all too easy on many devices (slow/mid end) and even on higher end devices with wide screens (and hence multiple stops during mouse resizing).
• Orientation for cause→effect and origin→destination is also clear with minimal or no animation.
• Content animation is independent of UI animation.

In doubt: Drop that animation altogether!

[jameskoster]

My mockups above were merely to initiate discussion, but obviously the PR was merged before any consensus was found. At this point it might be good to spin up a new PR and discuss the details therein.

[porg]

What is far more problematic here in terms of spatial/navigational orientation is how that top left button works.

• (Separate issue, have not searched yet whether already filed, links appreciated)
• It changed its behavior too often recently!
  • WP 6.1.1:
  • Top left button toggles left side bar visibility
  • Exiting to Dashboard has a dedicated menu entry
  • That's the correct behavior.
  • Gutenberg 15.4.0
  • Left side panel closed → Open left side panel
  • Left side panel open → Leave Site Editor to Site Dashboard
  • Gutenberg 15.3.*
  • Cannot recall exactly what, but it had yet another behavior.

[porg]

WP 6.2 shipping date is very close:

• Please make sure that WP 6.2 ships with no animation or a very short one!
• Otherwise I guarantee you many many complaints a la "the Site/Editor has become very slow".
• Detailed/other tweaks regarding toggling of the side bar can come later.