Updating card types (question/answer format)

[Mark Carter]

Is there any problem with updating a card type to having a very different question/answer format? - e.g. switching what's on the front with what's on the back

I'm thinking regarding scheduling etc. If a user has been learning cards in one way, and then the card type is changed fundamentally, then would that mean the scheduling should be reset (since they don't yet know the note the other way)?

[Tim]

If a user has been learning cards in one way, and then the card type is changed fundamentally, then would that mean the scheduling should be reset (since they don't yet know the note the other way)?

So just don't change the card type fundamentally so that the scheduling doesn't need to be reset... Why would you want to change the card type fundamentally?

[Mark Carter]

So just don't change the card type fundamentally so that the scheduling doesn't need to be reset... Why would you want to change the card type fundamentally?

The user can select from a variety of card types and there are too many to have one actual card type per possibility.  So I want to be able to reuse card types, if you know what I mean? 

[Tim]

The API doesn't support editing models once they've been added, so that isn't possible. Editing models over the API is unlikely to be something that we ever support due to issues like this, and the fact that full syncs can often be triggered by model changes, which isn't something I want to support over the API. You can either add a new model for each configuration, or add all the templates and use conditional replacement as I previously recommended to you.

[Mark Carter]

A new model for each card type would have so much note duplication, so I don't want to do that.

I've been using the conditional fields for the past few weeks now. It works fine but adds too much complexity for the end user IMO. I'm expecting the vast majority of my users to be happy with one card type. Maybe once in a while they want to switch to another card type but I wouldn't expect this to be common or the norm. Now, a few users might want to have multiple card types at the same time and they can still do this, but when this is supported in the UI (of my app) it really adds a lot of complexity. Also the notes become more complex because of these extra conditional fields and they take a long time to bulk update. The templates are also a little less readable. The more card types I have the more of a problem this is.

Personally, I find card types confusing when more than one is enabled. I have a deck with 4 cards from two notes (two card types). But when I study, I'm only shown 2 cards. It seems to only show one card for each note. Is that expected behaviour?

So what I would like to do is have just one card type and allow that to be refreshed. I already have an option in my UI to "reset" the CSS and templates etc (directly accessing the provider) just in case the user screws theirs up somehow.  It's working fine.

Any more thoughts please?

[Tim]

Oooh that's right, I had forgotten that I added that functionality to the provider, sorry.

what I would like to do is have just one card type and allow that to be refreshed.

In some cases it makes sense to update the template: for example formatting changes, or say in Japanese the user might want to switch the furigana from hiragana to romaji or vice-versa. Such changes that don't fundamentally change the content of the cards are totally OK. Reversing an existing card template (for example) however would be a huge abuse of the Anki system, and I would consider any app doing this a rogue app. The correct way to do this would be to add a new template and delete the old one. The delete template operation would require a full-sync and the user should be heavily warned that the operation is going to remove all of those cards and their progress, so I imagine this is definitely not something that we would support over the provider or API.

Adding new templates though, is pretty OK. So I would recommend making a PR to support that in the provider and API. In your UI you can then start with one template and give the option of enabling extra templates (which will be added to the existing model). Removing templates should not be supported, instead you can point them to documentation explaining how to delete card templates. I wouldn't want to support an Intent here as the operation is dangerous enough that we don't want noob users accidentally deleting templates.

The only disadvantage of this approach compared with conditionals is that it doesn't give support for selectively enabling certain cards for certain notes. I find that this level of detail is necessary for language studies, so I prefer the conditional replacement approach personally.

[Mark Carter]

Yeah, adding (and removing) templates seems like the proper approach to this.  I think the other approaches are somewhat hacky even though conditional fields are super-powerful.

What is your reason for not allowing a client to delete a template.  As long as the client is warning the user of the consequences, then is there a problem?

For my users, when they see those conditional fields there would naturally be lots of questions. What are they? What values can I use? Can I remove them?

And then what happens if I want to later support a brand new template? There is no way to add a new conditional field (why not?)

I'm very eager to understand if the scenario (mentioned earlier) is expected behaviour: multiple card types, but when studying, only one card per note is shown??

[Tim]

What is your reason for not allowing a client to delete a template.  As long as the client is warning the user of the consequences, then is there a problem?

A) Deleting templates can force a full-sync. It's too complicated to support this over the API IMO.

B) I'm not confident that we can trust client apps to do a good job warning which cards will be deleted. This is especially a problem in the case where client apps are using a user specified model (as opposed to new app-specific model), or in cases where the users have added notes on an official Anki client using the same model that the 3rd party client app uses. In such cases, it might not be obvious to users that all the cards belonging to the model are going to be deleted.

