Integrations of Load balance & Easy days

[L-M-Sherlock]

These two features require Anki to maintain a record of how many cards are due on each day.

As an initial idea, we may maintain this record in StateContext.

[dae]

Yep - my initial thought is we could store the counts per day there, and adjust the counts each time a card is answered.

One thing to think about is the long tail - large/old collections could potentially have thousands or tens of thousands of different due dates. What if we limited the features to a shorter time span, such as cards due in the next 3 months? For things like load balancing, it's probably not so useful to be balancing cards when they're so far out anyway, and as they become closer, younger cards would still be load balanced on those days. WDYT?

[L-M-Sherlock]

What if we limited the features to a shorter time span, such as cards due in the next 3 months?

It's totally acceptable. And we can also skip load balancing if the next due date is pretty far.

[Expertium]

An important question: when will Load Balancing be applied? After each review is probably too computationally expensive, although I may be underestimating Rust. So I'm guessing when the user clicks "Sync"?

[dae]

If we have a cached dictionary of daily due numbers, balancing can happen as cards are answered.

[brishtibheja]

Question: Will there be a way for us to use load balance not only for the collection but also for a particular deck? Someone bought this up before when there was no plan to add this feature in Anki. (For me, cards in some decks take longer time so want to prioritise their balancing)

[Expertium]

@dae @jakeprobst opinion on the slider?

I think having 7 sliders for every day of the week is an overkill (it's something that was considered a very long time ago, when this feature was being created), but one slider is enough. Btw, Jake, Easy Days also needs to support arbitrary future dates, so you'll have to add this thingy, too.

The math part is easy, just take the value of the slider and multiply the weight of the day by that value.
weight = card_count_weight * card_interval_weight * sibling_multiplier * easy_day_multiplier

So the value of the slider changes the probability of the card being scheduled on that day. 0% slider = 0% probability.

[brishtibheja]

I would rather not want another slider/button etc. so I'd say set it to 50%, take or leave. If people want more, they can use the add-on.

[Expertium]

There are people who want to make days as easy as possible, and there are also people who don't want to risk losing a streak. I think a slider makes sense.

[dae]

Easy Days also needs to support arbitrary future dates

If by this you mean "tell Anki to lighten the load on some arbitrary date in the future", that feels too niche to me, and complicates the implementation. There are other options for upcoming events, like using set due date to move the cards due on that day.

I think having 7 sliders for every day of the week is an overkill

We'll need to list out the days of the week anyway - is adding a slider next to each of them really complicating things much? It means the user can adjust the ratio in a single click, and they don't have to go into a separate setting to configure how easy the easy days are. It also lets them do things like have a mix of heavy, light, and (mostly) empty days as desired.

[Expertium]

1. This was requested for the add-on version of Easy Days back in the day, and I think it's worth implementing natively as well.
2. I'm REALLY surprised you don't think that 7 sliders is an overkill.

@L-M-Sherlock @user1823 @brishtibheja opinions are welcome

[brishtibheja]

The slider supports 10 values of the multiplier. I wonder how much that is necessary. This can be made a lot more intuitive by following a different UI.

mix of heavy, light, and (mostly) empty days

Instead of slider, how about three buttons for three modes?

[dae]

A slider with increments of 25% or 50% is effectively similar to a dropdown. I don't have a strong preference for one over the other, but think internally, we should be storing an an array of ratios, so we can provide more increments in the future if demand presents itself.

[Expertium]

The original slider goes in increments of 10%, and I think that's reasonable.
Honestly, I don't think that we need to change anything compared to the add-on. One slider? Good. Increments of 10%? Good. Support of any future dates? Good.

[brishtibheja]

@Expertium Your points:

1. It's bad idea. I think in such cases, it's better if you just Review ahead + Handle the backlog later. It's only a day.
2. I'm surprised too. I don't like 7 sliders as it's clutter. But I can imagine with three buttons, it's doable.

I believe if anything, we should start with lower number of possible values. If we start with higher, removing them later would be hard without impacting users.

[dae]

I don't like 7 sliders as it's clutter. But I can imagine with three buttons, it's doable.

I am not sure what you mean here. Do you mean three radio buttons next to each day of the week? That would be more cluttered than a slider next to each.

[Expertium]

I'm with Dae on this one. Let's add a slider in increments of 10%, or maybe 20%.
I meant to say that a slider is better than 3-4 buttons.

[brishtibheja]

That would be more cluttered than a slider next to each.

If you say so. My point was more about using words like (Hard/Easy/etc.) instead of numbers, than a specific UI. As for the the increments, I think 20/25% should be fine.

edit: where this will be added? preferences? deck options wouldn't make much sense.

[Expertium]

My point was more about using words like (Hard/Easy/etc.) instead of numbers

That is probably the absolute worst way to convey information you could've suggested. No offense, but I don't think I could come up with a less clear and more opaque way even if I was actively trying to sabotage Anki.

deck options wouldn't make much sense.

I was thinking of deck options.

I can already see that this will turn into another 100 comments issue.

[brishtibheja]

I don't think I could come up with a less clear and more opaque way even if I was actively trying to sabotage Anki.

lol. I didn't pull that out of nowhere. Maybe some game UI I saw unconsciously influenced me. Oh, I think some learning apps do this too, albeit in a different context. You put the amount of time you want to study everyday and they give it weird names.

My thinking was call this something like "Daily Study Amount" and select Low/Mid/Normal. It can make people think they can set everything to low without affecting other days, but that's true also with the sliders?

I was thinking of deck options.

No because you wouldn't want it to be attached to presets. Do we want this for setting easy days or setting days where you mostly study one topic, etc.?

I can already see that this will turn into another 100 comments issue.

LB was huge. This is a much smaller change in comparison. I wouldn't expect that much enthusiasm.

[Expertium]

Numbers: no room for "But I interpreted it in a different way!", no ambiguity, tells the user exactly how much the workload will be reduced.
Words: room for interpretation, ambiguous, doesn't tell the user exactly how much the workload will be reduced. Is High 100%? 90%? 80%? Is Low 0%? 10%? 20%?

I see no reason to use words.

[L-M-Sherlock]

I have no opinion to the UI. But seven percentages of easy days are complex to implement in math. In fact, the implementation of easy days with single percentage in the FSRS helper add-on is complex enough:

def p_obey_easy_days(num_of_easy_days, easy_days_review_ratio):
    """
    Calculate the probability of obeying easy days to ensure the review ratio.
    Parameters:
    - num_of_easy_days: the number of easy days
    - easy_days_review_ratio: the ratio of reviews on easy days
    Math:
    - A week has 7 days, n easy days, 7 - n non-easy days
    - Assume we have y reviews per non-easy day, the number of reviews per easy day is a * y
    - The total number of reviews in a week is y * (7 - n) + a * y * n
    - The probability of a review on an easy day is the number of reviews on easy days divided by the total number of reviews
    - (a * y * n) / (y * (7 - n) + a * y * n) = (a * n) / (a * n + 7 - n)
    - The probability of skipping a review on an easy day is 1 - (a * n) / (a * n + 7 - n) = (7 - n) / (a * n + 7 - n)
    """
    return (7 - num_of_easy_days) / (
        easy_days_review_ratio * num_of_easy_days + 7 - num_of_easy_days
    )

https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/782b44a1a3d131cb27a8366f6f089d19f1a1cbd0/utils.py#L194-L210

[dae]

As @Expertium pointed out the other day, I'm not a math guy, so I'll need to defer to others on this - I (perhaps naively) assumed that since load balancing is already using weights for balancing, it should be fairly simple to apply a multiplier to each of them based on the day of the week.

[Expertium]

That was my assumption as well. We take the value between 0% and 90% from the slider, and multiply the weight by that value.
weight = card_count_weight * card_interval_weight * sibling_multiplier * easy_day_multiplier
@jakeprobst am I wrong? I haven't looked at LMSherlock's code

[L-M-Sherlock]

It's not simple. For example, if the user set 30% to Monday and 100% to the rest weekdays, and we use the same multiplier on the weight, we will have 30% reviews on Monday and 100% + 70/7% reviews on the rest weekdays. So the real percentage is 30% / (100% + 70/7%) = 27.3% reviews.

Edit: maybe the PR doesn't has this problem. Because my helper add-on doesn't use weighted random.

[Expertium]

we will have 30% reviews on Monday and 100% + 70/7% reviews on the rest weekdays

That's intended, no? I don't see a problem here.
Btw, shouldn't it be 70/6, not 70/7?

[L-M-Sherlock]

OK. I will test it in the simulator later.

Edit:

I write a notebook to simulate Easy Days here: https://github.com/open-spaced-repetition/easy-days-simulator/blob/main/notebook.ipynb

I recommend opening a new issue to discuss it.

[brishtibheja]

1. As we're not enabling toggles, we don't need the word "Easy". The days of the week can be named normally, as the default option is "normal".
2. It can be way less cluttered if we have a column of buttons with "Normal", "Reduced", "Minimum" on top, in a table-like fashion.
3. I don't like dropdowns. They hide view from all the options, except the currently selected ones.

[Expertium]

@brishtibheja like this?

[brishtibheja]

That's what I was thinking. Normal should be on right side though.

[dae]

I agree with Jake - dropdowns are less cluttered, and this screen needs to work on narrow mobile displays as well.

[brishtibheja]

The buttons in stats display quite well in mobile.

Perhaps a opinion poll on this if we're looking for what looks less cluttered?

[Expertium]

So...survey time?
https://forms.gle/tc3eJrasW92RVZDv8

I just posted it on r/Anki

[Expertium]

David Ankidroid proposed this. What do you guys think?

[Expertium]

Btw @jakeprobst if I understand this correctly, if the user selects all days as Minimum, it will be the same as all days being Normal, right?

How about not allowing the user to select Minimum (and Reduced, too) for all days?

[brishtibheja]

I think the users need to understand that changing value for one day changes what happens with the other days. Pretty sure an average Anki user will think they can just vanish the reviews from some days.

[Expertium]

We can put that in the tooltip (that nobody ever reads)

[brishtibheja]

By the way, is it possible with some languages the proposal from @david-allison will look cluttered? I have seen similar UI before though.

[david-allison]

If Google can manage it, it's probably fine

[Expertium]

Most people prefer the buttons, admittedly, based on a small sample size.

So buttons it is, then. Hopefully, if we do it the David way, nobody will complain.

[brishtibheja]

I like the calendar like UI for it's aesthetics (and the help text) but the two options are related to each other but in this UI it seems like Reduced and Minimal are independent of each other.

I think we need show that only one state between these two are possible.

[Expertium]

@jakeprobst so here are my recommendations:

1. Most people voted for buttons, so implement buttons. But implement them the way David proposed (see above).
2. For days, don't just use M or T, that's confusing. Use Mon, Tue, Wed, etc.
3. Make it so that the entire row cannot be only Reduced or only Minimum.

[dae]

• The deck options need to display correctly even on small mobile displays - I'm not sure we're going to fit Mon/Tue/Wed etc on one line.
• The simplicity of the alarm clock example is somewhat lost when you have two separate rows, and extra logic to automatically deselect certain items depending on what else is selected.

Personally, I am not sure that Easy Days really needs such a bespoke UI, instead of reusing our existing dropdown components. The latter would be much faster to implement, and it leaves us with less of a maintenance burden. At the very least, if we're expecting @jakeprobst to work on this, I think we should focus on an MVP and leave the fancy UI for a future PR, if it's still felt that it's required.

[Expertium]

One more thing: I think a lot of users will complain if Easy Days doesn't apply immediately, so there should be a "Apply now" or "Apply immediately" button that would work similarly to "Reschedule cards on change": if enabled, changes are applied immediately (without doing FSRS-specific or SM-2-specific math) to free days up. If disabled, changing the settings won't retroactively affect already existing intervals.

[brishtibheja]

The deck options need to display correctly even on small mobile displays

Dae, it'll be in deck options? So will it be a global option or preset-specific? If its preset specific then I'll have to change settings in 20 different presets to get this working. If its global, preferences is a better place to have it. Deck options mean it can quickly get to the mobile clients but that screen already has too many options+adding more global settings there is confusing IMO.

[Expertium]

Preset-specific is better, since users may want to choose different easy days for different material. I was under the impression it will be preset-specific.

[brishtibheja]

That sounds like a very niche use case Helper add-on can support (it's already doing?). I don't want to change things 20 times just to get easy days working.

[Expertium]

@dae thoughts?

[dae]

• On an 'apply automatically': the current code is fairly integrated into the review process, so I don't think it will be trivial to reuse the existing code, and it's unlikely to happen for this release unless someone else rolls up their sleeves. Not sure a separate option would even be required - couldn't it just go off the reschedule on change setting?
• On config location for easy days: a preset is the logical place to put it, as users may want to have different rules for different decks.

[Expertium]

couldn't it just go off the reschedule on change setting?

But it has to work with SM-2 too.

[dae]

Does it? If we see FSRS as the future, I think it's fair to restrict new functionality to FSRS users when necessary.

[Expertium]

Easy Days doesn't rely on FSRS-specific math.

[dae]

But "reschedule on change" does rely on the FSRS setting, and this would let us keep things simpler. 🤷‍♂️