[Feature Idea] Unfinished Articles at the top of the feed?

[mircealungu]

Something like this?

This could definitely be useful for beginner users like me, who don't always manage to fully read an article.

Alternatively, we could have the percentage finished information in the history... with a button that would say "Continue reading" near that particular article.

Surely, this depends on having a decent enough "percentage completed" implementation :)

[tfnribeiro]

I think the issue here is the fact that the percentage is based on your screen height - which we do not track currently. We just know the percentage based on the screen you had. So cross-device implementation might be a bit tricky.

We can still report the percentage, but the scrolling back to that position might be a bit more difficult to implement.

Maybe it's possible to take the 66% and put you on the sentence that covers 66% of the text? Maybe that would work?

[mircealungu]

take the following

• the screen height
• the text component height
• the screen scroll percentage

could we figure out scroll percentage of the text based on them?

then we can bring the reader to the sentence that covers 66% of the text as you suggest.

does this make sense?

[mircealungu]

alternative:

• when you go back to a previously studied text we highlight your translations. that gives the beginner reader a good hint of where they were.

and yet a crazier alternative...

• tracking for every paragraph, the duration it had spent on the screen. then color the background in such a way as the paragraphs that have had a long screentime are slightly darker. that way the reader can see where they were left because those paragraphs are white... this would solve the problem of the user quickly scrolling to the end ... although the problem of quickly scrolling to the end can be solved by a low-pass filter: we only save the percentage every 30 seconds or so... so if you scroll quickly it does not get registered?

[tfnribeiro]

take the following

• the screen height
• the text component height
• the screen scroll percentage

could we figure out scroll percentage of the text based on them?

then we can bring the reader to the sentence that covers 66% of the text as you suggest.

does this make sense?

Yes, I think that would work fine, it's just about how to store this information in a nice way, because we have a limit of 4096 characters for the table, so doing a JSON file might take up a lot of characters.

when you go back to a previously studied text we highlight your translations. that gives the beginner reader a good hint of where they were.

This is probably the easiest, but we have no guarantee that a user will use translations. Maybe they were just pronouncing.

I think the tracking option would require a bit of a rework in the backend to function properly and maybe it could make sense for attention tracking, but it's quite demanding to keep track of which elements you are looking at at all times.

I think I can maybe make an event of VIEWPORT_READER_SETTINGS which stores the information we had so we can use the percentage. It will always be an approximate value, as the bigger the screen the larger the impression is. So I think it's OK to just scroll back to where the viewport was when they left the article.

[tfnribeiro]

I did some experimenting with this and actually the formula is quite simple - all we need is the clientViewPort and then recovering the position of the screen is quite straightforward.

    scrollElement.scrollHeight -
    scrollElement.clientHeight -
    shortenPageHeightPixels

We have 2 constants, the total height, which is always the same as it is measured in Pixels, and the bottomRow (shortenPageHeightPixels) which is not part of the text, it's the part where we have the feedback and what not.

So to get the pixel position where the user left we just do:

(scrollElement.scrollHeight - scrollElement.clientHeight - shortenPageHeightPixels) * Percentage where they left off. That should work for whatever screen size, as the pixel position will still be the same.

This means we only need to store the clientHeight when the user read that article, and we can then put them back in the same place. The only thing is that we need to store!

Though one of the things I realized is if you have a large enough port then it won't do much as sometimes the article will fit the viewport - so maybe we only allow this "Return to where you left off" to articles that are longer.

[tfnribeiro]

This is how it looks so far:

[mircealungu]

Looks super good!

I like the info! We could also put translations maybe? Or is it too much? It could be another measure of involvement...

I like the colors and styling. The blue goes well with the zeeguu orange :)

And a thing I wonder is: if one has many unread articles, then the fact that we keep the image takes more space. Should we consider keeping only the title? Although your design is nicer. Another solution could be to only show at most two recent articles. (Or two random ones?) And put a link to "see more" that could go to History (for now)?

I wonder if the search should be placed above the unfinished?

[tfnribeiro]

I don't think translations would be that relevant for me ( ? it can mean engagement / difficulty, but I think it would be more about if you care about to finish that article or not)

And a thing I wonder is: if one has many unread articles, then the fact that we keep the image takes more space. Should we consider keeping only the title? Although your design is nicer. Another solution could be to only show at most two recent articles. (Or two random ones?) And put a link to "see more" that could go to History (for now)?

Right now it's the 2 latest articles that are placed. I could also do the expandable component where a user could click to see the rest of the list. But honestly, I think the 2 most recent ones are OK, and then maybe a place we could redirect the user to see all unfinished articles could be a good solution.

[mircealungu]

Fair enough!

Translations were indeed a measure of engagement for me. But maybe not that essential, given that the learner must remember the article and the level of engagement if it was recent anyway.

2 recent ones + place to redirect suffices. Only thing that might still become necessary at some later point is a way of getting rid of the component maybe? e.g. a setting entitled: "show recent articles"?

[tfnribeiro]

I think we could have a setting that controls that: "Show unfinished articles" which enables the div. We could also make it collapsible so users could just click on it once and quickly get to the articles. But yes, I will work in having a setting to disable it.

I also need some feedback in the actual implementation of the percentage estimation - it's not so straightforward - currently I am using the velocity of the scroll to detect "real" reading and limit how much an update can progress an article - it seems to work OK, but it would be nice to review. We can do it Friday

[mircealungu]

Yes, less talk on Friday!

M

On Wed, 14 Aug 2024 at 12.49, Tiago Ribeiro @.***> wrote:

I think we could have a setting that controls that: "Show unfinished articles" which enables the div. We could also make it collapsible so users could just click on it once and quickly get to the articles. But yes, I will work in having a setting to disable it.

I also need some feedback in the actual implementation of the percentage estimation - it's not so straightforward - currently I am using the velocity of the scroll to detect "real" reading and limit how much an update can progress an article - it seems to work OK, but it would be nice to review. We can do it Friday

— Reply to this email directly, view it on GitHub https://github.com/zeeguu/web/issues/456#issuecomment-2288431729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADRNB3QJH3Y5P4GFPZY63DZRMY4PAVCNFSM6AAAAABMGLPUJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBYGQZTCNZSHE . You are receiving this because you authored the thread.Message ID: @.***>