Wallet recovery process - design iteration 2

Screens created with Figma. They are available at:

https://www.figma.com/file/I0L3WcvRKLTPLU6MNmKUhp/Taler-Wallet-Anastasis
-integration?node-id=557%3A4713

Clickable prototype available at:

https://www.figma.com/proto/I0L3WcvRKLTPLU6MNmKUhp/Taler-Wallet-
Anastasis-integration?node-id=557%3A6476&scaling=min-zoom&page-
id=557%3A4713&starting-point-node-id=557%3A6476

Changes made:

* Added an option to type the recovery credentials. This means users
will be able to paste the recovery credentials as well, unless we want to
specifically disable pasting in the credentials input field.

* Added reference to “Anastasis” as part of the warden service option. I
have not added “Anastasis” in the button label, since it would become too
long. But Anastasis is mentioned in the explanatory text now displayed on
the screen.

* I have removed the 'cancel' button from this process. Do we really want
to invite people to cancel the process, even after paying? What does 'cancel'
mean in this context? How does it relate to stopping / resuming the process?
These are things still to be worked out.

* Added additional hints to the identity verification challenges to disambiguate
them (mobile phone hint, email address hint, etc). I am still not exposing
policies here though. We really need to simplify this process as much as
possible. Ideally, users should be shown a list of challenges, and be told
how many of them they need to complete. Working out which policies the solved
challenges apply to, and when sufficient challenges have been solved to
proceed, should be done by the application. Not exposing policies here may
impact the design for the Anastasis backup process.

* Disabled the “Resend code” button, since when a new code can be requested
is governed by certain rules (https://docs.anastasis.lu/rest.html#get--truth-$UUID).
As far as I understand them, those rules prevent you from requesting a new code
until a certain period of time has passed.

* Change the design to reflect the fact that payment should happen when
solving each challenge. I still find this problematic: we’ll see what
happens when we put the design in front of users.

* Added error message about warden service temporarily unavailable.

* Added some text to explain that recovering a wallet does not delete any of
the information in one’s current wallet. Data and funds from the recovered
wallet are merged with the existing one.

* Added dialog to handle the case where the recovered wallet still exists on
another device. We need to think carefully about what happens if users want
to keep the recovered wallet in the old device, since at the point where we
present the dialog they may have already paid for recovery. This, however,
seems to me a bit of an edge case. Why would anybody start the recovery
process from a device where they don’t want the wallet to be?

Still to be done:

* Suspending and resuming the recovery process.

* Wallet does not have enough funds to pay for recovery.

* Designing detailed interaction for each identity verification option
(SMS, email, security question, post, bank transfer).

Signed-off-by: Belen <belenbarrospena@gmail.com>

1 files changed, 0 insertions, 0 deletions

diff --git a/anastasis_integration_wallet/recovery/backup_recovery_iteration2.webm b/anastasis_integration_wallet/recovery/backup_recovery_iteration2.webm
new file mode 100644
index 0000000..2363409
--- /dev/null
+++ b/anastasis_integration_wallet/recovery/backup_recovery_iteration2.webm