Show changes to padding when entering changes in dimensions panel

[annezazu]

What problem does this address?

This came up as part of the ninth call for testing with the FSE Outreach Program:

When adjusting the padding, the preview doesn’t show any changes, until the user clicks out of that box or press enter key. I guess this is a feature. But when the user changes the value to null(ie. Empty box), without pressing enter and clicks out of the box, the value automatically sets to the previously saved value and not 0.

Essentially, unless you're dragging up and down to change values, changing the value doesn't show a change in the editor. Tied to this, if one empties the value, it resets to the prior one (bug or feature?). Here's a quick video:

padding.mov

What is your proposed solution?

When manually entering a value, have the changes be reflected in the editing experience. cc @aaronrobertshaw @jasmussen for thoughts since I can see you all are working on this!

[aaronrobertshaw]

Thanks for the ping @annezazu 🙂

The behaviour shown is consistent with the implementation of the BoxControl and how it utilises the underlying UnitControl component. It explicitly flags the control to require enter to be pressed to commit a change.

I'm not aware of the history behind this decision or if it's still valid. I'd suspect there was a valid reason for it, perhaps @jasmussen can shed more light on that from a UX perspective?

After quickly removing that flag, an initial test following the video appeared to work ok. It could lead to a pretty jumpy experience updating on every keystroke though. I think I personally prefer the "press enter to change" behaviour. I make a broad edit say to something like 50px then can use up/down arrows to fine-tune with immediate visual feedback.

[annezazu]

Thank you for the great context! I find the differences in experiences a bit jarring/confusing but I can also see why it's implemented as it is. Either way, I couldn't quite tell if this was a bug or future but will trust the design expertise Joen brings on this one.

[jasmussen]

Very helpful context as well. I sense and suspect there are some accessibility considerations related to having to press enter when you manually type in numbers. It could perhaps even be related to performance, where if you accidentally type 10000 it might choke for a bit.

Worth noting we do have some affordances to make this experience nicer, including the fact that you can use up and down arrows to increment/decrement the padding by 1, or shift up/down to increment/decrement by 10. You can also drag upwards and downwards in the panel itself:

Finally there's #33221 which details an effort to adjust the padding in the canvas itself. All of these should mitigate the specific issue.

[annezazu]

Thank you for the extra details and for following up! Love how much one can learn in opening issues.

Worth noting we do have some affordances to make this experience nicer, including the fact that you can use up and down arrows to increment/decrement the padding by 1, or shift up/down to increment/decrement by 10. You can also drag upwards and downwards in the panel itself

^ I think these exact affordance are part of why I expect being able to enter values to work in the same way. I agree though that the contextual padding controls very much will resolve this. Closing out the issue as a result.