[TEST] Try drag & drop blocks feature

[fluiddot]

WordPress-Android PR: wordpress-mobile/WordPress-Android#16166
WordPress-iOS PR: wordpress-mobile/WordPress-iOS#18206

NOTE: This PR was created only for generating an installable build for testing the drag & drop blocks feature.

To test:
N/A

PR submission checklist:

• I have considered adding unit tests where possible.
• I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

[iamthomasbishop]

Hey @fluiddot great work thus far! I took this for a spin via the iOS and Android builds separately and jotted down some notes, some of which is platform-specific but mostly related to the behavior and sequencing of the interaction. I may have some additional visual design-level feedback in the next round, but I wanted to focus on the core interactions first.

Collapse behavior/sequencing

Instead of collapsing the block immediately upon long-press, can we wait to collapse it until the "chip" is dropped in a new location? This would essentially "hold" the space of the original block when dragging and ensure that blocks don't move around as much. The sequence would be something like this:

• Press and hold on a block
• Upon (long-press) timeout, a few things happen:
  • I get indication of draggability via haptic feedback and a chip (note: I can provide the styles for this shadow)
  • The area that encompasses the block stays as-is until the dragged block is dropped into its new location, perhaps with an opacity of ~25-40% while dragging
• When I start dragging, the drop-zone indicator (horizontal blue line) appears over where I'm dragging
• When I drop the block into a new location, it becomes the selected block

Does that all make sense?

Haptics

It'd be nice to feel some haptic feedback at a couple of key points:

• When dragging is initially activated
• Each time the "chip" appears over a new location

Other notes

• Is there any way we can shift focus/selection to the dragged block after it is dropped? I kept expecting the block I dragged/dropped to become selected, for some reason.

(Note: The following issues seem to mostly be on iOS, although the transitions upon drop, in general, are also a little choppy.)

• It doesn't seem that the height of a selected block is getting transitioned accurately when dropping them into a new position (video example), at least on iOS
• Sometimes the drop-zone indicator line doesn't disappear after dropping (video example)

[fluiddot]

Hey @fluiddot great work thus far! I took this for a spin via the iOS and Android builds separately and jotted down some notes, some of which is platform-specific but mostly related to the behavior and sequencing of the interaction. I may have some additional visual design-level feedback in the next round, but I wanted to focus on the core interactions first.

Great, thanks @iamthomasbishop for reviewing the feature and providing the helpful feedback.

Collapse behavior/sequencing

Instead of collapsing the block immediately upon long-press, can we wait to collapse it until the "chip" is dropped in a new location? This would essentially "hold" the space of the original block when dragging and ensure that blocks don't move around as much. The sequence would be something like this:

• Press and hold on a block

• Upon (long-press) timeout, a few things happen:

  • I get indication of draggability via haptic feedback and a chip (note: I can provide the styles for this shadow)
  • The area that encompasses the block stays as-is until the dragged block is dropped into its new location, perhaps with an opacity of ~25-40% while dragging

• When I start dragging, the drop-zone indicator (horizontal blue line) appears over where I'm dragging

• When I drop the block into a new location, it becomes the selected block

Does that all make sense?

Sure, I can try this sequence. The idea behind collapsing the block was to make the dragging easier when the block being dragged is long, although I see that on the web version the transition sequence is very close to what you outlined, so let's try to match it.

Haptics

It'd be nice to feel some haptic feedback at a couple of key points:

• When dragging is initially activated
• Each time the "chip" appears over a new location

Good point, it would be great to have haptic feedback on those actions, I'll add a task 👍 .

Other notes

• Is there any way we can shift focus/selection to the dragged block after it is dropped? I kept expecting the block I dragged/dropped to become selected, for some reason.

(Note: The following issues seem to mostly be on iOS, although the transitions upon drop, in general, are also a little choppy.)

Good idea, it makes sense that if the user moves a block it gets selected, I'll update the behavior to reflect this.

NOTE: The web version only allows dragging blocks when they are selected.

• It doesn't seem that the height of a selected block is getting transitioned accurately when dropping them into a new position (video example), at least on iOS

Oh, that's an issue I thought I fixed with the latest changes 🤔. As far as I investigated, this issue is caused by the height animation while dragging and dropping a block that is already selected. If we finally change the transition sequence, this issue will vanish. Alternatively, it could also be addressed by automatically unselecting the block before the dragging transition, and then again getting selected once it finishes.

• Sometimes the drop-zone indicator line doesn't disappear after dropping (video example)

