<https://android-review.googlesource.com/c/platfor...
# compose
Is this the final decision? I have a lot of user feedback about unclear over scroll vs reverting back with a clear indicator about the reason / status. Specially when it's disabled only on some items in a list
j
Yes, but the change would actually benefit your use case as the recommended new way wouldn't let the components scroll in the first place. See the new sample that's included the change
t
That's how I did it previously and users where confused.
Take gmail swipe to dismiss for example, now imagine in the list the user can swipe left and right 6 items but not the 7th because it's currently active or locked.
If the user can swipe most items but not some without any indication about why he's lost.
j
Yes, there would be an indication for this (e.g. an overscroll effect, which AnchoredDraggable integrates with)
t
In my case when the user swipe there's an animated icon when the action is possible that pop. When it's not the icon is red without the pop to be clear it's not possible for that item.
Overscroll is not an indication about why they can't swipe 1 item in a list of items. They just assume it's broken.
j
An OverscrollEffect lets you build the same UX as previously (although we don't recommend this UX) where you allow the user to drag as far as possible and then animate back to an allowed anchor
We do think default overscroll is a better indication of unavailability to the user, but ultimately this will be up to anyone using AnchoredDraggable
t
Well I guess I'll see what's possible, but usually when many users complains about an UX it means there's really something wrong with it, as most users just ignore and don't take time to report.
Can you make a sample about how to actually implement OverscrollEffect to show a swipedismiss layout under ?
j
We have samples for custom overscroll effects, but we can look into if we can prioritize one that replicates the old behavior
❤️ 1