Deck options: 'back' should only request confirmation if changes are made

[Arthur-Milchior]

Running on HEAD. If you open the deck option and change them then press back they are discarded. Please instead ask whether they should be cancelled or saved.

(Also, the save button is quite small. I doubt it satisfies accessibility requirement)

[dae]

The first point would require some work to implement, as currently the frontend doesn't have a flag that tracks when a change has been made. You'd need to store a copy of the initial data, then provide some JS method that compares the current state with the initial state to see if anything has changed. The Kotlin code would then need to invoke it and decide what to do based on its response.

[david-allison]

User comment:

Every time we tap Save button, the Deck options screen closes and we need to go back again and again to Deck options to continue our job. I think the Save button is not necessary or at least it shouldn’t close the screen.

https://forums.ankiweb.net/t/improvements-on-deck-options-screen-when-the-new-backend-enabled/39101

[briankrznarich]

I was actually coming here to consider filing a similar ticket. The title would have been something like:
"Inconsistent back-button behavior between AnkiDroid core settings and Deck settings" .

For the internal app settings (hamburger menu->settings), "back" will unconditionally save, which I think is how Ankidroid has always worked, even for deck-specific settings. Now, as you know, deck settings require the user to tap "save", or your changes will be silently discarded.

I screwed this up 4 or 5 times before I realized why my settings changes were not sticking. It doesn't take much work to adapt to, but every ankidroid user is going to screw this up 4 or 5 times before they figure out what's going on. A confirmation warning would alleviate this problem.

A long time ago I disliked this "back = unconditional save" mechanic, with no way to easily undo accidental changes. But all of iOS works this way, and most of Android I think. People are losing an intuition for an explicit "Save" button on phones, especially a tiny button at the top-right of the screen.

I agree with the earlier remarks on button-size and accessibility. The "save" button, and especially the drop-down menu to the right of the "save" button, are very very small. Besides being made physically taller, padding would probably help. There is literally 0 padding between the right side of the "Save" button and the edge of the screen. Whitespace on the right would make a safer tap-target for the drop-down menu.

[david-allison]

@briankrznarich Thank you for your time, I agree and I'll get this resolved

[david-allison]

Keep this open until we ask for confirmation on change, rather than unconditionally

[user1823]

Still looking for a solution...

[Arthur-Milchior]

I just opened this PR ankitects/anki#3410 , if DAE accepts it, once it's included in AnkiDroid, we can query the javascript to know whether there was any change.

[user1823]

The backend changes have been incorporated into the AnkiDroid main branch. So, an interested dev can work on this now.

[david-allison]

@Arthur-Milchior

Was this fixed in the following?

• DeckOption request the user to confirm whether to discard only if there are local changes #17315

[Arthur-Milchior]

Yes but it'll be broken with anki backend change because I removed the Bridge command that I introduced before knowing it was deprecated

[david-allison]

That's fine. We won't update the backend until they start on RCs

[user1823]

To clarify, Arthur didn't remove the implementation from upstream. He replaced it with another one. Here's the PR: ankitects/anki#3571

So, I guess AnkiDroid would have to modify some of its own code after the backend update.

[david-allison]

Things move fast! This is now actively in the pipeline:

• Update to 25.01beta1 Anki-Android-Backend#456