React-beautiful-dnd: Native scrolling on mobile

[humphreybc]

I upgraded Dovetail to 2.6.2 and reordering groups & cards now works on mobile (yay!). However one thing I noticed immediately is that it's quite difficult to use since you can't scroll. You have to put your finger right on the edge of the screen. Feel free to play around on dovetailapp.com on your phone to see what I mean, or check out these screenshots.

I read through the note on native scrolling. I don't really want to introduce drag handles to cards & groups since that increases UI complexity, and I also don't want to reduce the width of the draggable area to less than it already is.

My suggestion would be introducing a 250ms delay before triggering the reorder. This would let people scroll normally while supporting reorder with a ‘long press’. That's how Trello mobile works and what users have become accustomed to.

Forgive me if I'm missing some technical aspect. I'm not a ‘real’ developer, just a lowly designer 😂

[alexreardon]

Unfortunately this is not possible as we have to tell the browser if we are going to allow native scrolling straight away - and because we do not know if they are dragging or not we have to opt out in case it is a drag. The experience you are talking about is on the native trello app where they have a bit more control. On the web we are subject to the browsers and the corresponding specs.

Point of interest is that the trello mobile web experience does not support reordering at all at this time

I hope that provides a little more information - unfortunately that is how the browsers do things!

[alexreardon]

Also - i tried dovetail out on my phone and it looks great 👍

[humphreybc]

Okay, thanks for the reply. I think if that's the case, I'd probably want to disable reordering entirely on mobile for Dovetail and optimize for consuming the content rather than modifying it. Being able to scroll through the content easily is more important than reordering for us on mobile.

[alexreardon]

Makes sense. As a web library there is not much we can do about that. For what it is worth the reordering looked great though!

[bradleyayers]

I was curious about the browser behaviour, and found https://developers.google.com/web/updates/2017/01/scrolling-intervention#background_cancelable_events_slow_your_page_down provided some good background to it.

Another option is to use two fingers for dragging, and one finger for scrolling. I believe it's the gesture the embeddable (iframe) Google Maps uses for panning, to avoid breaking scrolling, so there's at least there's some precedent there. From an API perspective it should be as simple as having a prop that lets you specify the number of fingers.

[alexreardon]

Good link

The two finger one is interesting and worth considering more. However for now the single finger will be the way to go as we work on other features

[alexreardon]

You're welcome to create a new issues for it so it can be considered for future work

[alexreardon]

Also, keep in mind that not all touch devices support multi-touch. The more I think about it the more I doubt we will introduce a mutli finger drag

[humphreybc]

@alexreardon What percentage of devices don't support multi-touch? I imagine if Google Maps use two fingers to pan in their mobile iframe, it must be well enough supported?

[alexreardon]

I do not have access to multi-touch support data. Here are my current reasons against adding a two finger reorder mode:

• Some devices do not support multi touch
• Some users may not have the ability to use multiple inputs
• Some users might be using a stylus or similar single point input device
• Personally i have never see the two finger reorder pattern on either native or web apps. My thought here is that this pattern is generally not discoverable
• There are some viable patterns for supporting reordering with only a single input

• Not making Draggables the full width of the viewport so they can scroll on the side of it
• Use a drag handle so that only part of the Draggable is reserved for dragging (this is very common on native apps)
  readme

• Any time we add a new feature it adds complexity to the code which makes it harder to move forward - i see this feature and the configuration of it to introduce a number of code paths which I would prefer to avoid

Given these reasons I think we should not implement a duel finger reorder mode at this time. I appreciate your enthusiasm to make things more natural for users @humphreybc

[humphreybc]

@alexreardon I just had a realization – supersimpletasks.com works as I would expect on mobile. You can natively scroll the page up and down, and tap & hold to pick something up to reorder. It uses slip.js. It might be worth looking at that library to see how they do it?

[alexreardon]

I’ll take a look
On Wed, 22 Nov 2017 at 11:39 am, Benjamin Humphrey [e-mail]
wrote:

@alexreardon https://github.com/alexreardon I just had a realization –
supersimpletasks.com works as I would expect on mobile. You can natively
scroll the page up and down, and tap & hold to pick something up to
reorder. It uses slip.js https://kornel.ski/slip/. It might be worth
looking at that library to see how they do it?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/176#issuecomment-346206819,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7XA3PGYemPNeVs9_lvQ6xW6AcVhPks5s420ngaJpZM4Qf8eZ
.

[alexreardon]

That is great news. I will see how they did it. Ideally we move to long press only

[bradleyayers]

