✨ [Feature request]: Enhance The Trending Plays on the Home Page

[atapas]

Is your feature request related to a problem? Please describe. It is an enhancement request to tackle the Trending Plays on the Home Page. It is hardcoded in DB now. Change it based on the number of likes.

Describe the solution you'd like Query the plays in sorted order of "likes" and show 4 plays got the most liked.

Additional context Once implemented, we can drop the "featured" columns in the plays table.

[ammaaraslam]

Hi @atapas! I'll do it.

[Angryman18]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

[atapas]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

The UI structure won't change. Ive shared the query with @ammaaraslam that will fetch plays sorted descend on likes. We just need to use it using our service queries whatever existing ui needs.

[koustov]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

On graphql queries, if we need to sort it in the backend then also the front needs to be updated as the function name will get changed. Ideally , we just need to drop the featured column from the query and add order_by in the front end.

Note: The above sentence makes sense only when MOST LIKED = TRENDING.I consider both are different, trending should be based on date range, something like trending this month. Lets wait for new UI wireframe to debate on it :)

[Angryman18]

oh yes query has be changed also. i also agree for both to be different. trending plays can be measured from page views or using some different mechanism if there.

[atapas]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

On graphql queries, if we need to sort it in the backend then also the front needs to be updated as the function name will get changed. Ideally , we just need to drop the featured column from the query and add order_by in the front end.

Note: The above sentence makes sense only when MOST LIKED = TRENDING.I consider both are different, trending should be based on date range, something like trending this month. Lets wait for new UI wireframe to debate on it :)

That's correct about trending. We need to have a time range associated with it. When I think about the trendy and plays, I liked the model hashnode uses for trending tags, blogs, etc. It's not like any chart or graphs but a list of items on a time range. I'm inclined towards the same.

https://hashnode.com/explore/blogs?category=week

Also, we should go iterative in our approach. As we have the liked data, we can build the trending with the like model to start with. The model can be enhanced at the back with views, comments, anything without changing the UI structure much.

So suggest not to wait to get the final algo ready. As per the UI structure goes, yes waiting on @nirmalkc .

[ammaaraslam]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

On graphql queries, if we need to sort it in the backend then also the front needs to be updated as the function name will get changed. Ideally , we just need to drop the featured column from the query and add order_by in the front end.

Note: The above sentence makes sense only when MOST LIKED = TRENDING.I consider both are different, trending should be based on date range, something like trending this month. Lets wait for new UI wireframe to debate on it :)

I agree with this @koustov, I too have the same opinion to Most Liked and Trending plays. I think it's better as @atapas suggested to go with a starting algo first. This can then be altered down the road, depending on the UI structure.

Anyways, I'll start working on the algo using the JS services for query. I've decided to base the query only on number of likes in a specific time range as we still do not have a value for number of page views or any other metrics. Any suggestions before I start building?

[atapas]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

On graphql queries, if we need to sort it in the backend then also the front needs to be updated as the function name will get changed. Ideally , we just need to drop the featured column from the query and add order_by in the front end. Note: The above sentence makes sense only when MOST LIKED = TRENDING.I consider both are different, trending should be based on date range, something like trending this month. Lets wait for new UI wireframe to debate on it :)

I agree with this @koustov, I too have the same opinion to Most Liked and Trending plays. I think it's better as @atapas suggested to go with a starting algo first. This can then be altered down the road, depending on the UI structure.

Anyways, I'll start working on the algo using the JS services for query. I've decided to base the query only on number of likes in a specific time range as we still do not have a value for number of page views or any other metrics. Any suggestions before I start building?

I think so. @koustov what's your take?

[atapas]

yeah but we are again ending up making the plays call on the homepage. i think we do the sorting thing backend and send most liked plays on same graphql call meaning no frontend changes will be required. looking forward for other thoughts

On graphql queries, if we need to sort it in the backend then also the front needs to be updated as the function name will get changed. Ideally , we just need to drop the featured column from the query and add order_by in the front end. Note: The above sentence makes sense only when MOST LIKED = TRENDING.I consider both are different, trending should be based on date range, something like trending this month. Lets wait for new UI wireframe to debate on it :)

I agree with this @koustov, I too have the same opinion to Most Liked and Trending plays. I think it's better as @atapas suggested to go with a starting algo first. This can then be altered down the road, depending on the UI structure. Anyways, I'll start working on the algo using the JS services for query. I've decided to base the query only on number of likes in a specific time range as we still do not have a value for number of page views or any other metrics. Any suggestions before I start building?

I think so. @koustov what's your take?

I've some more findings.

As we have the Umami integrated, we have better ways to get the page view already for a period(week and month is what I am suggesting to start with)

URI: GET /api/website/{id}/pageviews

Note: Gets pageviews within a given time range.

Parameters

start_at: Timestamp (in ms) of starting date
end_at: Timestamp (in ms) of end date
unit: Time unit (year | month | hour | day)
tz: Timezone (ex. America/Los_Angeles)

Sample Response

{
    pageviews: [
        {t: "2020-04-20 01:00:00", y: 3},
        {t: "2020-04-20 02:00:00", y: 7}
    ],
    sessions: [
        {t: "2020-04-20 01:00:00", y: 2},
        {t: "2020-04-20 02:00:00", y: 4}
    ]
}

Please check more details from here: https://umami.is/docs/api

[atapas]

Hey @ammaaraslam are you on it?

[ammaaraslam]

Hey @ammaaraslam are you on it?

Hi @atapas , sorry I wasn't able to complete as I was not feeling well these days. Now, I'm back on track and currently fixing an issue in the NPM package.

I'll finish and push a PR with this feature in the next 2 or 3 days. Sorry for the delay.

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!