Interesting, we'll investigate this issue further, thanks for reporting it 🙇 .

[iamthomasbishop]

@fluiddot I tried the latest test build on iOS and the transitions/interactions in general are a lot more fluid (especially love the haptics 😍), nice work! I have just a couple of suggestions, none of which are critical, but rather refinements I'd like to make if possible.

• Can we speed up the duration of the transition-in of the chip (the UI bit that appears when you drag a block) to maybe ~half the current value? Would it also be possible to change the starting Y-position of the chip (the point from which if begins its transition-in) down ~10px so that when it enters, it sort of has the effect of "bubbling up" from directly under your finger, similar to when you drop a pin on a map in Apple Maps?
• Would it be possible to animate the space-allotment/dimensions of the block's new position before fading in the contents of the block? What I'm imagining is a quick 100-300ms transition to expand to the size of the block, and then a 50-150ms transition to fade in the opacity of the block itself.Here's an example. Note: I applied a dim gray background fill just to help me visualize the transition, but I actually quite like it. Maybe we could apply that and remove it if it doesn't feel right in practice.

[iamthomasbishop]

@fluiddot Just took the Android build for a spin and found that I have the same feedback as my previous comment. The only additional thing with Android was that I wasn't feeling the haptics — is that an iOS-only thing w/ the library we're using?

[fluiddot]

@fluiddot I tried the latest test build on iOS and the transitions/interactions in general are a lot more fluid (especially love the haptics 😍), nice work!

❤️

I have just a couple of suggestions, none of which are critical, but rather refinements I'd like to make if possible.

@iamthomasbishop thank you so much for reviewing and providing these suggestions 🙇.

• Can we speed up the duration of the transition-in of the chip (the UI bit that appears when you drag a block) to maybe ~half the current value? Would it also be possible to change the starting Y-position of the chip (the point from which if begins its transition-in) down ~10px so that when it enters, it sort of has the effect of "bubbling up" from directly under your finger, similar to when you drop a pin on a map in Apple Maps?

Sure thing, I think this effect would be relatively easy to implement 👍 .

• Would it be possible to animate the space-allotment/dimensions of the block's new position before fading in the contents of the block? What I'm imagining is a quick 100-300ms transition to expand to the size of the block, and then a 50-150ms transition to fade in the opacity of the block itself.Here's an example. Note: I applied a dim gray background fill just to help me visualize the transition, but I actually quite like it. Maybe we could apply that and remove it if it doesn't feel right in practice.

Yeah, I can try to take a look at this effect, the expand effect is similar to what I had previously so I could restore part of that logic. In any case, I'd like to note that in the next phase of the feature, we're planning to improve animations and transitions, so it would be great if we could focus on this first version on the simplest option to provide the basic functionality.

Just took the Android build for a spin and found that I have the same feedback as my previous comment. The only additional thing with Android was that I wasn't feeling the haptics — is that an iOS-only thing w/ the library we're using?

Yep, sorry, I forgot to mention that I only added the haptic feedback on iOS. I haven't finished the implementation of that part, so most likely we'll also be able to have haptic feedback on Android.

[iamthomasbishop]

I'd like to note that in the next phase of the feature, we're planning to improve animations and transitions, so it would be great if we could focus on this first version on the simplest option to provide the basic functionality.

That's totally fine, it's in a pretty good place already.

I forgot to mention that I only added the haptic feedback on iOS

Ah okay, glad it wasn't my imagination 😆 Thank you!

[fluiddot]

Can we speed up the duration of the transition-in of the chip (the UI bit that appears when you drag a block) to maybe ~half the current value? Would it also be possible to change the starting Y-position of the chip (the point from which if begins its transition-in) down ~10px so that when it enters, it sort of has the effect of "bubbling up" from directly under your finger, similar to when you drop a pin on a map in Apple Maps?

@iamthomasbishop I updated the animations of the chip in WordPress/gutenberg#40409, I'd appreciate it if you could take a look at the screeneshots/screencasts to verify that it's the expected behavior, thanks 🙇 .

[iamthomasbishop]

@fluiddot It's a bit hard to say for sure without trying it on a test build but based on the screen recordings you posted, the animations look pretty solid in general.

My first thought is that the duration could be shortened a bit. You mentioned that we're using the defaults from Reanimated which looks to be 300ms, so maybe we can try ~200 ms on entrance and ~150ms on exit.

