shouldn't the UI show which graph it is?

It's kind of inferred by the "Ratio" in the radio buttons, I'm not sure where I'd fit a title.

Maybe under the x axis?

Can we make a DR/workload and per-day-workload graph on the same canvas? What happens when you try to do that?

It clears the graph whenever you simulate after using the "Desired Retention info" graph and vice versa.

Maybe make a toggle button? The toggle state tells you what graph you're
looking at.

Something like this?

IMO, a memorized-vs-DR graph doesn't provide much value, especially if all the values are obtained by using the same new card limits. What about mentioning the number of memorized cards in the tooltip of the other graphs instead?

Edit:
The user can plot multiple graphs with different new card limits. So, the graph will be useful. However, my other suggestion still stands — we can mention the number of memorized cards in the tooltip of the other graphs too.

The user can plot multiple graphs with different new card limits. So, the graph will be useful. However, my other suggestion still stands — we can mention the number of memorized cards in the tooltip of the other graphs too.

if they wanted the memorised card count, I feel it would be best to switch between the 2 graphs? I feel the tool-tip might be overly cluttered by this.

Should we disable "Maximum reviews / day" in the DR mode? A low daily reviews setting masks the impact of increasing the DR on the review count, which is exactly what we are trying to illustrate here.

Also, we can replace all usages of timespan(value) in simulator.ts with timespan(value, false, true, TimespanUnit.Hours) to limit the study time to hours. Related PR:

• Limit study time to hours in reviews graph #4086

Edit: We won't require this because I have another suggestion.

• In the Time graph, we should plot the average time spent per day because the total time is difficult to interpret.
• In the Ratio graph, the ticks on the y-axis look wrong.

For many users, the time recorded in the revlogs doesn't reflect the actual time they spend reviewing on Anki (myself included). So, it is very important to have an option to display the number of reviews on the y-axis instead of the time.

Second the suggestion to hide/ignore max reviews/day, and maybe hide some of the others as well? What if instead of having a toggle between the two modes, you have a button/link in the deck options page near the DR setting (something like "Help Me Pick") that presents the graph without any further clicks required? I presume this is a feature we'll want users to be able to access easily / not hide behind an "experimental" tag?

Given the downsides of graphing by time and how we already have a reviews mode, does it still make sense to be showing time as well? And is there much. value from the Memorized mode?

Would it be worth showing yellow/red for high DRs? If changing the line color dynamically is hard, made we could just overlay some semi-transparent rectangles over portion of the graph? Or a gradient?

Beyond a certain point, you'll just deduce that all DRs output the same number of reviews for you. That's an useful thing to know. Sure, there's an abstract idea of "cards getting due each day" but that doesn't matter for the number reviews until you decide to uncap the limit.

I also noticed that the DR and max reviews/day can have unexpected curves in memorised count. For example, in one of my decks memorised count first increases as I increase my DR, then it starts to fall at some point.

Expertium raises a valid point too, it's not a newb friendly thing to do. We want the sim to actually reflect what's happening IRL.

I hope remain max reviews.
If max reviews are removed, it would be bad news for users who want to test the effect under conditions with max reviews.
If max reviews are remained, users who don't need max reviews can simply set max reviews to 99999 or higher.
Therefore, keeping max reviews would accommodate a wider range of user needs.

I can appreciate the argument for factoring in the review limit, though it still feels a bit counterintuitive to me. I don't feel strongly enough about it or the color gradient to push further if the majority are in favour of the alternative.

IMO a warning is the best option. If someone set their max. review limit so low that they just get a flat line on the desired retention - workload graph because the workload is artificially cut off, we can display a colored box that explains it.
I really don't see how disabling the limit is a good idea, considering that it will make the desired retention - workload graph unrealistic.

Would it be worth showing yellow/red for high DRs? If changing the line color dynamically is hard, made we could just overlay some semi-transparent rectangles over portion of the graph? Or a gradient?

How should we handle this if multiple graphs are plotted?

I hadn't even considered the multiple plots case. Let's just forget about it for the MVP.

I've made it so that when the workload modal opens, the review limit is set to 9999. This can be counter intuitive if the user alternates between the workload simulator and the regular simulator as this value will carry over between them, but I assume that this is a simpler way of solving the problem? The user would definitely be making a conscious decision at that point.

Dae gave the following argument for removing the "Time" mode and I agree.

For the time graph, you've already pointed out that it's wrong for a bunch of people, and keeping it around adds more visual noise for everyone. Given that reviews should be a roughly equivalent curve, wouldn't it make more sense to focus on the most useful modes that don't have caveats?

If we do this, we should also change Time per Memorized to Reviews per Memorized.

Why does this option say "Experimental"? Isn't the simulator very accurate now?

The estimation of time will be more accurate: open-spaced-repetition/Anki-button-usage#2

That said, I don't have strong feelings about Time per Memorized vs Reviews per Memorized. What I do have strong feelings about is 628bfe2. I think a warning is much better.

The calculation of time will be more accurate

For my case, no value (mean or median or 100th percentile or whatever) can be accurate because, for many cards, I spend more time per review than the default "maximum answer seconds" setting and I never changed it (because before the simulator, there was no advantage of doing that).

In addition, I don't do all of my reviews in one go. I do them in small blocks of time I get throughout the day. So, it is very difficult for me to know exactly how much time I spend reviewing per day. On the other hand, the number of reviews per day is very easy to know.

I am sure that there are many users out there with similar problems.

There are no caveats with reviews. So, IMO, there is no reason to not use reviews in place of time.

In fact, I would also say that we should modify the workload helpbox in Deck Options to use reviews instead of time as the measure of workload.

In fact, I would also say that we should modify the workload helpbox in Deck Options to use reviews instead of time as the measure of workload.

IIRC I showed this to Dae and said, "It's up to you to decide since there is no consensus", and he said "time". It seems like a significant proportion of users won't be happy either way.

The downsides of time calculation were not in my head at time, though.

Thanks for all your work on this Luc. It could use a bit more polish, but I'll merge it in so we can get it into the hands of beta testers. Some thoughts during review:

• would it make sense to hide the 'desired retention' label in 'help me decide' mode, instead of showing '(plotted on the x axis)'?
• the interaction between new cards in the collection and 'additional new cards to simulate' can be a bit confusing in this context. I wonder whether a simple "average new cards/day" setting that doesn't depend on the current state of the collection might be clearer? Or some other feedback on how many new cards the simulator is considering when the graph is created?
• we might want to add something akin to deck-config-slow-suffix so that we don't require translators to retranslate the ... (experimental) lines when we decide to drop the experimental suffix.