Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do collaborators ensure that users can study cards in a certain order? #107

Closed
sudomain opened this issue Nov 23, 2020 · 4 comments
Closed

Comments

@sudomain
Copy link

If someone was making a deck based on technical material, such as the Anki Manual, it'd be important that collaborators could arrange the cards so that users would study certain cards after other cards have been studied. For example, if cards based on section 2 of a manual build upon knowledge gained from cards based on section 1, we'd want the section 2 cards to come after.

This raises a few questions about CrowdAnki:

  1. as far as I can tell, CrowdAnki doesn't have a config option for export "deck sort method" that would sort by cardid or noteid. If a deck has been set to "show new cards in the order added", how do deck maintainers ensure (via. CrowdAnki) that cards will be studied in some kind of order to avoid section 2 cards coming before section 1 cards?
  2. I noticed in the example deck's JSON that cardid and noteid aren't tracked, rather "guid" is used. Is this internal to CrowdAnki or some part of Anki's database that I'm not aware of?
  3. When importing a new CrowdAnki deck (rather than updating), does CrowdAnki create notes in the order they appear in the JSON? i.e. will items that appear toward the top of the JSON be studied first (assuming we're using "show new cards in order added"
@aplaice
Copy link
Collaborator

aplaice commented Nov 23, 2020

Thanks for bringing up the topic — being able to specify the order in which learners see the cards is often, as you note, extremely important.


  1. as far as I can tell, CrowdAnki doesn't have a config option for export "deck sort method" that would sort by cardid or noteid. If a deck has been set to "show new cards in the order added", how do deck maintainers ensure (via. CrowdAnki) that cards will be studied in some kind of order to avoid section 2 cards coming before section 1 cards?

CrowdAnki has an option to sort the export by the first and second fields or by tag, so you can use that. You can go toTools > Add-ons > select crowdanki > Config and enter into the deck sort method, say tag or field1 or tag,field1. If you want to specify a completely rigid order, then you need to have an additional first field (say "sort order") that just consists of increasing integers (say 001, 002* etc.) and use the field1 sort order. If you just need to have section 2 cards coming after section 1 cards, but don't care about the order within the sections, you could just apply, say, section1, section2 etc. tags, and use CrowdAnki's tags sort order.

  • Currently the integers have to be padded with zeros so that they're all of the same length, because with the current sort method — the default python string sort method — "10" comes before "2", which probably isn't what you want. (Hence, you need to pad "2" with a zero, so that you get "02", which comes before "10".)

Unfortunately, sort by tag also isn't free of some potential pitfalls (at least currently) — if a note has several tags, then the "object" being sorted (the sorting key) will be the alphabetic list (concatenated to a string) of all the tags. For instance, if a given note has the tags red, green, blue, white then the sorting key will be "blue green red white", so the note will come before a note tagged "green, red" but after a note tagged "apricot". Hence, if you'll have many tags, some for sorting and some not, then to ensure that you'll definitely be sorting by the "sorting" tags, the names of the sorting tags have to come alphabetically before the non-sorting tags...

  1. I noticed in the example deck's JSON that cardid and noteid aren't tracked, rather "guid" is used. Is this internal to CrowdAnki or some part of Anki's database that I'm not aware of?

The note guid is a part of Anki's database (e.g. see Ankidroid's documentation, under CREATE TABLE notes).

  1. When importing a new CrowdAnki deck (rather than updating), does CrowdAnki create notes in the order they appear in the JSON? i.e. will items that appear toward the top of the JSON be studied first (assuming we're using "show new cards in order added"

Yes.

Hence, overall, if you:

  1. "Annotate" your notes with appropriate tags or an appropriate first "sort" field,

  2. (Like you wrote), use the "show new cards in order added" option,

  3. Sort by tag or "field1" (as required) in the CrowdAnki export,

you can control the order in which learners see notes.


I hope that this is helpful (despite some of the slight weirdness and potential pitfalls)! If you have any further questions, please feel free to ask.

@sudomain
Copy link
Author

Very informative and helpful, thank you. I think I prefer to export sort via field since the tag strategy could lead to unintended consequenced e.g. if a collaborater adds a marked tag without realising the effect on the export process.

More questions:

  1. Do the field1 and field2 sort options refer to the ordinal (position) of the fields? If so, why are only the first two available as the sort option? For this kind of metadata field I think I'd want it last on the list of fields for a model.
  2. How does crowdanki export when deck sort method is set to it's default of "none"?
  3. Will there be issues on crowdanki export/import (such as overwriting or loss of notes) if I have cards with sort fields of 001 through 009 and then find I need to make a new 008 card? The old 008 would be manually changed to 009 and the old 009 would become 010

@aplaice
Copy link
Collaborator

aplaice commented Nov 24, 2020

Very informative and helpful, thank you. I think I prefer to export sort via field since the tag strategy could lead to unintended consequenced e.g. if a collaborater adds a marked tag without realising the effect on the export process.

True.

If all your tags were namespaced under say anki_manual:: (anki_manual::section_1 etc.) you could avoid this particular problem (adding a marked wouldn't have much of an effect, since it'd be listed after all the other tags), but there will almost certainly be other similar issues.

More questions:

  1. Do the field1 and field2 sort options refer to the ordinal (position) of the fields?

Yes.

If so, why are only the first two available as the sort option? For this kind of metadata field I think I'd want it last on the list of fields for a model.

It's because these are the only two implemented. By default, in Anki, the first field is the "sort field"* for the purposes of the browser, so having the first available definitely makes sense.

However, you're right that sorting on the last field might indeed be useful. It'd be trivial to implement (we'd just need a NoteSortingMethods.FIELD_LAST: lambda i: i.anki_object.fields[-1] and some bookwork).

* Actually, it might be interesting to have a sort type that sorts explicitly by this sort field (as specified by sortf in the note model). It'd be slightly more tricky to get right, but it should be doable.

  1. How does crowdanki export when deck sort method is set to it's default of "none"?

It sorts by the order in which the nids are returned by this SQL query to the Anki database. The initial order in the database depends on the creation time, but I'm not quite sure under what circumstances it can change. I don't think that it's something that can be confidently relied upon, though.

  1. Will there be issues on crowdanki export/import (such as overwriting or loss of notes) if I have cards with sort fields of 001 through 009 and then find I need to make a new 008 card? The old 008 would be manually changed to 009 and the old 009 would become 010

There shouldn't be — the notes are identified/tracked by their guid, so unless that's changed (which is hard to do accidentally), there should be no issues.

It might, perhaps, be easier (if slightly "uglier") to "label" the new card as 008a or even 008.1 and the old one as 008b/008.2, to avoid a cascade of relabelling.

@sudomain
Copy link
Author

Thank you for taking the time to make that detailed reply. I have some things to consider now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants