Plotting the graph would still require doing simulations, which is slow. Slower than optimization of parameters. So I think we should focus on the relationship between DR and interval lengths and forget about the workload.
1 Like
So are you proposing to show that message for DR=90% as well?
I’m also struggling to understand the unintuitiveness of that message. Seems straight forward to me.
The issue I’m having with your seekbar approach is that it doesn’t look tidy and appealing from a UI perspective, and frankly somewhat more confusing than the current behavior.
So are you proposing to show that message for DR=90% as well?
I want something better. Like a slider with “Longer intervals” and “Shorter intervals” on the ends
Just spitballing, how about we do away with desired retention and ask user to set a daily review load? A sort of rebranding of DR. Or a duolingo like, “Hey, how much time do you want to spend everyday?” and set the DR for the user.
I actually really like this slider, but instead of having DR as something seperate let’s just show a tiny pop-up above the slider showing the DR percentage where the cursor’s at.
Still requires slow simulations. Also, lower DR doesn’t always mean lower workload, which can be unintuitive
2 Likes
@dae thoughts on this?
People would be able to configure DR both via the input field and via the slider. And the hints make it impossible to misunderstand.
(I think I got the length of the blue part of the slider in this image wrong for DR=80%, but eh, whatever)
EDIT: this is better Desired Retention UI Overhaul - #33 by Expertium
I vote against this.
I use Anki because I want to remember most of the material I learn. Desired retention means exactly that: “How much do you want to remember?”
The time I’d have to spend per day really isn’t relevant, as long as I get my cards / reviews done. And if the study time per day increases too much, then I’d just stop doing new cards for a few days or a week.
Besides: Let’s say today are 20 cards due and it is estimated to take me 10 Minutes (0.5 minutes per card). What if I need 45 seconds per card to study the cards today for whatever reason? Whould Anki have to hide the cards, meaning a backlog gets created and my retention would suffer?
I think that would be a neccessary conclusion if the user would set study time instead of desired retention.
I agree it would be confusing because both of them aren’t heavily correlated.
The time cost is only based on the number of reps per day and the duration. So I make this benchmark:
Setting:
- default parameters
- new cards per day: 100
- maximum reviews per day: 600
- duration: 90 days
- desired retention: 70%~99%
It costs ~100ms in my device if the simulations are executed in parallel.
3 Likes
My machine:
parallel_simulate time: [125.17 ms 126.76 ms 128.39 ms]
Yep.
here it is running with 4 cores only (I wanted to check it for lower end systems):
let num_threads = 4; // Set the number of threads you want
ThreadPoolBuilder::new()
.num_threads(num_threads)
.build_global()
.unwrap();
parallel_simulate time: [211.25 ms 213.41 ms 215.55 ms]
I think this is still too much work to be doing every time the user changes a setting though. It would still have to be a “show DR curve” button.
It is still weird to me that my simulation takes longer to execute than all the ones parallelized. I tried to really punish the simulator with 5000 really bad cards
Some(vec![Card {
difficulty: 9.9,
due: 0.,
id: 0,
stability: 1.,
last_date: -1.,
interval: 1.,
lapses: 0,
}; 5000]),
But even on 4 cores and with the simulation config copied over it managed
parallel_simulate time: [495.90 ms 500.27 ms 504.46 ms]
Edit: Maybe it was the converting cards and stuff? I did only call the code repeatedly from JS for testing.
3 Likes
Ok, how about an idea suggested by Brayan: answer buttons that show interval lengths
The interval lengths above answer buttons would change instantly when desired retention is changed
More from Brayan:
put the fsrs parameters at the bottom of the FSRS section
and add some title to the “query input” (idk what is called the<input>form below the parameters)
No idea what to do about fuzz, though
-
Display a range, like 14-18 days: “Why is there a range of intervals in deck options, but only a single interval in reality?”
-
Just add fuzz to intervals, like
ivl + fuzz_factor: “Why do intervals in deck options randomly jump around?” -
Don’t show fuzz: “Why do intervals in deck options do not jump around, but in reality they do?”
this is actually the most meaningful thing to possibly show to the type of person whos issues would be solved by this slider
I see a few issues with this approach.
- Some users might think the answer buttons must always have those intervals as shown in the options (i.e. the intervalls are always fixed at 15m, 23m, 4d, 16d, no matter the card state and review history).
- The intervalls would be vastly different depending on the card state and review history. E.g. new cards will have comparativly short intervalls, whereas other cards might have months of difference between those four buttons. The proposed button view doesn’t really accommodate for that.
1 Like
- Yes, that’s a problem
- We can’t show lots of different intervals for lots of different cards, so this is the best we can do without making the UI incomprehensible
Well, one could show an additional info message like “The intervalls will also change based on card state and your review history”.
But if that’s necessary, maybe the ui design should be updated.
I do like this button version much more than the slider solution though.
Just show a range of interval IMO. There seems to be some consensus on Discord that it wouldn’t cause much issues (#off-topic if anyone visits).
“The intervalls will also change based on card state and your review history”.
Nah, at that point might as well make an entire interactive tutorial (which would be epic, but nobody will do that)
There seems to be some consensus on Discord that it wouldn’t cause much issues
I actually see more consensus in favor of “don’t show fuzz”. Poll time? Poll time!
- Show fuzz ranges, like 14-18 days
- Just add a random fuzz value to the buttons
- Don’t show fuzz at all
0
voters
Just to clarify, I mean “Don’t show fuzz when it comes to fake answer buttons in deck options”, as per Brayan’s idea.
THIS POLL IS ABOUT FAKE ANSWER BUTTONS IN DECK OPTIONS, NOT ABOUT REAL ANSWER BUTTONS
Can we maybe define the problem a bit better? This is what I currently have:
Current State
- FSRS intervals depend on
- Desired Retention
- Card State (e.g. new cards vs. mature cards)
- Fuzz Factor (on vs off)
- The users FSRS parameters
- Changing Desired Retention only shows the base interval, like “A 100 day interval will become 46 days.”
Problem
- There are users that do not understand the relationship between Desired Retention and Interval length.
- There are users that do not understand the relationship between Desired Retention and Workload.
- Getting the users Workload would need simulations, but that would be way too slow.
Desired State
- It should be obvious to the user that the intervals depend on
- Desired Retention
- Card State (e.g. new cards vs. mature cards)
- Fuzz Factor (on vs off)
- The users FSRS parameters
Operators (actions, that’ll solve the problem)
Maybe we could do something like the following instead? It would make it more visually clear what contributes to the interval length. No idea how to incorporate the parameters into the graph though.
This graph then would change based on the DR the user has set, and whether Fuzz is turned on or off. Regarding Fuzz: Since that’s a range, one could have a solid blue block for the minimum interval and a checked one for the max interval.
(and the cards on the y-axis could probably be a bit more meaningful, so that there is an example for new cards, as well as young and mature cards).
I really, REALLY doubt that this would clear confusion as opposed to creating it. Also, I don’t know how I would make a chart like this