Feat/grade now #3840
Feat/grade now #3840
Conversation
|
Could this be implemented as a submenu on "Grade Now" instead of opening another dialog? Similar to how ajt's card management addon currently does it. I understand that the dialog mirrors the reviewer's button bar, but feel it might be too clunky in practice |
|
I think "Set Due Date" should be removed then Also, shouldn't it be "Rate now", since the manual usually says "ratings" and not "grades"? |
No, both have their own use cases.
SuperMemo also has both the options: https://supermemopedia.com/wiki/Ctrl%2BJ_vs._Ctrl%2BShift%2BR |
|
I thought the whole point of adding "Grade Now" was to remove "Set Due Date" since FSRS can't properly work with it? |
|
Would it be feasible to make it accessible through APIs like AnkiConnect so third party tools like Yomitan could be used to mark a word as "Forgotten" ? For example, if I'm reading a book, I hover a word I forgot, if I see it's already in Anki and has reviews, I could mark it as "Again" meaning I forgot it, and thus my external review would be counted by the scheduler as a review |
Yeah, that's the purpose of adding the Grade now feature. However, I can't say whether connecting this to third party tools would be easily possible or not. |
All that’s needed from Anki side is to expose the |
|
upd: It’s worth noting that For instance,
Demonstration: Demo.mp4 |
|
The advantage of leveraging the Graphical Actions API is that developers of end-apps (e.g., |
@Expertium I think people should be allowed to grade the cards when they're using SDD. Or, allow setting a due date when using GN. That was also the initial idea with this feature if I remember correctly, i.e. reschedules will stop having a manual I'll leave the matter to Jarrett however. |
|
To solve the set due date problem, we may require the user to grade before set due date. |
I feel like we need to merge both GN and SDD into one feature. |
A normal review just before a SDD would also help? And how will people be let known that needs to be done? I feel changes to SDD needs to be made (maybe in a different PR). |
|
@dae seems like nobody agrees on anything. Let me summarize:
|
|
I don't think it'd be confusing per se. Just that the issues with SDD will still be there for some users. There's a good way to solve those by having users use GN along with SDD, but if they're seperated like this users won't know they've got to do this. |
|
[I question whether a PR for one feature is a useful place to discuss removing/altering another feature, but I'll respond here, since the discussion is already underway.] There's nothing confusing about having Set Due Date and Grade Now as 2 separate features -- they do completely different things. It's great if Grade Now can address some SDD use-cases, specific to New cards, that were challenges for FSRS, but it certainly doesn't cover all of the uses. For instance, Grade Now doesn't allow a user to set a card to be due on a particular date/range. My primary use case for SDD is when I've made major changes to a note, even adding New siblings that will be introduced soon, and I don't want to wait months to study the existing Review siblings again. For that, Grade Now would be useless to me. I don't want to skip studying those cards and grade them today -- I want to actually study them, just sooner. SDD is also a reasonable technique for addressing a missed-day/vacation backlog: scatter those overdue cards across the next X days. There are better techniques -- but it's a fast and simple alternative for folks who don't want to deal with Filtered decks, and it's better by far than the "postpone your whole collection X days"-type add-ons. |
There was a problem hiding this comment.
Thanks Jarrett, I've left some comments about the technical side of things below.
I too find myself wondering how exactly we should integrate SDD and GC into Anki. Would some sort of unified interface where the user could specify grade and/or due date make sense? Are there situations where it would make sense for FSRS users to use SDD without grading the card?
Currently, I use SDD in only one situation and in that situation, grading the card would be harmful. I use SDD when I am in the reviewer and encounter a card that I don't want to answer for the next few days (depending on its stability). Basically, I use SDD as a "prolonged bury" feature. Why I don't want to answer it? What would happen if I rate it |
- Add `from_queue` field to `CardAnswer` struct and proto message - Modify `answer_card_inner` to handle queue updates based on `from_queue` - Remove `grade_card` method and consolidate card answering logic - Update related test cases to set `from_queue` flag
- Refactor `grade_now` to collect processed card IDs first - Add new `update_queues_for_processed_cards` method for efficient batch queue updates - Improve queue management by removing entries and updating counts in a single pass - Remove individual queue update method in favor of batch processing
There was a problem hiding this comment.
Getting there! A couple more technical concerns below.
On the GUI end, I agree with @iamllama that a dropdown may be a better choice - the current pop-up feels a bit clunky, and can't be navigated easy with a keyboard. But that can be deferred to a follow-up PR by someone with more of a GUI focus.
Or not. I still also find myself wondering whether it might make sense to present these two features with a unified interface, allowing one to grade & optionally set due date or vice versa, but I don't have any great ideas for how it could be done at the moment.
rslib/src/scheduler/queue/mod.rs
Outdated
| // We don't need to save undo information here since | ||
| // this is a batch operation | ||
| // and grade now can be undone as a normal op | ||
| } |
There was a problem hiding this comment.
Looking at this more carefully, I find myself wondering if you've actually accidentally taken the second approach I mentioned? maybe_clear_study_queues_after_op() does not cover the grade now case, so the next queue operation after this one causes the queues to be rebuilt. If I'm right about that, all this code could be dropped.
There was a problem hiding this comment.
I didn't know maybe_clear_study_queues_after_op() before you mentioned it :-). I will check whether the code is useless.
There was a problem hiding this comment.
OK, I guess this info means I can remove the function update_queues_for_processed_cards safely?
[rslib/src/scheduler/queue/mod.rs:213:9] &op = OpChanges {
op: GradeNow,
changes: StateChanges {
card: true,
note: false,
deck: true,
tag: false,
notetype: false,
config: false,
deck_config: false,
mtime: true,
},
}
[rslib/src/scheduler/queue/mod.rs:214:9] &op.requires_study_queue_rebuild() = true
This PR adds a new "Grade Now" feature to the browser, allowing users to grade cards directly without going through the review process. This is useful for quickly adjusting card states in bulk.
Changes
Implementation Details
The implementation includes:
GradeNowoperation in the backendScreenshots
close #3694