C) Users could have removed the templates added by client apps and added their own. Letting client apps delete such templates might be undesired

I'm very eager to understand if the scenario (mentioned earlier) is expected behaviour: multiple card types, but when studying, only one card per note is shown??

http://ankisrs.net/docs/manual.html#siblings-and-burying 

[Mark Carter]

> A) Deleting templates can force a full-sync. It's too complicated to support this over the API IMO.

But deleting templates can also be done in the AnkiDroid app, so it's the same, no?

> B) I'm not confident that we can trust client apps to do a good job...

Yeah, this goes back to the permissions discussion (like with models). If a client creates a model then it should, by default, be trusted more with that model than one it has not created. Same with card templates. Telling a user to go to the AnkiDroid app to delete a template that was created in the client app, is not a great user experience. I envisage a lot of my users will control all their notes and cards from within my app. My app will also support users who make additional changes in Anki/AnkiDroid, so it would check before deleting a card template whether it has been changed etc

> C) ...

same as above

Since there is no support for adding templates right now, I'm left to choose between overwriting a single template and using conditional fields. Hmm, dilemma!

[Tim]

I'd definitely be willing to accept a PR for adding new templates. Deleting would need to be a separate discussion.

To be honest though, this is kind of going out of the scope of the API. The intention from the start has been to support adding notes with a nice default model. Customizations to the default model are intended to be done in an official anki client by motivated users that are willing to read the documentation when necessary.

[Mark Carter]

Yeah, understood. Modifying things like CSS is extremely powerful though. For example, for coloring hanzi by tones, the client can automatically update the CSS when the user changes the coloring settings.  Similarly modifications to the templates. Changing the template conceptually is another matter though, granted.

OTOH, you've also said the provider should support Anki clients (like AnkiWear) so there is that too :)

Out of interest, is it possible to bulk-modify the conditional fields in Anki/AnkiDroid?  For example, if I want to set a conditional field for all notes with a certain tag?

Finally, adding support for adding templates should mean there should also be support for adding fields (e.g. a corresponding conditional field) right?

[Tim]

Modifying things like CSS is extremely powerful though.

The problem is that many users will make their own modifications to the CSS, and client apps should not overwrite those changes. They may even completely re-write it and that makes it very difficult for a client app to make meaningful changes to it.

Out of interest, is it possible to bulk-modify the conditional fields in Anki/AnkiDroid?  For example, if I want to set a conditional field for all notes with a certain tag?

Not in AnkiDroid, maybe with Anki desktop search and replace. Definitely with a plugin.

 Finally, adding support for adding templates should mean there should also be support for adding fields (e.g. a corresponding conditional field) right?

Again, this would need to be a separate conversation. Templates are relatively self-contained whereas users can potentially manually add/remove/reorder fields so the relative order could get messed up by allowing clients apps to add new fields after the model has been created.

[Mark Carter]

I've just created a new PR: https://github.com/ankidroid/Anki-Android/pull/4215

> and client apps should not overwrite those changes

yeah, but if the client app checks first that nothing has changed since it last updated the CSS/template then there's no problem.  Also, sometimes the user WANTS to overwrite their changes.

> users can potentially manually add/remove/reorder fields

the position of a field is not changed by adding a new field

I guess you're worried about users adding/reordering/deleting fields and then the client app overwriting the wrong fields. My app already handles that :) But anyway, that's the same problem whether the client is able to add fields or not, right?

[Tim]

My app already handles that

Assuming fields will not be renamed I presume? 

[Mark Carter]

Well of course. Actually, initially I attempted to account for a certain amount of renaming. For example, if one field name has changed but all others are the same, we could presume that the field has been renamed but should continue to be written to. Now, I think that is too risky, so I simply map between fields based on names. If a name no longer exists, I simply don't write it's value.  If important fields don't exist, I tell the user and then they can act accordingly to make updates proceed.

[Mark Carter]

You might consider updating the provider so that the client has to specify the field names corresponding to the fields (for inserts and updates). And then the provider would take care of this mapping.

[Mark Carter]

In fact, query() could also specify an array of field names (conceptually, much like it specifies column names) so that only those fields are returned (and in that order) when a model's notes are queried.

[Mark Carter]

The problem is that many users will make their own modifications to the CSS

Regarding this specifically - I can do a find-replace to change colors of a certain class. For example:

`.tone1 {color: #aabbcc;} -> .tone1 {color: #ddeeff;}`

This is pretty safe I think, especially if the user is first asked if they want to update the AnkiDroid CSS colors.