It'd be nice to spend some time tinkering with some of the other properties (e.g. spring, dampening, etc.) but this is a good place to start! I see they have a playground but I was hoping they'd have a web app or something I could tinker with while mobile 🙃.

[fluiddot]

@fluiddot It's a bit hard to say for sure without trying it on a test build but based on the screen recordings you posted, the animations look pretty solid in general.

Right, I'll try to generate new installable builds to include the latest changes so you can test them 👍 .

My first thought is that the duration could be shortened a bit. You mentioned that we're using the defaults from Reanimated which looks to be 300ms, so maybe we can try ~200 ms on entrance and ~150ms on exit.

Sure thing, the animations are fully customizable, so we can tweak the durations. I'll update the PR to reflect this.

It'd be nice to spend some time tinkering with some of the other properties (e.g. spring, dampening, etc.) but this is a good place to start! I see they have a playground but I was hoping they'd have a web app or something I could tinker with while mobile 🙃.

Yep, that would be awesome but AFAIK they don't provide a tool for playing with the animations 😅 .

[fluiddot]

@fluiddot It's a bit hard to say for sure without trying it on a test build but based on the screen recordings you posted, the animations look pretty solid in general.

Right, I'll try to generate new installable builds to include the latest changes so you can test them 👍 .

@iamthomasbishop I've just generated new installable builds with the latest changes (including the new chip animation).

[iamthomasbishop]

@fluiddot I just took the latest builds for a spin (iPad Pro running iOS 15.5 beta, iPhone 13 Pro running 15.4.1, and Pixel 4 running Android 12) and noticed a few issues, some of which I would consider release-blocking — specifically the ones I experience while using iPad with a trackpad. As a side note: I don't currently have an Android tablet to test with, so I'm not sure if the issues I experienced with iPad also apply to Android tablets.

Activation Reliability

I don't remember seeing this on previous builds, but I now seem to be having issues reliably initiating drag & drop at all. In practice it feels like a performance issue because things slow down a bit while it's happening, but it's happening across platforms. It's especially fussy upon opening a new or draft post, but it's hard to pinpoint the issue because it's inconsistent. Fwiw, I hadn't seen this issue while testing on iPhone or Pixel 4 previously, but I would consider this a blocker.

iPad OS/Trackpad Blockers

In addition to the unreliability mentioned above, I noticed an issue while testing on an iPad (iPad OS 15.5) with a trackpad (the magic keyboard with trackpad and also a standalone trackpad just to be sure) where I'm unable to drag at all. Performing a long-press does (sometimes) make the chip appear, but I can't continue the gesture by dragging — the chip simply stays in its original location until I release. (video)

Other notes

• Chip transitions: The transitions on the chip look much better, thanks for wrangling that!
• Haptics: I still need to test the latest improvements to haptics, which you mentioned is coming with a new test build. I don't expect any surprises with this and it's something we can iterate on, thus not a blocker IMO.

[iamthomasbishop]

Following up on the issues I reported in my previous comment for visibility.

After some discussion, I noticed that I had been testing using an outdated build 🤦. Most if not all of the issues I mentioned are no longer present in the newer build, so I think we're in pretty good shape. I did however discover (as discussed in slack) a separate UX concern: that only the inner content container of the block is draggable (as opposed to the entire block, which is what I expected). It sounds like there are some technical challenges that come with that regarding block heights/transforms, so that's an ongoing discussion.

[geriux]

Most if not all of the issues I mentioned are no longer present in the newer build

That's good to know @iamthomasbishop! 🎉

One question, were you able to check the issue mentioned above related to the iPad OS trackpad problems you had when you tried the latest build?

When I tested it I didn't have any issues but I wanted to confirm with you as well so we can close this issue.

Thanks!

[iamthomasbishop]

One question, were you able to check the issue mentioned above related to the iPad OS trackpad problems you had when you tried the latest build?

@geriux Yea, those issues are no longer present as far as I can tell! We can probably close that one.

[fluiddot]

@iamthomasbishop, in relation to the latest feedback:

I did however discover (as discussed in slack) a separate UX concern: that only the inner content container of the block is draggable (as opposed to the entire block, which is what I expected).

This issue was solved in this PR and included as part of the basic functionality of the feature in version 19.9.

It sounds like there are some technical challenges that come with that regarding block heights/transforms, so that's an ongoing discussion.

I'll open a new issue as a follow-up on this, so we can include it for the next iteration of the feature.

[fluiddot]

Closing this PR as the feature is already included in the main apps.