-
Notifications
You must be signed in to change notification settings - Fork 12
Implement UX for scrolling in Home View #372
Comments
A quick WIP to show what's in scope here.
|
I’ve mocked up the scrolling animations in slow motion – so you can see how each element animates – and divided it into two separate parts. Part 1: initial state, until the card UI hits 16 margin from the topI’ve mocked up two possible Map View button animations: Part 2: Content scrolls “under” the top card section, until the end of contentThoughts? |
Nice! that's what I was thinking. But I pictured it with some more "bounce". Perhaps useful to see it at full speed?
Nice! looks good to me |
Before I realized this was an issue, (in my free time) I started cleaning up the code and adding the scrolling inside the card so the card never moves while scrolling: Notably, this conflicts with:
@antlam, @brampitoyo Is my implementation something that would be desired? Notes:
I can get you a build, if you'd like! |
Leaving this one to @brampitoyo ;)
Yes please! Feel free to just send a one over to us. In general, always great to get things on device. |
In this case, I think it’s a good idea to let card height expand dynamically to follow content height. The idea is that, when the content expands downward beyond the screen, it becomes visually clear that you’re supposed to scroll down to see more. But you can also argue that this would complicate the code. What do you think? |
@mcomella If we’re going to allow the content to scroll without moving the card itself, what we can do is put a subtle white mask on top and bottom sides of the card.
I would argue we shouldn’t be too smart here. On horizontal scroll, we’ll show the next card but preserve the user’s vertical position on the previous card. If they had scrolled down too much and now want to go back up, they can simply scroll. Thoughts? |
via Slack: antlam preferred the card to scroll to the top of the screen. My response:
And Bram responded:
@brampitoyo Do you have further thoughts? Should I pursue your two requested changes? |
Spoke with antlam on vidyo: In the current experience, when the user scrolls to read long-form content, we move the photos off-screen because they're no longer important – my experience is a regression from this, where the photos remain on the screen. As such, we don't want to continue pursuing my implementation. My intention was to simplify the code by re-using To continue to pursue this design, I would recommend first refactoring the carousel layout by separating group layout/transitions from the individual item interactions (use UICollectionView?). Then hopefully it will be simple enough to pursue this solution. Anthony gave great advice at looking at other open source solutions which have done something similar – an example will be a scroll view that affixes new headers as it scrolls. |
As the cards get longer we need to account for how our content scales, how a user swipes to the next card, and how our UI adjusts.
The text was updated successfully, but these errors were encountered: