How to handle burying/sorting for image occlusion cards

[dae]

Re burying, how frequently do users mix and match the two modes?

I'm not sure how frequently users switch between the two IO modes, unfortunately, but what I can say with good certainty is that "Hide one, guess one" is the more popular mode. So what I would say makes up the main case for having note-type-specific sibling behavior in the context of IO is that users typically will have both IO notes and regular clozes contained within the same deck, and sibling spacing and burying will typically make sense for regular text-based clozes while for IO notes, assuming "Hide one, guess one", it won't (and given IOE's multiple-note implementation, no spacing and burying is the behavior users do expect at the moment).

@glutanimate is there anything you think should be addressed that shouldn't wait for a follow-up PR?

I think my main goal for this PR personally would be to come out of it with us mostly fully set on the note type. If we defer sibling burying/spacing behavior and a flag for IO note types to a follow-up PR (that I would however hope we could still merge ahead of rolling this out to testers), then I think we're mostly there.

Originally posted by @glutanimate in https://github.com/ankitects/anki/issues/2367#issuecomment-1446098285

[dae]

Restating the problem to ensure my understanding is correct:

• The user may wish to place normal cards and image occlusions in the same deck
• For the less common type of image occlusion, where everything is hidden and one item is revealed per card, users tend to want burying to be disabled, and cards to be shown in template order (not spaced apart), but may not want that for their normal cards.

Is that right @glutanimate?

You've suggested an option in the notetype to alter the burying behaviour. That's technically possible, but will add overhead to the queue building process, and make the code somewhat more complicated. The sorting behaviour is harder though: only one sort order can be in affect at once, and it's taken from the deck that's selected, so I think it's going to be somewhat impractical to alter this via something like the notetype.

Given that the second issue may be difficult to solve, is there still merit in trying to solve the first issue, despite the downsides, and despite the fact that the user will need to place cards in a separate deck to alter the sort order?

[khesed]

Looking through 15 popular collections/decks using Image Occlusion, I think your understanding is correct:

1. For the frequency of mixing and matching modes, I found that all 15 popular decks were using both modes.
2. "Hide one, guess one" mode is most commonly used in the same manner as the built-in Cloze notes. That is to say, the image occlusion notes generated from one image are being designed by users as though each note is a sibling card. For this mode, I think users would want to handle them the same way Cloze cards are handled with New card sort order: Card type.
3. "Hide all, guess one" mode is most commonly used where each note generated from one image is independent from the other notes. I did not find any special scheduling patterns which might be desired by a user from my review of currently existing decks. For this mode, I think users would want each thing generated to be handled as completely separate notes.

For 3, if no special handling is implemented in queue building, I don't think the functionality is missing. Users can create a filtered deck, with the search criteria of deck:Example is:buried "note:Image Occlusion (Occlude All Context)" and the select by of Random.

[glutanimate]

Hey @dae, sorry for taking so long to respond to this, meant to do so much earlier. Trying to catch up on mentions now after some more busy weeks.

Restating the problem to ensure my understanding is correct:

• The user may wish to place normal cards and image occlusions in the same deck
• For the less common type of image occlusion, where everything is hidden and one item is revealed per card, users tend to want burying to be disabled, and cards to be shown in template order (not spaced apart), but may not want that for their normal cards. Is that right @glutanimate?

Yes, that's correct aside from "hide all guess one" being less common. It's actually the other way around, with this mode being the most commonly used (and recommended by most IOE tutorials).

I would agree with @JeremiaWilliams on 2 and 3 being representative of how users are using IOE at the moment. For 1, that's an interesting insight. It doesn't fully reflect what I've observed, I feel like I've seen users stick to one mode for the most part, but either way – be it through mixing different IOE modes or IOE notes and e.g. regular clozes – real user decks will typically contain notes with different burying needs in the same deck.

Regarding altering the burying behavior without changing the sort order:

I think there is still merit in addressing the burying behavior in isolation as I think this is what will disrupt users' current IOE workflows the most, if they have sibling burying enabled. For instance, the 10 cards generated from an anatomy image that users would typically be able to review on the same day would now suddenly be scheduled to be recruited in piece-meal over a period of 10 days. This would likely force a lot of users to either disable burying entirely, use separate decks, or other workarounds that would affect Anki's usability in these scenarios.

Other note types which also create cards that do not interfere with or hint at each other would of course also benefit from note-type specific handling of burying.

At the same time, if I understand things correctly, sibling burying is now disabled by default for new users, so perhaps the scope of this issue among the greater Anki user base is smaller than we think. @dae do you have an idea how many users have sibling burying enabled in their deck options?

[glutanimate]

(with that said, even if the majority of users do not have burying enabled, I would argue that the impact on the workflow of those that do would be considerable enough to warrant the burying behavior changes)

[dae]

Sorry, I don't know the bury/no bury user ratio.

I can't seem to recall any AnkiMobile users complaining about the burying behaviour of I/O cards in the past. They're only a small subset of the total userbase, but given that supporting this would mean a considerable performance impact on queue building, I'd prefer to take a YAGNI approach for now and see what feedback eventuates when native I/O becomes available on all the clients.

[glutanimate]

Holding off and waiting sounds reasonable. However, I don't fully follow in regards to AnkiMobile users. Wouldn't this be expected given that IO users in general have been happy with the current behavior? (due to the large majority using "hide all guess one" and sibling burying naturally not being active because add-on IO cards aren't actually siblings)

[dae]

Sorry, that's a thinko on my part - I'd forgotten that your add-on generated separate notes.

[glutanimate]

No worries, IOE is also not fully consistent in the terminology in UI messages, docs, etc.

But yeah, this is why I think that the burying behavior could be a pretty significant point of confusion for existing IOE users, but likely also new users if they are coming to image occlusion after watching tutorials on it. It also seems like enabling burying (or keeping it enabled?) is a common recommendation in the most popular Anki guides for med school, e.g. 1, 2, or more recently 3.

[SiddharthManthan]

Do not make image occlusion cards siblings by default. I create multiple unrelated cards from same image and do not want them to be siblings. An option to not bury related cards only for image occlusion note type will be great.

Here is the relevant feature request on forum : https://forums.ankiweb.net/t/image-occlusion-do-not-bury-sibling-cards-only-for-image-occlusion/47085