Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaPlayer: Mark as read on audio/video completion #2684

Merged
merged 2 commits into from
Jul 28, 2024

Conversation

ztec
Copy link
Contributor

@ztec ztec commented Jun 7, 2024

When listening to enclosure media like Podcasts or Peertube feeds, you now have an option to mark the entry as read when the playback reach 90% instead of right after viewing the entry page.

Settings

In order to do that, I had to modify every place where the MarkAsReadOnView decision was made. To centralize the new condition I moved it in the entry entity. It create a coupling with the user model. I could have put it in the user model but the coupling would be the same. I'm not aware of a more suitable place to put this kind of small code (such as an utils module)

If the new option is enabled, the existing option mark as read on view will only trigger if the entry has no audio or video enclosure at all. Image enclosure are excluded because they are not relevant for the feature in my opinon.

I've rename the handlePlayerProgressionSave to accommodate the new behavior. I could have created another function but this would have duplicate some code, I felt it is better to just add the new behavior in the end. Debatable of course. In order to mark as read I reused the handleEntryStatus function. This has the advantage to show the status change on the unread/read button on top.

The user model have a new setting, and I've added a new DB migration to add the field as well.

The completion trigger is defined by the data-mark-read-on-completion value. It is a percentage (from 0 to 1).
For now I've hardcoded the value to 0.9 => 90% but maybe we will feel the need to make it configurable at some point. (on a by feed basis)

I've tested the feature on

  • firefox - linux
  • vivaldi - android

I've checked the mark as read button and player behavior on

  • unread entry pages
  • search entry pages
  • categories entry pages
  • history entry pages
  • unread list
  • categories list
  • history list

TODO before getting the PR out of Draft

  • i18n integration

Do you follow the guidelines?

@ztec ztec force-pushed the markAsReadWhenListened branch 2 times, most recently from 41626fa to 5d2621b Compare June 13, 2024 10:05
@ztec
Copy link
Contributor Author

ztec commented Jun 13, 2024

The PR is ready for review.

As mentioned by @rdelaage in the issue #1847 (comment), Maybe this option should be complemented by a feed override option. Depending of how the global option is welcomed and how people use it I can implement it.
Considering minimalist philosophy I'm personally convinced it's best to have only one global option.

@ztec ztec marked this pull request as ready for review June 13, 2024 10:13
internal/model/entry.go Outdated Show resolved Hide resolved
@@ -114,6 +114,7 @@ <h1 id="page-header-title">{{ t "page.settings.title" }}</h1>
<label><input type="checkbox" name="show_reading_time" value="1" {{ if .form.ShowReadingTime }}checked{{ end }}> {{ t "form.prefs.label.show_reading_time" }}</label>

<label><input type="checkbox" name="mark_read_on_view" value="1" {{ if .form.MarkReadOnView }}checked{{ end }}> {{ t "form.prefs.label.mark_read_on_view" }}</label>
<label>↳ <input type="checkbox" name="mark_read_on_enclosure_completion" value="1" {{ if .form.MarkReadOnEnclosureCompletion }}checked{{ end }}> {{ t "form.prefs.label.mark_read_on_EnclosureCompletion" }}</label>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove the

Copy link
Contributor Author

@ztec ztec Jun 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The is here to show that this options modify the previous option's behavior. Initially it was directly included in the wording but I found it a bit misleading and reworded it.
The two options are independently enablable but the second will affect the first when enabled (actually disabling it when audio/video enclosures are present)

Of course I can remove the arrow, you decide in the end. I just feel there is something missing without it and I don't have any better proposition that would not require a complete paragraph to explain properly the option in the UI.
Are you sure you want to remove it ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My main concern is from an accessibility point of view. I don't know how will be interpreted by screen readers. Also, from a usability perspective it might confuse some users.

Perhaps, the web ui could be changed to a list of choices to make things more explicit:

image

The logic to process the form might be more complex, but at least no additional Javascript is required.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to experiment and see If I can implement something like you suggest.

Copy link
Contributor Author

@ztec ztec Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My last commit (df849fc) contains a proposition. Can you have a look and tell me if it is ok for you ?
The commit is not mergable as is, I'm just asking for a global opinion on the way I did it. If it feel ok for you,
I will polish the changes and integrate the missing i18n translations. If you have any remarks, I will work on them.

As I stated in the commit , few tweaks may be added (CSS). Also the final options text is open to better suggestions. the current proposition contains the necessary information in my opinion but may clearly be improved.

The actual result from the web:
Radio options

I tested the setting form and each 4 options on the undread entry pages.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks okay to me, but I would reword the text because the sentence is quite long. Maybe something more concise like this:

  • Automatically mark entries as read when viewed
  • Mark entries as read when viewed. For audio/video, mark as read at 90% completion
  • Only mark as read when audio/video playback reaches 90% completion
  • Mark entries as read manually

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've put your suggestion into the form and setup the i18n accordingly. The Length is still an issue in the literal french translation I made tho. Not a big deal I think.

internal/database/migrations.go Outdated Show resolved Hide resolved
internal/locale/translations/fr_FR.json Outdated Show resolved Hide resolved
@ztec
Copy link
Contributor Author

ztec commented Jun 17, 2024

I've re-tested on firefox-linux all the usecase I listed previously after the changes.

@ztec ztec marked this pull request as draft June 25, 2024 13:53
When listening to enclosure media like Podcasts or Peertube feeds,
you now have an option to mark the entry as read when the playback
reach 90% instead of right after viewing the entry page.

In order to do that, I had to modify every place where the MarkAsReadOnView
decision was made. To centralize the new condition I moved it in
the `entry` entity. It creates a coupling with the `user` model.
I could have put it in the user model but the coupling would be the same.
I'm not aware of a more suitable place to put this kind of small code (such as an `utils` module)

If the new option is enabled, the existing option `mark as read on
view` will only trigger if the entry has no audio or video enclosure at all.
Image enclosure are excluded because they are not relevant for the feature in my opinion.

I've renamed the `handlePlayerProgressionSave` to accommodate the new behavior.
I could have created another function but this would have duplicate some code,
I felt it is better to just add the new behavior in the end. Debatable of course.
In order to `mark as read` I reused the `handleEntryStatus` function.
This has the advantage to show the status change on the `unread/read` button on top.

The user model have a new setting, and I've added a new DB migration
to add the field as well.

The completion trigger is defined by the `data-mark-read-on-completion` value.
It is a percentage (from 0 to 1).
For now, I've hardcoded the value to 0.9 => 90%, but maybe we will feel the need
to make it configurable at some point. (on a by feed basis)

I've tested the feature on
 - firefox - linux
 - vivaldi - android

I've included English and French i18n version.

I've checked the `mark as read` button and player behavior on
 - unread entry pages
 - search entry pages
 - categories entry pages
 - history entry pages
 - unread list
 - categories list
 - history pages
@ztec
Copy link
Contributor Author

ztec commented Jul 25, 2024

I've rebase and all, re-did the tests I've mentioned in my initial comment. All seems ok

@ztec ztec marked this pull request as ready for review July 26, 2024 10:12
@fguillot fguillot linked an issue Jul 28, 2024 that may be closed by this pull request
@fguillot fguillot merged commit 4f55361 into miniflux:main Jul 28, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Media player: Mark as read when playback reached the end
2 participants