“Jittering” (spaced repetition systems)
Reference post.
Credit to Nate Meyvis for coming up with the concept & naming it.
“Jittering” is any method which prevents cards that give context about other cards from showing up in reviews temporally close to each other.
From [1]:
Most flashcard users do—and should—create many cards with overlapping information simultaneously. So, for example, you might create these cards back-to-back:
- What is the largest bone in the body? (The femur)
- What is the anatomical name of the shin bone? (The tibia)
- What is the slender bone behind the tibia? (The fibula)
- The tibia is where in the body? (The shin)
- The fibula is where in the body? (The calf / ankle)
These are good, solid flashcards. The problem is that they give information about each other. If you've just seen one of them, you are likely to have been given the information you need to answer others correctly. But we need to be able to recall the information, not just be able to infer it. In life, on the job, or on an exam, you will usually not be given those hints right before your recall is tested.
The best solution here is to try to break up these clusters of cards. […] Your learning becomes much more effective.
One method for jittering involves assigning due dates for cards randomly within some range, rather than deterministically, so that similar cards — which were likely created at similar points in time — are unlikely to show up temporally next to each other. (This is done natively in ZippyFlash.) Another method for jittering involves explicitly marking cards that give context about other cards as “siblings,” and then using an algorithm that explicitly prevents sibling cards from showing up in some predefined temporal distance from each other. (This is done natively with intra-note cards on Anki, but there are Anki add-ons [note: made by the author] that will allow manual sibling marking).
From [2] (some formatting edits on bullets from the original), somewhat more opinionated:
[Anki] tends to treat each card in isolation, at least in the sense that review times are calculated only in terms of a given card. (This assumption--that the review intervals for a card should depend only on a user's history with that card--is taken to be so obvious that it's usually not even mentioned.)
But people often do--and, in my view, very much should-create many cards about related material at a given time.
And, in a system that does not introduce random "jittering" or other mechanisms to spread out clumps of cards that come in together, that will cause the student often to have seen relevant material right before reviewing a given card.
A quick example:
- One day, the user makes or adds 10 cards about blood cells.
- The user immediately studies the cards, and gets 8 of them right easily.
- One day later, the user gets 7 of those 8 right again.
- Six days later--or however long their algorithm dictates--the user starts to study, and those 7 cards come back in a clump. They study the first 6, getting some right and some wrong.
- Now the user studies the seventh card. After their review, the algorithm will schedule the card again as if the material has only been seen three times: on days n, n+1, and n+7. But the user has, mere seconds ago, seen six cards' worth of related material.
Algorithms that consider only the history of a given card, therefore, are working with a huge blind spot. I suspect that addressing the blind spot matters much more for overall quality than algorithmic improvements do, in the current paradigm. (If you're fumbling around in the dark, a little bit of light will help you a lot more than better sneakers.)
References: