Seriously, Just Hide Historical Retention

Problem: “Historical retention” is, unfortunately, a thing that exists. And users see it. And they think about it and tweak it. That’s bad.

Proposed solution: estimate it from the user’s history.

Problem with the proposed solution: Anki doesn’t store the date when the FSRS toggle was flipped for the first time, so there is no way to tell where the “pre-FSRS” history ends.

Simple fix: just store the date when FSRS was first enabled.

Pros: an accurate estimate (users can estimate their historical retention inaccurately); one less setting for the users to worry about; less confusion surrounding all sorts of things with “retention” in their name: desired retention, historical retention, true retention.

Cons: doesn’t work for people who are already using FSRS, only works for people who switched after the hypothetical update.

@L.M.Sherlock

Why is it bad though?

Also: When you press on the text so that the in app manual appears, it explains that this option is useful if “ignore reviews before date” had been used, or if stuff from another SRS had been used, or if review logs had been deleted.

  1. Are you suggesting to calculate an estimate from the review logs after the ignored reviews?
  2. Can this even be accurately done if only a few reviews would be left / not ignored?

Why is it bad though?

  1. Extra mental load for the user
  2. Confusing because there are other things with “retention” in their name
  3. The user may under- or overestimate their historical retention

Are you suggesting to calculate an estimate from the review logs after the ignored reviews?

I’m suggesting to calculate the estimate based on whatever history is available before the user turned FSRS on for the first time.

Can this even be accurately done if only a few reviews would be left / not ignored?

No, but in that case it can just be set to 90%, it’s not like the user will provide a better estimate in such a case anyway.

2 Likes

Some historical context for new forum members.

1 Like

IIRC, it has been discussed before. And dae rejected it. The main problem is the performance issue.

And the historical retention is also used in FSRS case if the user removed their revlogs after enabling FSRS.

The main problem is the performance issue.

How? It’s just storing one date + calculating retention once. It doesn’t have to be recalculated.

Fine. I don’t oppose this idea.

1 Like

@dae thoughts?

You’d be replacing some problems with other ones. With an auto-calculated figure, users will have no insight into what the calculated figures are, and won’t easily be able to adjust them when they e.g. merge decks from two profiles together.

The setting is already in the advanced section, which is exactly where such relatively-obscure settings belong - people who really care about it can still tweak the value to their desires, and the bulk of users can just ignore it.

1 Like

With an auto-calculated figure, users will have no insight into what the calculated figures are, and won’t easily be able to adjust them when they e.g. merge decks from two profiles together.

See, this is the problem. You’re favoring power users instead of new users. Anki is complex, and FSRS adds a lot of extra complexity as well, which makes Anki overwhelming for new users. You should be working on simplifying it. Speaking of which: Should Evaluate Button be Removed?

1 Like

Anki is not complex. Only you and some members of the Discord channel are thinking so.

Here’s what I’ve been able to piece together about the marginal user. Let’s call him Marl. The first thing you need to know about Marl is that he has the attention span of a goldfish on acid. Once Marl opens your app, you have about 1.3 seconds to catch his attention with a shiny image or triggering headline, otherwise he’ll swipe back to TikTok and never open your app again.

Marl’s tolerance for user interface complexity is zero . As far as you can tell he only has one working thumb, and the only thing that thumb can do is flick upwards in a repetitive, zombielike scrolling motion. As a product designer concerned about the wellbeing of your users, you might wonder - does Marl really want to be hate-reading Trump articles for 6 hours every night? Is Marl okay? You might think to add a setting where Marl can enter his preferences about the content he sees: less politics, more sports, simple stuff like that. But Marl will never click through any of your hamburger menus, never change any setting to a non-default. You might think Marl just doesn’t know about the settings. You might think to make things more convenient for Marl, perhaps add a little “see less like this” button below a piece of content. Oh boy, are you ever wrong. This absolutely infuriates Marl. On the margin, the handful of pixels occupied by your well-intentioned little button replaced pixels that contained a triggering headline or a cute image of a puppy. Insufficiently stimulated, Marl throws a fit and swipes over to TikTok, never to return to your app. Your feature decreases DAUs in the A/B test. In the launch committee meeting, you mumble something about “user agency” as your VP looks at you with pity and scorn. Your button doesn’t get deployed. You don’t get your promotion. Your wife leaves you. Probably for Marl.

– quoted from: The Tyranny of the Marginal User - by Ivan Vendrov

4 Likes

Lol :laughing:. To be clear, I don’t think we should hide every single algorithm-related setting like Duolingo. But there is definitely a healthy middle ground between Duolingo and the unwieldy behemoth that is current Anki.

1 Like