[Enhancement] Add an information screen before changing some specific settings

[tadeubas]

Today users don't know what is changing in some specific settings. For example, see Appearance > Screen Saver Time, it does not inform the user that the value is in minutes and the value 0 will disable the screen saver feature. The user also does not know the allowed range beforehand.

My suggestion is to add a simple screen to inform the user what will be changed or how this configuration behaves, right before the screen that allows the configuration to be changed. This would only be necessary in some options in the settings. The screen should look like the one that appear in New Mnemonic > Via Camera.

[odudex]

To avoid extra steps and translations, how about adding a string property like unit in NumberSetting class, that is displayed during the setting capture?

[tadeubas]

It would avoid the extra steps, but the settings are not something the user would change that often, so I don't see a problem here if there are extra steps in other features, like the three options under New Mnemonic or Load Mnemonic > Via Camera > Tiny Seed or all options in Load Mnemonic > Via Manual Entry > Words / Word Numbers.

Of course this would also avoid extra translations too, but I don't think most users will read the docs to fully understand what these settings mean, and a simple text can help a lot! Check out this tutorial made by a Korean guy: https://florentine-porkpie-563.notion.site/Krux-Maix-Cube-71803293462a40a58825c08752fde385

In the tutorial he stated his confusion about these settings (This could be easily resolved with a simple text):

[odudex]

I agree we need to clarify units. But solve all theses questions and keep a standard would require to embed and translate all docs to device. Jeff once stated he didn't want Krux explaining concepts in the device screen, and I agreed that only explain procedures is the best.

[jdlcdl]

I agree with above re: "not on device screen". Precise meaningful names on screen, backed up by clear documentation available online and translated online seems best. It's easy to clarify instructions in online docs as soon as we realize an improvement can be made (or translators get around to doing it) whereas it's much harder to do a new release and get users to upgrade. If a term used on device screen is not as perfect as it can be, user's can still find most recent clarification in the online docs based on looking up that imperfect term...and we can even use those online docs to let them know that in the next release, the term will be clarified on device screen.

[tadeubas]

This does not aim to replace docs, I was just thinking about informing the user simple things like:

• Persist: Select the location to store device settings
• Debounce: Set the threshold in milliseconds (lower values allows faster movements)
• Screensaver time: Set the time in minutes (0 to disable)

But if this is too much information to display on the device, should we also remove the information from the other pages I mentioned?

[jdlcdl]

Just to chime-in with thoughts on this topic while reading comments in #373)

It's a simple "?" or "help" call to action button that is always available (much like "< Back"). It's not for in-device help, rather it's for an in-device qrcode that directs the user to the appropriate online documentation.

Implemented, it might mean that each "page" has a single unique keyword that helps build the qrcode's url. And as the online documentation changes/reorganizes, the "help-via-qrcode" library would re-build these links so that an up-to-date device never has help-via-qrcodes that point to broken links. It could be aware of the current locale that the device is using, so could redirect user to docs in their language. Maybe it would be tied to settings, so that a user who wants their docs locally might edit the domain so they don't cross the Inet for docs and instead get their docs starting at "http://mydesktop.mylan.home:8000/krux"

As a hazard, we might be teaching users the unsafe habit of scanning qrcodes from device to their phone... but this is already the case (ie: extended public keys, signed psbts and messages, etc) so perhaps there is a solution for the only dangerous time that a qrcode should NOT be scanned with an online device: Mnemonic Backups -- which might have some visual clue that this is a "secret" to be guarded (perhaps a red margin around the screen).