No, the first question is whether the toggle should be set to On or Off by default.
EDIT: I deleted all responses. Again. That’s because I added a third question. If in the first question the user chose “No”, it’s important to ask why.
1 Like
Alright, so idk who this is, since the survey is anonymous, but I want to address this.
If any devs followed this philosophy, the users would only get funcitonality that existed on day 1 (when the app was released) by default, and ANY functionality that didn’t exist on day 1 would have to be enabled separately. That sounds like a bad idea. If you want a test period - sure, that’s perfectly fine. We can make Load Balance disabled by default, and then make it enabled in a future release after a few months. But when taken literally, this says “Any new functionality that didn’t exist on day 1 should never become default”, which is…not smart.
EDIT: adding a warning for every major change doesn’t seem like a great idea either. Showing a changelog, like AnkiDroid? Ok. But a warning? That would probably just make the user dread opening the app after 3-4 times.
EDIT 2: regarding this
Load Balance respects the fuzz range, it won’t change intervals by a greater amount than fuzz would. It will just change intervals in a smarter way than fuzz. Yes, this means that retention will vary more (just as with fuzz) than with no changes to scheduling, but it’s not that much of a concern. At the very least, not any more than with fuzz.
1 Like
The first one is me – but I don’t think I said anything about all-devs, all-apps, all-features. 
I was answering a question about this feature in this app.
For existing users, you shouldn’t change their current behavior without warning. But you don’t have any way to tell whether a user is existing or new (even a fresh install can be an existing user). A major new feature like this should be introduced as disabled (even if you think it’s amazing and everybody will love it and there are no downsides).
I get to hear from people daily who are confounded by how Anki has changed – regardless of how much warning they’ve gotten, or how small a change it is (or whether there has actually even been a change …). My message urged temperance and gradual introduction, so as not to disrupt folks’ study routines.
I’m not sure how that could be objectionable. It’s not as though there is some point where it will be “too late” to force this feature on users.
To be clear, I think Load Balance is great, and I’m looking forward to it being native functionality. But I don’t think that my enthusiasm for it will necessarily be universal.
Well, as I said, a test period when Load Balance is off by default (and then on by default in some distant future release) is perfectly fine, I just don’t think that showing a warning when the default behavior changes is a good idea. Neither in general, nor in this case. Btw, I like AnkiDroid’s approach of showing the changelog.
1 Like
I also think we should remove the load balancing option (maybe in the future), because it’s clear that some people don’t understand that it’s not affecting anything. Also if you think of it, it’s just Fuzz 2.0, as you initially wrote. If we allowed people to turn off Fuzz there will be some people turning it off because someone recommended that fuzz affects retention or something. For similar reasons, there is no reason why anyone would want to make daily load inconsistent by going back to legacy Fuzz.
1 Like
That wasn’t on the list. If you’d made that one of the options … you might have gotten different responses.
Not even a warning? Not even when changing default behavior? So that’s you on one side, and everyone who helps people figure out what has gone wrong in their app on the other side. At least if there’s some warning, there’s something to point to and say “did you read that or just click through?”
Test period is fine but I thought you are against too many options. It’s confusing if you introduce an optional feature and then remove it in the future. I see no need to allow users to disable this so a toggle button would just add to the complexity of the app. Better make this the default way “fuzzing” happens.
Also, there will be no immediate confusion among people because balancing is happening as you review something. So the changes will only slowly appear. Even after some time I don’t expect most people to notice that something has changed.
But having said that, I’m 100% sure Dae will want there to be a toggle button for Load Balance. So there probably will be one.
Always add a field to the survey form for an unplanned comment for the interviewer. That’s why I’m writing here. 
I think the controversial issue arises precisely because some siblings are testing one aspect and some are testing different aspects. Based on this, some siblings should be balanced and others should not.
So the solution is to add the appropriate functionality to the card type so that the user can specify which card types are related (That is, they test the same aspect of knowledge.) and no balancing should be done for them.
And vice versa.
Why am I talking about the functionality at the card type level? Because brothers and sisters are formed precisely at this level, at this essence, at this moment, and not at the level of a note, deck or anything else.
Naturally, the connection must be many to many. The example of language learning shows this very well when one and the same aspect is studied by different card types.
Moreover. A single note may have several such pieces of knowledge. Therefore, it may be necessary to add an entity such as “piece of knowledge” to which the user will assign these card types.
Based on the paradigm of minimizing information on a card, I believe that only one knowledge area can be assigned to a card type.
This should’ve been there. Expertium can you add it? Might be useful for some people if they want to give anonymous opinion.
That will just make everything more complicated. You would want to set whole note types as “siblings shouldn’t be balanced”, if anything. Now I understand that some decks might contain both type of note types, some where you want “avoid siblings” and some where you don’t want “avoid siblings” but I fear that will just make the feature very unintuitive.
The entry threshold for ANKI is, in principle, quite high. Therefore, I am not sure that understanding the idea of combining card types by field of knowledge will require more understanding than the difference between a note and a card type.
Which of course does not mean that the system needs to be complicated.
But in this case, we divide sibling cards by a feature that is not explicitly specified in the system, which leads to a blurred understanding by different users, and as a result, different approaches to the organization. Including their decks.
So it would be great to add a best practices section to the help, so that new users can already understand at an early stage how best to slice their decks for different situations: language learning, formacology, sciences, etc. In a way it would encourage standardization or at least give a direction of thought.
If you make the functionality focused for some users, then the second ones will not understand and will complain that everything is bad.
If we’re talking about “intuitiveness”, I suggest leaving the approach as with the deck overide. Those who need it will figure it out and use it, and those who don’t need it, haven’t figured it out or for some other reason will use the “standard functionality”.
It remains only to decide whether to use the default balancing or not. But with the current implementation, some part of the users will be dissatisfied. Moreover, this discontent will be wandering, depending on how many balanced brothers and sisters (Who need or did not need to be balanced) you’re are looking today.
I genuinely don’t understand what you’re talking about here. How does this feature you’re talking about work? From which screen would you configure this and how? How is it helpful for your situation?
The “avoid siblings” toggle option one that you set for a preset? What I understood previously is that you want to toggle this for note types instead of presets. But I don’t understand the solution you offer (something like assigning relationships between fields?).
I read it again. This, as far as I understand, does not work for cloze cards and IO cards. But in any case, I can not imagine a situation where you would want two sibling cards of the same note to be dispersed, but you wouldn’t want it for other sibling cards of the same note. For such cases, people can always create simpler note types.
I think such complexity scares off a lot of new users. So better to be simpler. Especially if it is not adding a lot of value.
If you are asking me about the implementation, then I see the following scenario.
- In the Card Type form, add a drop-down list where the user will select the knowledge area for which the card type is used.
- After the drop-down list there is an Options menu where the user can add a new area of knowledge, rename, reposition, delete. (Similar to the Options menu for the Сard type.)
- In the pieces of knowledge form, we add a checkbox about the applicability of load balancing.
- Further, in the balancing algorithm, we take into account that the cards belong to a single field of knowledge, and depending on the sign of applicability, we either perform balancing or not.
I don’t think it’s any more complicated than administering the card types themselves.
Yes, there is also a nuance that when using a deck overrite, cards from the same area of knowledge can end up in different decks.
For example, I have a “Verbs” deck, but in the note of a particular verb I have two card types with using a deck overrite of entries with direct and reverse translation sentences .
That is, on the “main” card I learn the translation of the word itself, and on the examples I practice to highlight and reproduce these verbs already in the text. Using German as an example, this is not easy.
Total, I can independently study cards of verbs themselves, cards with direct translation of sentences with verbs, and cards with back-translation of such sentences.
But nevertheless, even though the cards are in different decks, they are nevertheless siblings. So the balancing algorithm should take this into account and not work only within one deck.
Maybe I have poor decks organization. If best practices were given in Help - maybe I would have organized differently.
If you know how to make organizing decks easier, please let me know.
As a result, I have the following deck structure. For everything else (e.g. lessons) I use tags and then, if necessary, I can create filtered decks.
It seems like there is no consensus. Alright, let’s ask the big boss. @dae do you think that there should be a toggle for Load Balance, or should it always be enabled, like fuzz right now? Additionally, what’s your opinion on the sibling stuff (check my survey)?
1 Like
For example, I will tell you my case.
Let’s take a note of some German verb “aufstehen” = “get up”. That is, we already have two types of cards: direct and reverse transfer. BUT.
According to the rules of German, this verb has a detachable prefix, which in sentences is separated from the root and goes to the end of the sentence.
“ich stehe vom Stuhl auf.” = “I get up from my chair.” Accordingly, these are two more types of maps for examples with direct and reverse translation of sentences.
To give the verb a past form “ist aufgestanden”, first, add the verb sein (to be) or haben (to do), and secondly, change the word itself (there also seem to be 4 options). (and this is already 2 pieces of information per card.) Here is another type of card - “a verb before aufstehen”.
Plus more example sentences in two past tenses where this verb changes in different ways.
And let’s not forget about writing at least the main form of the verb.
I have already listed 7 or 8 card types for one note, and this is not the limit.
Are all types of cards siblings? To be honest, I don’t know. On the one hand, they all describe a single verb, but from different sides. But, on the other hand, these are different sides, on the basis of which it might have been better to make different notes. I do not know what is the best practice in this case.
That is, when a card with a sentence in the past form appears, will it be a reminder of the main form of the verb? I think yes. So it’s a related card. But in terms of verb tenses, they are unrelated.
Do I want to separate the sibling cards of direct and reverse translation? I think yes.
Do I want to separate the sibling cards of direct translation and writing? I think not.
it seems to me that when learning complex languages (Chinese, French, German, Russian, and the like), where there are many word forms that do not lend themselves to any rule (that is, they need to be memorized), a similar problem occurs everywhere.
That’s a crazy grammar rule. Some people like me, simply ignore most grammar. For Sanskrit, I put gender in my cards as additional info but I never test myself on these. But if you want to, and this is what most people do, you create a different note for grammatical info. This is easily solvable without doing all of the field of knowledge thing.
If it were so easy to describe everything with rules, then there would be no problems. Unfortunately, you often just have to memorize, because this is the another fabulous exception.
I do not know how much it is possible to ignore the rules when communicating in Sanskrit, but when talking in German, where the prefix can completely change the meaning of the word, it seems unlikely to me.
Please don’t say that word. I think we don’t say it here. The rule is you ask yourself whether you’d like your message on the front page of NY times.
I acquire grammar through comprehensible input. By consuming books, comics, and podcasts. But as I said, you can always create a different note type if you really really want load balancing for those cards.
I will quote dae on this actually
I’m a bit concerned about the number of options we have already - it can overwhelm new users, and some users unfortunately feel like they are missing out if they don’t tweak everything in sight.
Pretty sure even if I agree with this complicated feature, dae would not. You have other ways of going about what you want to do. No need to set relations between sibling card types and make the load balancer read into those.
By the way, that quote is from back when Anki had much less features so…
Now I’m curious how fuzz was handled. I don’t know when it was introduced, I assume not on day 1. Was there a warning? Was it a “this is the default now, no toggle, deal with it” situation?
I am in favor of a dumb “if a card has a sibling on the easiest day then put siblings on the next-easiest day” (and if all days have siblings, just load balance as normal). This is how the old load balancer addon worked. Currently if someone wants to avoid siblings on the same day they check the “bury review siblings” option. That will still be needed in most cases anyway, this will just make them more evenly spread.
Its dumb, its easy to implement/reason about, and its still a significant improvement over what is already in place.
Creating entirely new categories of what is a dispersable and non-dispersable sibling seems like a ton of overhead, intoduces quite a bit of complexity, and has an abyssmal UX for…probably not much gain.
I’m also in favor of a checkbox for the feature, with it being default if we are avoiding adding more options.
Of course, I’m just waiting for dae to show up and say what he actually wants. I did just show up and do all this on my own with no consultation with anyone after all.
Re: fuzz introduction
Its old, real old. A very old version of Anki had it, but during a rewrite 10+ years ago there was a period of time when it didn’t have it (which is also why the original load balancer addon came to be! I was writing a fuzzer addon and got carried away). it eventually got re-added since it was a feature it used to have but no longer did with minimal fanfare. I don’t recall it being toggleable but it might have been initially?
2 Likes