Implement UX for scrolling in Home View

[antlam]

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.

[antlam]

A quick WIP to show what's in scope here.

• Map View button animates out (animation TBD)
• Name, Categories, and URL stays fixed in position as soon as the card UI hits 16px margin from the top
• Header image carousel scrolls off screen (like we have now)
• Background image fills remaining space
• maintain 16px margins from bottom of the screen
• maintain 24px margin under URL
• faint fade to white as content scrolls "under" the Name, categories, and URL section.

[brampitoyo]

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 top

I’ve mocked up two possible Map View button animations:

1. Scrolls up + fades out
2. Scales down + fades out

Part 2: Content scrolls “under” the top card section, until the end of content

Content scrolling animation.

Thoughts?

[antlam]

Scales down + fades out

Nice! that's what I was thinking. But I pictured it with some more "bounce". Perhaps useful to see it at full speed?

Content scrolling animation.

Nice! looks good to me

[mcomella]

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:

Header image carousel scrolls off screen (like we have now)

@antlam, @brampitoyo Is my implementation something that would be desired? Notes:

• In my implementation, it's straightforward to add scrolling the content under the Title/category/url header
• My implementation greatly simplifies the code and is done-ish now. It'd require extra work (and I'm concerned it'd be really tricky) to do the implementation in this bug (as far as I understand it, move the card under the user's finger, stop it when it hits the top of the screen, then continue scrolling the bottom of the card up, leaving the title/category/url header in place).
  • An unresolved UX issue: how does a scrolled card animate out when we pan horizontally to the next card?
• There are a few remaining UX issues with my implementation:
  • It's not always clear that a user can scroll inside the card
  • When the bottom-most description view (Yelp) is expanded, it expands outside the visible card and, since it's not clear a user can scroll, it's unclear the description has even expanded.

I can get you a build, if you'd like!

[antlam]

An unresolved UX issue: how does a scrolled card animate out when we pan horizontally to the next card? It's not always clear that a user can scroll inside the card When the bottom-most description view (Yelp) is expanded, it expands outside the visible card and, since it's not clear a user can scroll, it's unclear the description has even expanded.

Leaving this one to @brampitoyo ;)

I can get you a build, if you'd like!

Yes please! Feel free to just send a one over to us. In general, always great to get things on device.

[brampitoyo]

When the bottom-most description view (Yelp) is expanded, it expands outside the visible card and, since it's not clear a user can scroll, it's unclear the description has even expanded.

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?

[brampitoyo]

@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.

An unresolved UX issue: how does a scrolled card animate out when we pan horizontally to the next 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?

[mcomella]

via Slack: antlam preferred the card to scroll to the top of the screen. My response:

I don’t think moving the card while scrolling will be feasible: 1) It’d take a lot of custom code and I’m not interested in doing it in my free time (sorry!). There are higher priorities during work hours 2) The custom code is likely to complicate the code, which will make it harder to change other (probably more important) things 3) It’s a prototype and the design could change so I’m not sure it’s worth investing the time (edited)

Do you want me to pursue it without moving the card to the top of the screen?

I think I can do both of Bram’s suggestions in the bug (move bottom of card off-screen, white mask

Animating any change in size to the card will be hard though (it’d just pop to the new position instead)

And Bram responded:

mcomella Thanks for letting us know about feasibility! I’ll talk to antlam about it shortly and let you know.

@brampitoyo Do you have further thoughts? Should I pursue your two requested changes?

[mcomella]

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 ExpandingCardView – we can still do this in the current experience.

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.