Refresh homepage if it's sitting open and idle #6171

Open
opened 2021-06-03 23:43:17 +02:00 by kauffj · 4 comments
kauffj commented 2021-06-03 23:43:17 +02:00 (Migrated from github.com)

After X minutes of being open plus Y seconds of idleness (i.e. don't reload while user is moving mouse, etc.), reload the homepage or category pages to show the latest content.

After X minutes of being open plus Y seconds of idleness (i.e. don't reload while user is moving mouse, etc.), reload the homepage or category pages to show the latest content.
tzarebczan commented 2021-06-03 23:45:19 +02:00 (Migrated from github.com)
https://github.com/lbryio/lbry-desktop/issues/4876 will close :)
dan-peterson commented 2021-09-16 00:44:30 +02:00 (Migrated from github.com)

Hey, I'd be happy to look in to this. I'm new to the code, and to an extent LBRY, so bear with me while I think out loud a bit:

1) In what areas are we concerned about stale content?

@tzarebczan you had mentioned the homepage and @kauffj you had mentioned category pages too.

What about other areas where videos are being listed / filtered / ordered?

Do we benefit at all by framing this more generically as being applicable to "video listings" instead of certain "pages"?

Or perhaps this just starts to push this task needlessly beyond its intended scope?

2) Thoughts on alternative UX patterns?

An alternative that might be worth considering is some kind of stale content indicator in the UI with the option for the user to refresh, as opposed to an automatic refresh.

A go-to example of this would be Twitter. When returning to the app, the interface is exactly as it was, but an indicator will be shown alerting the user that the content has become stale, giving them the option to refresh.

The primary benefit to this approach is that it avoids any confusion or loss of continuity, especially when the user has been scrolling in an infinite-scroll area.

This could still be driven by a time elapsed / user idle mechanism.

Anyways, just spitballing here without intimate knowledge of the product or breadth of the original goal. Curious to hear what others think!

Hey, I'd be happy to look in to this. I'm new to the code, and to an extent LBRY, so bear with me while I think out loud a bit: **1) In what areas are we concerned about stale content?** @tzarebczan you had mentioned the homepage and @kauffj you had mentioned category pages too. What about other areas where videos are being listed / filtered / ordered? Do we benefit at all by framing this more generically as being applicable to "video listings" instead of certain "pages"? Or perhaps this just starts to push this task needlessly beyond its intended scope? **2) Thoughts on alternative UX patterns?** An alternative that might be worth considering is some kind of stale content indicator in the UI with the option for the user to refresh, as opposed to an automatic refresh. A go-to example of this would be Twitter. When returning to the app, the interface is exactly as it was, but an indicator will be shown alerting the user that the content has become stale, giving them the option to refresh. The primary benefit to this approach is that it avoids any confusion or loss of continuity, especially when the user has been scrolling in an infinite-scroll area. This could still be driven by a time elapsed / user idle mechanism. Anyways, just spitballing here without intimate knowledge of the product or breadth of the original goal. Curious to hear what others think!
tzarebczan commented 2021-09-28 16:11:06 +02:00 (Migrated from github.com)

Hey @dan-peterson , sorry for not getting back to you sooner on this.

  1. There's probably other areas that benefit, like the category and channel pages - that probably covers the majority of areas where content may update in a fashion that the user should be alerted to it.

  2. I like the idea of a sale content indicator, this will probably avoid lots of the UX issues with refreshing automatically. Something along the lines of 5-10 minute intervals should work - this would refresh whatever query(ies) drive the page the user is on, and then compare to the visible data. Once you know there's an update, there's probably no need to keep checking for newer ones - the refresh action the user takes would probably re-query to get the latest.

Maybe @kauffj has some other ideas here too!

Hey @dan-peterson , sorry for not getting back to you sooner on this. 1) There's probably other areas that benefit, like the category and channel pages - that probably covers the majority of areas where content may update in a fashion that the user should be alerted to it. 2) I like the idea of a sale content indicator, this will probably avoid lots of the UX issues with refreshing automatically. Something along the lines of 5-10 minute intervals should work - this would refresh whatever query(ies) drive the page the user is on, and then compare to the visible data. Once you know there's an update, there's probably no need to keep checking for newer ones - the refresh action the user takes would probably re-query to get the latest. Maybe @kauffj has some other ideas here too!
dan-peterson commented 2021-10-05 05:39:43 +02:00 (Migrated from github.com)

@tzarebczan Yeah the way you described it working makes sense to me.

The UI is a bit tricky. If we gave each feed on the homepage a bit of a header this would give us some space to introduce a stale state indicator.

I think doing so could be beneficial for other UX reasons as well. (the sections sort of all flow together and arguably they aren't immediately distinguishable from one another)

The other areas already have a header with controls established.

Here's a rough example of what I mean (not intended as a final draft, just brainstorming)

Home

@tzarebczan Yeah the way you described it working makes sense to me. The UI is a bit tricky. If we gave each feed on the homepage a bit of a header this would give us some space to introduce a stale state indicator. I think doing so could be beneficial for other UX reasons as well. (the sections sort of all flow together and arguably they aren't immediately distinguishable from one another) The other areas already have a header with controls established. Here's a rough example of what I mean (not intended as a final draft, just brainstorming) ![Home](https://user-images.githubusercontent.com/1827853/135956289-e366e234-abb9-4670-af77-31e052bd4b11.png)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry-desktop#6171
No description provided.