ankitects
Feat/Disable parameter editing until right clicked 3 times
I was asked to disable parameter edits entirely or make it a config bool, but I think this is a nicer compromise.
c.c. @Expertium @Danika-Dakika
Essentially, this is similar to the way android does it regarding developer settings. I think it's good as it...
- makes it obvious that changing the params is discouraged and
- still allows to edit the params if the user really wants to.
It might be a bit difficult to discover, though. On click it only shows a message informing the user that it's discouraged, but there is no indication that clicking 3 times still allows one to edit the params anyways.
On click it only shows a message informing the user that it's discouraged
It shows the warning message after the box is right clicked 3 times and the parameters are made editable.
Essentially, this is similar to the way android does it regarding developer settings.
It's similar, but not exactly the same. On Android, you click 5 times on the version number to get permanent access to the developer settings.
This change, however, requires you to click 3 times (and closing the alert window) every time you open the Options for deck menu.
As a user who needs to tweak the weights after every optimization, I think this change adds nothing but noise and is troublesome for those who have to edit them "regularly". There is no benefit for ordinary users either. It is again nothing more than a change for the sake of change, because Expertium thinks that it should be done this way.
(Imagine if you had to click 5 times every time you wanted to access the developer settings on Android. It's the same here)
This change, however, requires you to click 3 times (and closing the alert window) every time you open the Options for deck menu.
Yep, Its why I kept the right click count low.
As a user who needs to tweak the weights after every optimization
Why do you need to tweak the weights?
Why do you need to tweak the weights?
(This question is out of scope of this discussion)
Answer: Because FSRS produces inadequate/inappropriate graduate interval for me (>20 days).
Answer: Because FSRS produces inadequate/inappropriate graduate interval for me (>20 days).
You should not be modifying the graduating interval. The other parameters will be generated while assuming that the initial stability parameters are not manually edited.
You should not be modifying the graduating interval. The other parameters will be generated while assuming that the initial stability parameters are not manually edited.
FSRS doesn't have single weight that responsible for graduating interval. I modify several weights and I think that I understand what I am doing (and my review statistics prove it).
FSRS doesn't have single weight that responsible for graduating interval.
The first 4 parameters are what are responsible for the initial stability and therefore the initial interval (Aside from the short term parameters?). The other parameters are what effect the following intervals. You are right that this is almost off topic now but I would heavily advise you to stop manually changing your parameters.
The first 4 parameters are what are responsible for the initial stability and therefore the initial interval.
Okay, I expressed myself incorrectly. I'll put it differently: I am okay with long distance intervals, but because of high initial stability weight value I have very long intervals for a first few reviews (including graduating interval). It can not be fixed by making DR higher, because it messes with long distance intervals.
@Luc-Mcgrady how about increasing the number of clicks to 5, but making the "unlocking" permanent, so that after the first 5 clicks the user will no longer have to repeat it in the future? And make the counter global, so that if the user has "unlocked" editing in one preset, it unlocks all other presets too.
Btw, for Dae: the purpose of this change is to prevent people from using parameters of someone else, like YouTubers or ChatGPT. Like this: https://www.reddit.com/r/medicalschoolanki/comments/1nbyh7j/comment/nd7c0n2
Change is costly. It takes time to discuss, to verify correctness, to fix unintended consequences, to educate users on the change, etc. I think we do a bit too much of it at the moment.
the purpose of this change is to prevent people from using parameters of someone else, like YouTubers or ChatGPT
How much of a problem is this currently? Do we have evidence ChatGPT is actually doing this? I tried asking it for some FSRS params, and it explicitly cautioned against editing them manually.
I'm more sympathetic to the YouTuber argument, if there's a demonstrated pattern of this actually occurring.
Regarding the proposed approach:
- Most users on mobile devices will not be able to right click
- 3-4 left clicks/taps is barely more work than one, so a config variable seems unnecessary for gaining access
- But a pop-up each time is a bit cumbersome for the users who insist on manual editing. Maybe a compromise there that will avoid a config var (and the chance the user will forget the warning) is to display it as a
<Warning>under the input area instead?
Like this?
If it would appear only when a user has clicked/tapped on the parameter field, sure, why not. Though Luc's approach seems more fool-proof to me.
That's what I had in mind, but perhaps with a more forceful message like "Manually editing parameters will almost always make FSRS worse. If someone suggested you change them, they are giving bad advice."?
But I'm still waiting for the evidence that we actually need this :-)
I had assumed the point of this PR was to prevent people manually tweaking their parameters like Yuki did. Anecdotally, some people do think that the box being editable implies that the parameters are something to be manually edited: https://forums.ankiweb.net/t/review-intervals-too-short-for-high-difficulty/66187/4?u=a_blokee (Although maybe I gave bad help in this case :P)
Maybe a compromise there that will avoid a config var (and the chance the user will forget the warning) is to display it as a <Warning> under the input area instead?
I'm happy with this as it solves the mobile issue. Should I go ahead?
- Asking ChatGPT to generate parameters: https://www.reddit.com/r/medicalschoolanki/comments/1nbyh7j/comment/nd7c0n2
- Looking for old default parameters: https://www.reddit.com/r/Anki/comments/1itsks2/does_anyone_know_the_default_parameters_of_fsrs/
- Questioning new default parameters (here the problem is less about editing and more about parameters being visible at all causing worries, the user even went as far as to downgrade because he was convinced that Anki got the wrong default FSRS parameters): https://www.reddit.com/r/Anki/comments/191uian/anki_update_changing_the_fsrs_parameters/
- Manually editing parameters: https://www.reddit.com/r/Anki/comments/1eut3eb/fsrs_sending_out_new_cards_34_days/
- Manually editing parameters: https://www.reddit.com/r/Anki/comments/18a367v/fsrs_extremely_long_intervals_for_low_card_repeats/
- Asking how to manually edit parameters: https://www.reddit.com/r/Anki/comments/1ikvkar/how_to_manually_adjust_fsrs/
- Asking ChatGPT to generate parameters: https://www.reddit.com/r/medicalschoolanki/comments/1jyyu4t/waking_up_with_800_reviews_a_day/
- Asking how to manually edit parameters: https://www.reddit.com/r/Anki/comments/1awhn60/fsrs_new_card_timing_question/
- Asking about manually editing parameters: https://www.reddit.com/r/Anki/comments/1my3naa/comment/na9txa0
- Asking how to manually edit parameters: https://www.reddit.com/r/medicalschoolanki/comments/1kppr8j/comment/msztxc9/
It's hard to find specific examples like these, considering that this isn't something I keep track of (unlike, say, cases where true retention doesn't match desired, or interval length complaints, for which I record post IDs).
Anecdotally, some people do think that the box being editable implies that the parameters are something to be manually edited: https://forums.ankiweb.net/t/review-intervals-too-short-for-high-difficulty/66187/4?u=a_blokee
Yeah, I guess the fact that parameters are exposed so prominently and are editable makes some users think "Oh, Anki wants me to do something with these" or "Oh, I have to mess with these to get the most out of FSRS".
I don't think Dae will find this argument convincing, but I'll quote a Discord user:
I just don’t think it’s feasible to argue that the 3 users who actually understand and change their own parameters are more important than the 99% who COULD completely mess up their scheduling or get put off
That is a more than sufficient list - thank you for taking the time to make it.
I think you're both right that having it editable implies to the user that it can/should be edited. We could have it shown as disabled by default, with the triple or quadruple tap enabling editing, perhaps?
I just don’t think it’s feasible to argue that the 3 users who actually understand and change their own parameters are more important than the 99% who COULD completely mess up their scheduling or get put off
I don't think anyone feels that way, including me. What I take issue with is when you break power user workflows in the name of making things simpler. I'm fond of the proposed solution here because it should solve the problem for the common user, without taking away functionality some users were using.
We could do a combo: 5 clicks/taps to "unlock" editing parameters + a warning. 5 clicks/taps would be required only once for any preset, so after that the user will be able to edit parameters in any preset at any time but will see a warning. Or just one of these two solutions. I'm fine with either solution or a combo or some third way, as long as it does a good job as a guardrail.
What I take issue with is when you break power user workflows in the name of making things simpler.
Unrelated to the current PR, but this is something that I think colored button borders do better than a two-button mode. Both address Hard misuse, but colored button borders don't break people's workflows and don't make old guides/videos confusing ("where did the buttons go?? why does my anki only have two buttons???").
I'd rather we keep things simple and avoid the need to persist the setting. I don't think it's a big ask to the few users using this to tap a few times more than they previously did. The taps are not punitive, we just want enough that they're not accidentally triggered frequently.
The more I think about it, the more I think a combined approach (clicking + warning) is best. Not having a warning may make users think that having to click multiple times is a bug and we'll see "Bug report: editing FSRS parameters requires multiple clicks". Also, making it persistent so that users have to triple/quadruple/quintuple click only once would reduce annoyance and still work nicely combined with the warning.
I am in favour of both the taps + warning (as I'd have thought my mention of a more forceful warning above would imply!). But it's a no to making it persistent for now. We can always add it later if it proves necessary.
Reviewing the current state of the PR:
- Still think an inline Warning would be less bothersome for the niche users
- Unfortunately, the taps are not working so well at the moment. Because we've used readonly instead of disabled, there's a focus highlight around the text box when you click on it, which implies to the user that the text can be selected. If they then attempt a couple of times to click and/or drag in the text box, they can pretty easily activate the threshold by accident, as we're not requiring the taps to come in quick succession. We could perhaps either change the styling so it still looks disabled so users don't try and drag, or display the params as plain text instead of a text box, only revealing it when trigger (hopefully with a threshold for how quickly the taps must occur in).
- A disabled appearance makes it difficult to determine if the placeholder values are being shown or if actual values are being shown. Maybe we should just be showing something like "FSRS defaults" in that case? 🤔
I presume our primary motivation for even showing them by default is to make support easier. @Danika-Dakika, how frequently do you find that is useful? I'm wondering whether it might be time to consider tucking them away by default, as presenting a bunch of uneditable numbers to users that they can't do anything with is not so helpful.
My opinion is not as valuable as I am just a simple Anki user, but I though:
There is already an "Advanced" section at the end, with an "Arrow dropdown" for Custom Scheduling. In terms of UI, naming it Advanced already convey the idea that this stuff is not necessary to mess with, and the consequences of doing could be undesirable. I have seen software before that even had a "Here be dragons!" tongue-in-cheek message in the equivalent section.
When I started using Anki again after a long gap, seeing the "FSRS" section with the FSRS parameters and the various buttons immediately drove me to think that "that FSRS stuff is obviously advanced, for the power users", and I left it disabled. I did some quick googling to see if SM-2 would still work for me, and decided it's worth staying with SM-2 if that means I don't have to learn how to tweak FSRS. My logic was: "I don't need the latest and most powerful at the cost of having to learn more and having understand better what I'm doing". (I have since done some research and activated FSRS).
Again, I'm just a user, and not a very advanced at that, but I think the slider for activating FSRS and perhaps the "Desired retention" could stay there, as it's part of the basic functionality, and everything else could be tucked away in Advanced. For the advanced user, it would simply mean having to scroll down for a fraction of a second longer, and for the normal user, it would mean that you know what's needed. To reinforce this, perhaps the parameters could be hidden in another "arrow drop down".
My opinion is not as valuable as I am just a simple Anki user.
You are the target audience so thanks for the feedback :)
Helpers often want to know what the parameters are and keeping them in the FSRS section allows them to more commonly appear in help screenshots.
I've implemented all of Dae's above listed changes.
I'm not sure what the default text should contain.
Also, is a11y an issue here? should the edits be trigger-able with just a keyboard?
Also, is a11y an issue here? should the edits be trigger-able with just a keyboard?
It should be. From an A11Y point of view, people should be able to access everything that a "normal" user can. Currently, using a lot of Tabs, we can edit the FSRS params easily. So if your PR breaks that, I guess that counts as a regression.
I do see two challenges though:
- Is there a key that is commonly used to unlock such things? Enter perhaps?
- Wouldn't we need some sort of visual indication, like a highlighted border on focus as well in that case? How else would someone know they could interact with it (well, I guess there is a tab stop. Is that enough of an indication)?
@dae
I presume our primary motivation for even showing them by default is to make support easier. Danika_Dakika, how frequently do you find that is useful?
Every day, many times a day. They are the quickest way to tell whether "my intervals are too long" is a real problem, or just getting-used-to-FSRS stuff. To be fair, I can really only decipher a few of them on sight, but I can plug them into the visualizer to gauge differences. And the # of parameters is a nice giveaway for what version of FSRS they are using.
As long as they can still be copy-pasted as text, I'll be perfectly happy.
As far as eventually hiding the parameters entirely -- Expertium asked me about that in the Discord server a few weeks ago. Compiled from my hot-take on that:
Until FSRS is perfect (even for imperfect users [^1]), and stable (i.e. you stop changing the algorithm every release), it's too soon to obscure more of it. It's a deliberately high bar. Until FSRS works without support, it needs to be easy to support. That's why it was too soon to remove "Evaluate"/obscure it behind a "Health Check" with no interpretation instructions. It's similarly too soon to hide the parameters. [^1]: I'll clarify that I would define "imperfect users" distinctly from -- users who do illogical/mind-boggling things, users who ignore visible warnings, users who make mistakes in their setup, etc.
Just today, I've been trying to help someone with FSRS whose first 4 parameters are:
2.5038, 41.6273, 41.4231, 41.6273, ...If you want FSRS to be a black box (and for every help request to be solvable with a flow chart), it's got to need no intervention. We're not there yet.
Wouldn't we need some sort of visual indication, like a highlighted border on focus as well in that case? How else would someone know they could interact with it (well, I guess there is a tab stop. Is that enough of an indication)?
Highlighted border and slightly different font color seem good
Sorry it's taken so long to circle back to this. Gave the latest code a try:
- Triple clicking on the numbers, at least on a Mac, appears to select the text instead of enabling editing. Triple-clicking on the empty area after the numbers does appear to work. Not necessarily a problem, as long as we document it. Edit: actually, depending on the generated numbers, they can take up almost all the available space, meaning you have to hunt around for the little bit of non-occupied space in the bottom right, which might be problematic.
- I like the warning when unlocked
- The placeholder text shown when the params are the default and the user doesn't have enough reviews is a bit confusing: it tells them to use the optimize button, but that message remains after it's clicked. Possible ideas we could solve this: change the wording so it makes sense, change it after optimization does nothing, or just hide the params section until the params are non-default. Thoughts?
Triple clicking on the numbers, at least on a Mac, appears to select the text instead of enabling editing. Triple-clicking on the empty area after the numbers does appear to work. Not necessarily a problem, as long as we document it. Edit: actually, depending on the generated numbers, they can take up almost all the available space, meaning you have to hunt around for the little bit of non-occupied space in the bottom right, which might be problematic.
Should be fixed in https://github.com/ankitects/anki/pull/4372/commits/44a10811a3d1d2412c124c1e7738b24a4d15d839