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

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 3 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[user1823]

Still looking for a solution...

[Arthur-Milchior]

I just opened this PR https://github.com/ankitects/anki/pull/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.