Improving sort orders

@dae this post is meant to be a clean version of this.

First of all, right now there are way too many different sort orders:
image
Even for an advanced user, this is unnecessary. For a newcomer, this is absolutely overwhelming.

Thankfully, we don’t have to guess which ones are better, because Jarrett already figured that out via simulations: review-sort-order-comparison/notebook.ipynb at main · open-spaced-repetition/review-sort-order-comparison · GitHub

PRL is Potential Retrievability Loss. PRL = R(Today) - R(Tomorrow)

Additionally, I made a table of sort orders that can maintain retention at a constant level even if the user never gets through the backlog.

The two major takeaways:

  1. If the user can do literally any number of reviews per day, the order doesn’t matter.
  2. If the user can only do a limited number of reviews per day, then Retrievability Descending is the best in terms of spending the least amount of time studying while still maintaining retention at the desired level.

My proposal: only keep the four sort orders that can maintain retention at the desired level even in the presence of a backlog: Retrievability Descending (aka Reverse Relative Overdueness), Add Order Descending, Stability Ascending, Interval Ascending. Remove all other sort orders.
Yes, there will be people who will say, “But I love this sort order!” but this will still be a positive change. It will greatly reduce the cognitive burden since instead of figuring out 11 sort orders, the user will only need to figure out 4 (3 with SM-2 since it doesn’t have stability), and it will make sure that no matter what the user chooses, it will be effective in the presence of a backlog.

If you really want to keep all this zoo of sort orders, you can add “Custom” that opens a new window where the user decides the metric as well as the order (ascending/descending). So there would be 3-4 pre-defined orders and “Custom”.

Lastly, if you don’t feel like making this big change right now, at least add Reverse Relative Overdueness (aka Retrievability Descending), as it’s objectively the best. Might be worth naming it Least Overdue First, and renaming Relative Overdueness to Most Overdue First.


Please do not comment here unless you are Dae or LMSherlock. If you want a discussion, please visit this topic: Ordering Request: Reverse Relative Overdueness - #28 by Expertium.

5 Likes

New users typically aren’t changing the order, so I don’t feel the existing count is a particularly pressing issue. Some of those orders are there not because they’re the most efficient, but because they’re the order some users prefer to study.

If simulations are showing a different order is more efficient, it sounds like we should add it. I’ve logged that on Add 'reverse relative overdueness'; consider making it the default · Issue #3460 · ankitects/anki · GitHub

Regarding the wording, ‘least overdue first’ reads easily, and I don’t mind it, but it no longer communicates that the overdueness is relative, so users may assume it works based on the number of days a card is overdue without regard to the card’s interval.

7 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.