EW: Modernize the recovery key input modal

[mxandreas]

Problem

The modal to enter recovery key is used in the following context:

• Verifying the device (either at login or within the app).
• Resolving the key storage out sync issue.

As we are modernizing the designs, there is also an updated design for it.

Designs

• Entering recovery key.
• A wrong recovery key.

In an ideal case the new designs are fully implemented, the fallback minimum is:

• Make sure the copy of the current implementation is aligned with the new design.
• Remove the option to trigger reset (Reset all)

Left: current screens, right: expected screens after this item

When closing this issue, check back and close #29120 if appropriate.

[uhoreg]

The current dialog displays different text if the user has a passphrase they can use instead of a key. Do we want to keep this? (I'm guessing not)

The current dialog also displays a message if the user entered the recovery key correctly. Do we want to keep that?

[Croydon]

The current dialog displays different text if the user has a passphrase they can use instead of a key. Do we want to keep this? (I'm guessing not)

From a user perspective, I understand that one is generated and the other is user-defined, and without knowing anything about the implementation, I never understood why the UI would make a difference at entering dialogs.

A user can only have one of those at a time, right? Maybe even the way the passphrase / key are saved are identical and the validation steps are identical?

If possible, please unify it to something like

Please enter your recovery key (formerly known as security key) or passphrase.
[text input field]
or [select file]

Mentioning that the recovery key was formerly known as security key (which was even longer ago already once known as recovery key) also helps to not lock people out, as they are rightfully confused.

[mxandreas]

The current dialog displays different text if the user has a passphrase they can use instead of a key. Do we want to keep this? (I'm guessing not)

Does it somehow know in advance if the user had a passphrase or where/how do you see that different text? But I think we should try to follow the (copy of the) new designs to be consistent across the platforms. The new designs indicate that if the user had "security key" (old name of the recovery key) or "security phrase" ("key" entered by user), this will work, too. However, we should make sure that Recovery Key stays prominent (as in the new designs), as in the future we would like to stick to this term only and the reason is that users are already overwhelmed by having 1 more thing besides their account password.

[uhoreg]

The current dialog displays different text if the user has a passphrase they can use instead of a key. Do we want to keep this? (I'm guessing not)

Does it somehow know in advance if the user had a passphrase or where/how do you see that different text? But I think we should try to follow the (copy of the) new designs to be consistent across the platforms. The new designs indicate that if the user had "security key" (old name of the recovery key) or "security phrase" ("key" entered by user), this will work, too. However, we should make sure that Recovery Key stays prominent (as in the new designs), as in the future we would like to stick to this term only and the reason is that users are already overwhelmed by having 1 more thing besides their account password.

Yes, it knows if the user has a passphrase. This is what it currently displays in that case:

If you wanted to enter the key instead of the phrase, then you need to click the "use your Recovery key" link, which is not great. It's certainly better to have the user able to enter the key or the phrase into the same box.

[uhoreg]

The current dialog box checks the key as it's being typed to see if it is the correct key. Do we want to keep that, or only check when the user hits "Continue"?

[mxandreas]

Let's continue using new designs "as is" for both cases (recovery key or passphrase). This was what we intended and I think it also helps with clarifying / ensuring that it is the same thing (e.g. the purpose & use is the same) and the only difference is if it was generated or manually picked.

The current dialog box checks the key as it's being typed to see if it is the correct key. Do we want to keep that, or only check when the user hits "Continue"?

I personally like it but it is not critical because if the key is wrong you immediately see it and do not have to press Continue for "nothing". @americanrefugee please confirm if we would like to keep this pattern on the web UI or not.