Weiwu can fill in details or prompt me if I can help to provide more details. But basically: I just want to remind us that we should bear in mind to keep the flow simple and not overcomplicate the UI, while still keeping the keys secure. Especially on small screens like mobile apps.
A few questions to ask might be:
How many users will understand this?
How many users will care about this?
How many users will be angry with us if we do it wrongly?
Does it surprise/delight the user (and not give a nasty surprise)?
I just want to remind us that we should bear in mind to keep the flow simple and not overcomplicate the UI,
Absolutely
We can run remote user tests on usertesting.com to check how people get it. One participant is around $39, we can set their location, income etc.
Absolutely we should test. I was taught good lessons back in the bank where tests reveals what I couldn't have predicted.
Speaking of project management, the backup/restore feature can't wait as it is already 3 weeks into the end of the sprint. Let's finalize the implementation of what is already designed and have tests done in the meanwhile, and have Green team to implement the needed changes from the learning of the tests.
If you are speaking of the "set-up fingerprint authentication" screen (which happens when the user change from a key not requiring user-presence to an encryption key that requires user-presence), I have the following info:
it's needed by Android since it can't be set up without user-interaction. So we can do all sorts of simplification except leaving that one out
but the same can't be said of iOS. @Tomek, @hboon just told me in today's weekly meeting that iOS doesn't technically require a set-up phrase for swapping the key to an encryption key that requires user-presence, so do we add the set-up screen anyway despite iOS doesn't need it, making it more complicated?
I subscribe to a view much influenced by my early days in GIZ/AHK (German) that "simple" means "consistent" and "clear", not "fewer steps". "Swapping key to an encryption key requiring user-presence" marks a point of no return: before that, the user will not lose the key unless he does it in settings or he deletes the app; after this point, if the user disables screenlock in the OS, the key is lost and the user will have to use backup.
@hboon is of the opinion that the point of no return was blurry at the outset - if a user would cry a river when he lost his key as he disables screenlock in the OS, then a user would cry a river too when he deleted the app and re-installed it (and finding 0Ξ), as his experience was deleting an app has nothing to do with deleting money or identity. My view: even crypto users who knows they can't delete their app without backup their money can't reasonably anticipate disabling screen lock would cause loss of money, therefore to hide the change is not a simplification but a complication, from the view that "simplicity is consistence and clarity".
I also think consistence between iOS and Android is highly desirable.
So this is what I have so far. I would be more than happy to get a feedback from you @hboon
This is Android based, I can provide you a custom design for iOS.
These steps are at the end of Back up process, right after you rewrite the seed.
Few more screens will be posted tomorrow morning.
Speaking of project management, the backup/restore feature can't wait as it is already 3 weeks into the end of the sprint. Let's finalize the implementation of what is already designed and have tests done
Yes, let's finish this up and ship it. Shippers ship.
I also think consistence between iOS and Android is highly desirable.
I agree (for this particular case).
Regarding the screen titled "Lock your seed phrase to increase security", do we consider the wallet to have been backed up (and hence no longer showing back up alerts) only after the user has tapped and completed "LOCK SEED PHRASE" successfully?
Should we have some copy to explain that removing the system PIN might cause their keys to be lost once the seed phrase is "locked"? [1]
Since we are here, should we have some copy to mention that the keys are not backed up to iCloud. [2]
[1] Related to that: I'm pretty confident that removing the iOS PIN and then re-adding it back will allow access to the keys, but I'm not confident enough especially because it isn't explicitly documented, so it might change. So let's assume it might be lost, just like Android, but be careful not to say that it will be lost.
[2] Not sure if it's possible without presenting a wall of text to the user.
We will display this alert at the top of Wallets tab. Something similar to "Time to back up". The one situation I would like to avoid is the one from BRD Wallet. I deactivated pincode and I had to say goodbye to my wallet. We should let users access their wallets, open them and maybe another backup.
The 3-segment bar indicator to introduce back up status looks nice, but since it looks like it doesn't affect how backup works internally and looks like it can be added as a separate, smaller sprint or a single issue, can we defer that?
But discussing/talking about it is still wonderful
(the same indicator might also be shown in the back up alerts to improve user familiarity or even guide the users towards securing the wallet seed/keys further)
