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
[Feature] Pausing for Quickly-Flashed Content #1940
Comments
Consecutive flashes of information (or paginated) might be an issue for pausing, maybe supporting multiple timestamps would have to be required
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's long been a trend in YouTube videos to flash small bits, or even full walls of text and other content, on screen in a manner as to disallow absorbing them in entirety during casual viewing. This necessitates viewers jogging back and spamming the space bar (or using the oft-forgotten , and . keys) until they land in the correct spot. I assume everyone here is familiar with this editing style, but I can provide examples if need be.
A new category for "Flashed content" (name TBD) could alleviate this unnecessary burden on viewers by triggering one of a few possible actions when the marker comes up. Whether the action is determined only by individual user settings or also determined on a per-submission basis by the contributor is up for debate and depends on the behaviors implemented. Some possible actions would be:
Action 1. would be undesirable in many cases as it requires further user interaction. However, to accommodate high variance in reading speeds, this behavior should probably be a setting available to users.
Action 2. may require contributors to make assumptions about users' reading/absorption speed, but could primarily be used to allow time for viewers to pause if they wish. The flexibility here also allows contributors to extend the time the content spends on screen by only small amounts, in the case of short content which can reasonably be absorbed in, say, just twice the time on screen. Additionally, the length of time could be only a user setting.
Action 3. is possibly undesirable, as it requires contributors to specify a short segment by often very fine amounts. I.E., submitting a "Flashed Content" with this behavior would require specifying a very precise segment (potentially down to exact frames), and not just a single atomic marker during the flash. However, this behavior offers a lot of control and a per-user setting to override the slowing factor may make it especially useful. I simply believe the burden of setting fine segments could leave the feature largely unused (I may be very wrong).
There are likely other possible behaviors, but these are what immediately came to mind.
This feature would not only be useful for many people in the general case, but also serves to accommodate slower readers, those with slower reaction times, and more. It would help to further legitimize SponsorBlock as an accessibility tool, while simultaneously enhancing the viewing experience for those who do not wish to go frame-by-frame in YouTube videos to catch potentially important information — a large cohort I assume.
If this feature gets positive feedback (or if contributors doubt its usefulness), I could work on an implementation in the coming weeks, but currently I have little free time and essentially zero extension dev experience. In the meantime, thanks all for reading.
The text was updated successfully, but these errors were encountered: