The Problem
It was requested in #4 to implement A-factor (a multiplier associated with the individual IncRem), like in SuperMemo. Particularly, I don’t see relevance. Multiplying by 1.2 ou 1.5 or 1.8 - what would it change? At least it wouldn’t solve the use case of an entire book that would require 100x + repetitions to be seen in its entirety. In a regular overloaded incremental reading flow, the topic interval has very little relevance. It is only a "minimum interval" to be used in your top priority material to avoid too frequent exposition. But what would be the common place for a lower priority IncRem is an extract that gets an interval of 3 days not being reviewed but in 100 days (if ever).
Somebody requested implementing custom schedules (rem-specific, via a new property to Incremental tag). When pressing the "Reschedule" button, we would include some more stuff to the widget, allowing the user to apply custom schedulers to that IncRem. This would be especially helpful for these cases of long PDFs / books /articles. I thought in options like Every Day, Every Other Day, Every 3 Days, Every Week, as well as a maximum interval (following the scheduler, but capping it if larger than the max int). This can be considered for the future.
As I understand it, while the spacing effect is well documented and also applies to passive reading (putting some space in between reading sessions is beneficial to memory), I am absolutely convinced that there is no such thing as an "optimal interval" for passive reading (i.e., Incremental Rems).
The interval usually is not relevant and works more like a minimum interval to ensure spacing, but what drives the presentation order is the priority (NextRepDate is kind of unimportant).
So the goal, as I see it, is encompass different workflows without hurting the scientifically proved principles.
1st step toward an improved Scheduler
One flow that needs a better treatment is that of long articles/PDFs. They will require multiple repetitions, and the intervals will grow beyond what is reasonable. While there is a "Reschedule" button that certainly helps, it only affects the current interval. All the future intervals will not be shortened (as the scheduler counts the number of repetitions and multiply it by the multiplier). For these cases, we need to improve the workflow.
It is important to mention that the current behavior of the scheduler is good for other workflows. E.g. Imagine that you face a text that is too complex for you to understand. You import some explanatory material to your Knowledge Base that will help you grow your understanding of the subject, make this import Incremental, and Reschedule the original complex material to, let's say, 60 days. After this period, the material will come back to your queue, but not with a gigantic interval. So, there is place for the current scheduler behavior, and it should be preserved.
What I suggest is to implement an option in the Reschedule widget to, instead of applying the multiplier over the repetition counts, to apply it over the last registered interval. For this sake, we would need to store it in the "History" slot of the Incremental powerup. And this option would have to be stored somewhere (maybe also in the History slot; the scheduler would then look for the current option, and apply the multiplier either over the rep counts or over the last interval; the current behavior should be the fall back in case no option is found; the option should persist in the rep history registries until it is changed).
This way, if I am reading an entire book, when the interval gets too long I can use Reschedule, set a small interval (let's say, 1 day), and opt to use the last interval instead of the rep count. After a few repetitions, when the interval gets too long again, I could reschedule to 1 day again. This way we would avoid the user having to Reschedule in every single repetition.
@randygrok and @bjsi - What is your opinion here?
The Problem
It was requested in #4 to implement A-factor (a multiplier associated with the individual IncRem), like in SuperMemo. Particularly, I don’t see relevance. Multiplying by 1.2 ou 1.5 or 1.8 - what would it change? At least it wouldn’t solve the use case of an entire book that would require 100x + repetitions to be seen in its entirety. In a regular overloaded incremental reading flow, the topic interval has very little relevance. It is only a "minimum interval" to be used in your top priority material to avoid too frequent exposition. But what would be the common place for a lower priority IncRem is an extract that gets an interval of 3 days not being reviewed but in 100 days (if ever).
Somebody requested implementing custom schedules (rem-specific, via a new property to Incremental tag). When pressing the "Reschedule" button, we would include some more stuff to the widget, allowing the user to apply custom schedulers to that IncRem. This would be especially helpful for these cases of long PDFs / books /articles. I thought in options like Every Day, Every Other Day, Every 3 Days, Every Week, as well as a maximum interval (following the scheduler, but capping it if larger than the max int). This can be considered for the future.
As I understand it, while the spacing effect is well documented and also applies to passive reading (putting some space in between reading sessions is beneficial to memory), I am absolutely convinced that there is no such thing as an "optimal interval" for passive reading (i.e., Incremental Rems).
The interval usually is not relevant and works more like a minimum interval to ensure spacing, but what drives the presentation order is the priority (NextRepDate is kind of unimportant).
So the goal, as I see it, is encompass different workflows without hurting the scientifically proved principles.
1st step toward an improved Scheduler
One flow that needs a better treatment is that of long articles/PDFs. They will require multiple repetitions, and the intervals will grow beyond what is reasonable. While there is a "Reschedule" button that certainly helps, it only affects the current interval. All the future intervals will not be shortened (as the scheduler counts the number of repetitions and multiply it by the multiplier). For these cases, we need to improve the workflow.
It is important to mention that the current behavior of the scheduler is good for other workflows. E.g. Imagine that you face a text that is too complex for you to understand. You import some explanatory material to your Knowledge Base that will help you grow your understanding of the subject, make this import Incremental, and Reschedule the original complex material to, let's say, 60 days. After this period, the material will come back to your queue, but not with a gigantic interval. So, there is place for the current scheduler behavior, and it should be preserved.
What I suggest is to implement an option in the Reschedule widget to, instead of applying the multiplier over the repetition counts, to apply it over the last registered interval. For this sake, we would need to store it in the "History" slot of the Incremental powerup. And this option would have to be stored somewhere (maybe also in the History slot; the scheduler would then look for the current option, and apply the multiplier either over the rep counts or over the last interval; the current behavior should be the fall back in case no option is found; the option should persist in the rep history registries until it is changed).
This way, if I am reading an entire book, when the interval gets too long I can use Reschedule, set a small interval (let's say, 1 day), and opt to use the last interval instead of the rep count. After a few repetitions, when the interval gets too long again, I could reschedule to 1 day again. This way we would avoid the user having to Reschedule in every single repetition.
@randygrok and @bjsi - What is your opinion here?