I had a quick look at their implementation, and they use the fact that touchmove isn't emitted immediately after touchstart — instead it's first emitted when the user moves their touch (e.g. finger/stylus) from the starting position. This means if you keep your finger still, touchmove isn't emitted.

Opting out of native scrolling can be done on the first touchmove event (TouchEvent#preventDefault()) so they simply wait for that event to decide to cancel native scrolling. When that event fires you can check the time elapsed and distance moved to decide whether or not to cancel native scrolling and enable 'reorder' mode.

Going by https://github.com/atlassian/react-beautiful-dnd/issues/11#issuecomment-343387736 I'm assuming we either:

• didn't realise the first touchmove is delayed until the touch actually moves, or
• didn't realise calling #preventDefault() on the first touchmove event can cancel native scrolling

Either that or I'm missing something else…?

[alexreardon]

When I was previously looking the touchmove fired instantly. However, it seems like that was an incorrect finding. Based on this new understanding I think we can move to a long-press only mechanism

[alexreardon]

I did a quick spike and it is looking goooood

mobile link

[alexreardon]

@humphreybc @bradleyayers check it out ^

👍

[bradleyayers]

That's much better! Long press is definitely my preference. It requires being fairly precise with a finger, but I think that's totally fine.

[alexreardon]

yeah i agree - much better

[humphreybc]

Nice! Yeah that's awesome. Much better!

[humphreybc]

Haptic feedback on long press is a great idea too!

[alexreardon]

It looks like the instant and paired touchmove is a emulator only thing.. So that is where that idea came from

[alexreardon]

It seems like the native scroll is being stopped on andriod.. hmm

[alexreardon]

It looks like the native scroll does not work on andriod - even for slip

😢

[alexreardon]

@lukebatchelor ^

[alexreardon]

I have checked that nothing is being stopped and still no good. By simply adding listeners native scroll is somehow prevented..

[alexreardon]

It looks like this is the troubled line:

touchAction: 'none',

By adding that we opt out to the pull down. However, by opting in with a value such as 'manipulation' I cannot seem to get it into the right state

[alexreardon]

I tried starting in manipulation (and others) and moving to none during a drag - but no dice

[alexreardon]

I think I may have found a way to make it work 🤞

[humphreybc]

If it's any help, I can confirm that Slip does work in Chrome on Android.

[alexreardon]

Not for the long press
On Wed, 22 Nov 2017 at 7:11 pm, Benjamin Humphrey [e-mail]
wrote:

If it's any help, I can confirm that Slip does work in Chrome on Android.

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/176#issuecomment-346274024,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7YWqXFuAwAxEb1Aicp7petziYGJCks5s49cxgaJpZM4Qf8eZ
.

[alexreardon]

Can you check out the preview in your android and let me know what you think?

[lukebatchelor]

Slip seems to work for me, includimg long press and that instant button (you have to hold for a tiiiiny bit longer than instant, but less than long press).

Android 8 on a Pixel XL

[lukebatchelor]

You link above mostly works. If I'm dragging one of the top two it will activate the native refresh event unless I hold for 2 or 3 seconds.

[lukebatchelor]

Interestingly, I can work around it by doing the long press and giving a tiny horizontal wiggle first, the dragging. :p

[alexreardon]

Andriod is being difficult. The complication right now is that the elements are focusable. However, I think I may have found a solution. I have tried it on my test device (Nexus 2) and it seems to be good. Can you give it another look on your device @lukebatchelor @humphreybc ?

mobile link

[alexreardon]

If we do go ahead with this I hope to bundle it with #190 into a breaking release. This will involve creating a new branch once we are happy with how this works

[lukebatchelor]

Ooh. Wow. Works perfect for me.

[alexreardon]

Huzzah! @lukebatchelor

[alexreardon]

I hope to test this on real devices a bit more - but i think we are getting close

[alexreardon]

Tested on three different andriods and it is looking nice

[humphreybc]

@alexreardon Yeah it's working great on my Pixel. The only thing I'd consider is lengthening the long press slightly — just a touch. I'm not sure what it is now, but maybe another 100ms delay. Great work.

[alexreardon]

@humphreybc we have kept the time fairly tight to allow rapid actions to occur without needing to wait too long. Interactions we need to balance:

• scrolling (could be fast or slow)
• tapping
• multiple reorders

The values chosen try to allow multiple reorders to occur without getting in the way of other actions - as well as not forcing the user to wait too long. Also, the longer we wait the more unlikely to get a false positive for scrolling as we need to opt out on the very first touchmove. The less time they need to keep their input still the better. Have a play on master and see what you think