Why not? That change will barely affect the metrics, but if it makes users more satisfied and makes the difficulty more aligned with their intuition, that’s good.
I don’t even understand why users need something like that in statistics page if it’s confusing them.
From what I see parameters were used to explain a non-issue. That’s what I see all the time. Parameters are only used when somebody “thinks” something is wrong and then you explain to him that it’s not and params are used.
1 Like
This is most often the case. From time to time, the parameters help to find out that the user is using the buttons incorrectly.
I see that this confuses those users who are familiar with CM2 and how ease works. The longer FSRS exists, the fewer questions there will be about Difficulty. If FSRS does not spoil the innovations in any way, then I don’t care.
This will be solved when 2 button is implemented but dae doesn’t like it because he thinks there is a non zero probability that 4 buttons might have some benefits we haven’t been able to discover yet.
In any case, SM2 users can use buttons wrong too but you don’t need something in the deck options to tell you that. It’s a complete waste of space to have this thing there. As Expertium suggests, collapse it by default.
1 Like
Can also use it incorrectly with two buttons. May not know about parameter optimization.
Sure, examples abound! Having access to the parameters – even if just in a screenshot, or only a portion of them from a small-sized screen – provides answers to questions that users often ask, like –
- Why are my intervals so short?
- Why are my intervals so long?
- Why doesn’t D go down when I’m getting the answer right?
On top of that, seeing the parameters means that helpers can also deal with the “not asked, but is the real problem” issues, like –
- out-of-date default parameters
- parameters that were copied/modified from another source
- plugging the parameters into a visualizer (if you can get an accurate OCR of the screenshot) to quickly look for outliers
- questions that are not “about” FSRS, but are influenced by FSRS/parameters/desired retention
A lot of helping is reassuring folks that their experience is within the realm of possible and normal. Most users have a sample-size of 1 – just their own experience – or maybe 2 – their own experience and the experience that someone else complained about once (whether justified and relevant or not). The more exposure that frequent helpers (here or on Reddit or on Discord) get to parameter sets, the better the quality of help in the community.
2 Likes
I understand where you’re coming from, but I still think that collapsing that field by default is good because it reduces the “Why is everything so complicated in this app…” factor for new users. For tech support purposes, you can always ask the user to click on “FSRS parameters” when you think it’s necessary.
2 Likes
This will reduce the chances that someone will be able to help the user. The user may not understand which field to expand and how to do it. Or he’ll be too lazy to figure it out. Other users will be less willing to help, as it will become more difficult to do so now.
The implementation of this proposal will lead to a waste of people’s time.
1 Like
I’m not trying to re-open or re-hash the argument. I was just asked to offer concrete examples related to my earlier suggestion –
1 Like
These are all non-issues. FSRS obviously doesn’t provide you with much control over scheduling so these “concerns” will be solved if they try to understand FSRS or just switch to SM2. But to give you an anology, dark hair means there are more of certain types of melanin, right? But if someone were to ask you this, you would never need to know the density of this class of biomolecules in their hair to answer the question. To me, looking at the parameters to then say the obvious doesn’t sound like solving an actual “issue”.
These are issues that do not require too much worry. Default parameters are still better than SM2 and cases of people copying others’ parameters might just decrease if FSRS parameters field is hidden by default. But in both of these cases, if you think something might be wrong with the parameters you can just ask people to Optimise.
1 Like
Not to the users asking about them. Not to me.
If someone’s issue is that they don’t understand what is happening, helping them to understand what is happening and why is clearly a solution to their issue.
It seems like you asked me for specific examples so that you could remind me how little value you place on giving users actual or specific help. You made your point!
This is not a non-issue.
Understanding FSRS isn’t hampered by Expertium’s suggestions albeit a little because if you want to use parameters now you’ll have to give many more directions but I don’t think specific numbers are necessary to understand FSRS.
I’m struggling with your English. I think the guidelines you sent me over PM said be respectful or something similar to that effect. Is this considered a case of politeness in USA? In any case, I was not and am not discussing anything particularly with you. My points are meant for everyone.
I think the only issue for most of these cases where parameters are needed might be one of distrust. And simplifying the UI and eventually making it the default scheduler (SM2 skews perception) will solve the trust issues people are having. One more thing, people should be guided to see if they are reaching their “desired retention” or not because that is the true test of whether FSRS working fine for them.
1 Like
I can’t edit the post anymore, so I’ll add one more in the comment.
9.5. Add “Stability (descending)” and “Stability (ascending)” sort orders when FSRS is enabled.
What do people think of removing evaluate? I like evaluation but for very non-practical reasons. Now that the parameters do not update unless optimisation results in lower log loss I don’t believe there is a need for this (optimize can be used to tell which one of two set of params result in lower log loss; though not RMSE iirc).
1 Like
No, I don’t think that removing Evaluate is a good idea. It’s only useful for power users, yes, I agree, but still.
This is almost the same as the interval. Only without taking into account “Desired retention” and “Fuzz Factor”. It will be useful to some extent, but we already have a lot of sorting.
Right now, sorting by difficulty is almost useless. Will the new FSRS version fix this? If not, it would be possible to hide them when using FSRS.
It is worth raising this issue later. FSRS is developing and there may be errors in it. A large RMSE may be indicators that FSRS does not work well for certain users, and then they can share their collection with developers. A large RMSE can also show users that they are inconsistent in choosing the buttons to answer, or that their material is too different in complexity and it is worth using different presets.
I am not sure that RMS can help with all this since I did not understand this issue deeply, this is just my guess.
That can be known from retention rates which the users already get in statistics page (and more stats are coming too).
I don’t know under which circumstances a person would deem using all these fancy sort orders as functionally necessary (e.g. order added; latest added first; ascending/descending intervals; due date, then deck; deck, then due date).
2 Likes