Yeah, that’s all I meant. It will show the sub decks in order, which can mimic his desire to get that “order added” sort because similar cards will be sorted together. Not gonna be exactly the same of course.
@sorata It stems from them saying this. They seem to want to have “order added” as the secondary sort so that related cards having the same due date will sort together. If they put related cards in a sub deck, they can get the same effect with “due date, then deck.”
Agreed. Too many sort orders are confusing people, or maybe it’s just me who don’t understand how half of them work.
This just is not a realistic option for longterm users with tens of thousands of cards covering hundreds of concepts. Especially, as I understood (at least in 2017 or so), the meta was to avoid having multiple decks, and instead use tags. Perhaps a “Due date, then tag” would be similar to what you describe. But I expect that would be more challenging to implement then what I am describing (“Due date, then Order Added”).
As I tried to suggest, what I am suggesting is intentionally non-arbitrary. Instead, it has a deliberate goal to maximize retention by prioritizing due date, and then prioritizing minimizing time on reviews.
I don’t see why you’d want to avoid multiple decks, but if you have been, you can easily search by tag and send them all to a new sub deck.
But you’re losing that contextual review benefit by sorting by due date first. Again, I understand that your decks are large and you have many reviews per day, but if you have so many decks you can’t feasibly just create sub decks, than you’ll have so many partitions within each due date that you are switching contexts just as much as anyone else anyway.
Also, and this is a slight digression that we don’t need to hash out if you disagree, but I’ve always wanted context switches because if I’m reviewing cards that are too similar, I’m probably remembering them better because my brain is getting primed for that topic already. Your brain won’t be primed when you need that information in the real world, so why practice that way?
I know this isn’t satisfying, but I think you should just sort by “Order Added.” I think it defaults to “Order Due” as a secondary sort, but I don’t know for sure. I don’t think of due date sort as maximizing retention anyway tbh, but that’s another topic.
It is so curious - I felt like years ago the meta/zen was to use “tags” rather than subdecks. Interesting to hear it has switched back! Ultimately, I think for some users using tags, it is unreasonable to make them into subducks. For example in language vocabulary, to achieve the desired result, one might need separate decks for travel, dining out, house, work, hospital, pets, medical visits, etc. I think it would spiral such that the “Due date, then Deck” is not a viable solution for what I posed.
This does seem to be a conceptual disagreement. Obviously my point is there is value of contextual review. But I do not think it should be prioritized over “Due date”. Otherwise, with “Order Created” if several days of reviews have accumulated, the card most overdue might not be seen even after reviewing several hundred cards that day. And that may persist for days (or in perpetuity in an edge case). While the point of the second principle above is to support the value of “Order Created” as a sort variable, I don’t think it should be prioritized over the first principle (which I personally value (and which I thought was part of the meta/zen of SRS/Anki)).
There is evidence from the American Psychology Association to suggest you pay a penalty when switching topics/tasks. It is not clear how well this maps to SRS reviews and long-term retention. Ultimately, I also recognize this affect of priming, and find it desirable than paying 1 or 2s penalty every card for reestablishing the domain I am studying in while doing several hundred reviews per day. I think this is what also motivated the implementation of “Order Added” too.
The manual isn’t updated so you can look up the reasons for why that happened. Display crashing/slowdown issues don’t happen anymore for reasonable number of decks. And we have better gather order/sort orders. So yeah, the meta has shifted.
1 Like
It’s still advisable to use tags for organization when you can – Adding/Editing - Anki Manual – but that doesn’t mean you can’t have more than 1 deck. It just means you shouldn’t have 100s of tiny decks.
It’s fine for you to think that other users are setting their priorities wrong, but that’s not really a basis to change (and break) how this sort order works.
Agreed! This is why “Due date, then Deck” is not a viable solution. Having used Anki for over a decade, I have thousands of tags, some with only 6 or 7 cards. And thus, to achieve a more context specific review, it would require transferring these thousand or so tags into separate decks. I think that is a cumbersome way to achieve the desired behavior with “Due date, then Deck”.
I have never stated users are setting their priorities wrong; but used comparisons to articulate the value of what I am suggesting…
as I was requested to do. I believe Spaced Repetition Systems should work for as many users as possible, and seamlessly as possible to maximize retention with as little input as possible. And I would not impose my belief on others.
You are correct that I did suggest earlier in this thread to change the implementation of a current tool. That was wrong, and born out of a misunderstanding of the calls for it to be implemented in the first place, which you pointed out later.
However, I have also laid out clearly why the suggested sort order has a deliberate, non-arbitrary, benefit by prioritizing the algorithm and user input/data (“Due date”) then contextual review of “cards that are closely linked” - already acknowledged for its utility with its inclusion as a standard Anki sort term.
And after learning this, I am no longer suggesting a reimplementation of an existing setting, but implementation of a new sort order that has articulated value. To be clear - not changing (or breaking) how this sort order works
I have been asked multiple times to articulate the value of this suggestion. I have done so. I have laid this out clearly using principles the primary principles of SRS and the second principal of minimizing user review time to maximize retention.
After articulating this, it has been disappointing no one has focused on its value. I have gathered from colleagues at my institution that “Due date, then Order Added” would save them time (and likely hundreds of others), while still prioritizing the SRS algorithm.
The smaller the tag grouping, the less likely those cards going to fall on the same due date. Those 6 or 7 cards are almost never going to fall on the same date, so sorting by “Due date” first is already keeping those contextually separated.
If you have a tag grouping large enough that multiple cards are falling on the same due date often enough that this matters, put them in a sub deck and sort by “Due date, then deck.” I think this completely solves your problem.
I know you think your solution is easy to implement and this shouldn’t be such a big deal, but while other people disagree, you have a solution here.
1 Like
I would argue a group of cards would need to be at least in the hundreds before this will matter at all, because they’re aren’t going to fall on the exact same due date in very short order. You might get the random one or two that do, but that isn’t saving you hundreds of hours over your lifetime when it’s just a couple one off instances.
1 Like
@rich70521 Thanks for your reply. While there are some tags that are 6-7, several include cards of 60 or 100. Empirically, doing reviews today, what I am describing would indeed by useful and indeed save me time to accomplish reviews while maintaining retention - not one off instances. And if implemented, would likely have saved others time. The solution you propose does not solve the problem as has been pointed out, it is un-ideal for use cases which include what I am describing.
This small number of cards just statistically are not going to be falling on the same due date unless they are brand new. They just won’t. If you know how to run this in a simulation, I think you’ll find that I’m right. You would need a much larger tag grouping for this to matter, and much larger tag groupings are much easier to just throw into their own subdeck and use my suggestion.
But at this point, I think we both understand each other, so I’ll leave it alone and agree to disagree.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.