Identify app behavior while walking around #594
Comments
Briefly looked into this. Looking at the current code, I think we only fetch places when the app returns to the foreground ( If we wanted to update the places as we walk, the PlaceCarouselViewController has the @antlam FYI that I don't think we update the UI at all as we walk, unless the app is closed and reopened. See below. |
However, it looks like we may resort the places every 100m as we walk. If I understand this correctly, the currently displayed card and the cards on either side will not be updated when we re-sort, but any subsequent swipes will use the newly ordering. That being said, the behavior is complicated and would not be intuitive for users. One example: The cards are resorted while the user is looking at a card. They swipe left, left, and swipe right, right to get back to the original card. However, this may not be the original card because this card is of the new ordering. I can explain further if necessary (though it'll take more work so I'm leaving this explanation as is for now). (FYI @antlam) Implementation details: |
Also note that anything that happens with place updating does not affect the map view, which makes a copy of the places list before it displays the places. |
NB: Strangely enough, when we re-sort, we do so by absolute distance from location, not travel times. This seems undesired – @antlam, what do you think? |
This is actually the behaviour we set out for in Kona right? I don't think this is actually a huge problem right now. But I'd definitely be up for revisiting/ prioritizing this work after Chicago if we learn otherwise.
I agree. But I don't think I can come up with a simple, not-hairy solution in time. That being said, I don't think we've seen users think of our "stack" of Places Cards as something that's very "linear". I think the important thing here is to drive home the message that "these are some places around you" - which we could have more success doing via other methods such as onboarding/first run, hints, etc. Though I would like to revisit this for after Chicago because of the complexity here. It would take UX some time but we could create a flow chart to document all these scenarios again for everyone. We should also re-prioritize this afterwards with Product if it's a huge problem.
I agree. We should always default to sorting by travel times :) |
@thebnich Is going to get @mariapopova0729 a build to verify the expected behavior, after walking:
|
I verified the behavior of Prox local build while walking around: Whether the user backgrounds the app or has the app on screen while walking around, the cards are refreshed almost instantaneously based on the new location. If the cards DO not get refreshed (which I observed several times), then scrolling through one or two cards results in refreshing the set. It seems like a timing issue and I couldn't reliably expect that the cards will be refreshed without actions on my part. |
This sounds different from what we were describing earlier today. Are you saying that if you're actively using the app and looking through cards, the app refresh will lose the card you're on and start you from the beginning? |
That is correct, the behavior I saw on device while walking around was that cards do get updated and I lose the card I was on. |
OK, I assume we'll want to fix that since that would be a pretty jarring testing experience. |
If we fix this, we may also want to fix:
|
To summarize the behavior: In the future, we could also add some kind of "get newest content" button (or otherwise indicate to the user that new cards are available with some action to refresh). |
I fixed a bug in the existing behavior in #639. |
Verify with antlam it is okay. If not, fix it!
The text was updated successfully, but these errors were encountered: