Hi guys, there’s some good discussion going on. I’ll try to address the points in the original question and clarify a couple details.
First, there is a a divide between the new mobile apps’ scheduling algorithm and the “classic” Skritter algorithm referenced in the legacy FAQ. The retention index (RI) is only used in our legacy/classic services. It isn’t used in the new mobile apps. I’ll get to why in a little bit. The RI affects scheduling–if you want to keep an index at 95% likely to remember vs. 87%, you’ll see items sooner and more often, like the FAQ says. How often exactly depends on a lot of other factors about the item and when it’s reviewed in relation to how due it is; it’s difficult to give a “one size fits all” graph. But the RI is a minor factor in the scheduling algorithm. Conceptually it is along the lines of the difference between interval * 0.87 and interval * 0.95.
My advice: don’t worry about it. Or if you are going to worry about it, keep it low (I personally have mine set to 87%). You’ll have fewer reviews and make progress faster. Most of the mathematical precision everyone praises about SRS falls apart if a user misses days of study. And even at its best, SRS is a guess at how a person’s memory will be and merely provides an efficient opportunity to re-encounter information they’ve seen before. In the long run, habit and consistency will reap more gains than tweaking a detail of an SRS algorithm. See https://www.hackingchinese.com/when-perfectionism-becomes-an-obstacle-to-progress/ for further philosophical reading.
All that being said, in the new app, we do not take the RI into account and I do have some numbers I can give you (with a caveat). As the RI was an overall minor detail but a complicated mechanic to explain, we decided to rely on other factors for our calculations. Instead, along with the normal SRS calculations, we do a lot of heuristics based on the larger context of the item–we don’t just blindly crunch the numbers. For instance, new items that don’t have many/any attempts and are answered correctly in consecutive reviews get an extra boost to their interval so they space out faster. If a new item’s first few initial attempts were all correct, it’s likely the user already knew the item–this is review after all! Or it’s a super easy item. Either way, we fast-track it so it gets out of the user’s way. Because of heuristics like these and the context around each item, it’s a bit hard to prescribe exact values for item spacing. But if a user reviewed a brand new item correctly at the exact second it was due each time, here’s generally what the interval spacing would look like for the first few attempts:
For the first row (answered only correctly [score of 3]), because of that heuristic I mentioned, the increase is a bit aggressive. On the other hand, an item with an incorrect attempt early on will increase its interval more slowly. The “initial score 1 interval” row shows some intervals for attempts on an item that was marked incorrectly on its first attempt and then correct for each subsequent attempt.
An item’s actual intervals will vary around +/-7.5% as we insert some minor randomness at the end of the calculations to prevent cards from appearing in the same order on different days. In the new algorithm, there is an upper bound on the interval of 1 year. If you don’t want to review something at least once a year, it probably doesn’t belong in an SRS queue. I don’t have the code open at the moment, but I believe the limit on the legacy system was 3 or 5 years.
In general, we’re trying to move away from exposing complicated settings for tweaking the SRS algorithm that, in the long run, adjusting will only have marginal, if any efficacy, and instead, provide better modes for a user to interact with their content. Test mode is a good example of this. Many users over the years have completely messed up their items’ intervals because they overstudied in order to reinforce some vocab for a test the next day. In any event, we’re always discussing how to improve things and welcome your feedback!