Currently the editor sticky setting behaves persistent: E.g. if you open the AddCards dialog, toggle a field from non-sticky to sticky, close the dialog, and reopen it, this field will be sticky.
I think a good change would be to make meta settings like sticky, which don’t affect the field HTML, non-persistent.
Motivation:
Ever since we implemented the new HTML editor, a common request is to have fields default to it instead of the WYSIWYG editor. If this setting was persistent however, users who are not familiar with HTML might accidentally activate it, and not know how to leave it again. Having default instead of persistent settings would prevent this, as reopening the dialog would still reset it.
I would like to implement Collapsible fields within Anki, as I think it would be helpful, especially on mobile, where space can be quite limited. The same argument for the HTML editor also goes here. It would be nice to have a default setting, but a persistent thing might confuse users who are new to the feature.
Challenges:
However the settings should still be persistent across one session. For example in the browser, selecting new cards or using the arrows, should not reset the field options each time a new card is displayed. Same goes for AddCards and the sticky settings.
For this the editor would have to be aware of note types. When it wants to display a note of a note type it hasn’t displayed before, it could fetch the DefaultEditorOptions once, and initialize its EditorOptions with this information. Across one session, it would accumulate all those EditorOptions it needs, and discard them when the session (the window) is closed. The same is true for the AddCards dialog, when you add multiple cards of the same note type, or the EditCurrent dialog, if you edit notes of the same note type without having closed the EditCurrent previously (especially if the live-updating PR is merged)
Alternatives:
Have mixed default and persistent options. We could implement a setting for the field to default to the HTML editor, e.g., but I think it would be confusing to have some settings persist and some reset on reopening the editor.
I think this is a tough call because there are multiple use cases for frozen/sticky fields, and with some of them, cross-session persistence makes sense while for others less so.
For instance, when I set the question field on a basic note as sticky to carry over the question stem to the next note, then that’s a setting that would make sense to revert when exiting the session.
OTOH there are fields like “Sources” that – at least in my use case – basically stay sticky permanently. This is because rarely will I change their content more frequently than every 10 or so notes. The same goes for other supporting fields that put notes into a greater overarching context.
Ah, I see, I misread your post. So your suggestion would be to have a default initial setting applied at the beginning of a session. Any changes within the session would persist just within that session. Restarting Anki would once again set the initial default.
If so, that sounds good to me. Adjusting the setting via the field dialog also makes sense to me. We’d just have to make sure to communicate the difference properly.
Users used to the current behavior might also end up slightly confused as they might not be familiar with the fields dialog setting, having used Frozen Fields and now the sticky button to set their “defaults” (even if they’re not actual defaults). E.g. if a user marks the “Extra” field to be sticky, based on what they’ve seen in previous tutorials they will currently expect that setting to still be set the next time they start Anki.
Right, but since a lot of users probably never visited that dialog (you don’t really have to if you don’t create your own note types) and used Frozen Fields to control the setting, there might be a slight adjustment period where people could get confused.
Not a blocker by any means of course, especially if we think that the altered behavior will provide a better user experience in the long term, just something to keep in mind.
So each screen is maintaining its own state, and if the user goes into the Fields dialog and changes a default, it will not affect the existing screens? If so, that sounds like a good way of tackling this without making the code too complicated.
As I wrote on Note editor: collapsing fields more - #4 by ArthurMilchior , I’d really love to have settings registered on note type and be persistent between each use of the note type. And when I change note typ, I want to have the loaded note type persiestent state and not the previous state of the previous note type
You mention mobile. May I ask what mobiles you are referring too. Do you use the same UI for ankimobile?
I never thought about it, but since it’s web, if it works in a webview, I guess it would make sens to try to use it in ankidroid, instead of creating our own wysiwig
Yes, some Anki components are already used on both AnkiMobile and AnkiDesktop, e.g. the Card Info, or the Deck Options.
It would indeed be great, if components were shared between all platforms. Indeed, it might be easier for AnkiDroid to use the Anki components, because assumably Androids and Qts webviews are way more similiar than the iOS WebKit ones.