Page MenuHomePhabricator

[Cashtab] Revamp UX and remove antd from SignVerifyMsg
ClosedPublic

Authored by bytesofman on Apr 1 2024, 23:04.

Details

Reviewers
emack
Group Reviewers
Restricted Project
Commits
rABCb5b2281eedf1: [Cashtab] Revamp UX and remove antd from SignVerifyMsg
Summary

Depends on D15844

Improve the SignVerifyMsg ux using new custom components.

Test Plan

npm test

image.png (513×518 px, 45 KB)

image.png (754×521 px, 54 KB)

Diff Detail

Repository
rABC Bitcoin ABC
Branch
signverify-ux-fixes
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 28244
Build 56033: Build Diffcashtab-tests
Build 56032: arc lint + arc unit

Event Timeline

bytesofman published this revision for review.Apr 1 2024, 23:20
bytesofman added inline comments.
cashtab/src/components/SignVerifyMsg/SignVerifyMsg.js
63 ↗(On Diff #46707)

get all formdata inputs into one object

69 ↗(On Diff #46707)

manage errors in the same way

70–84 ↗(On Diff #46707)

now we get to lose all of these crazily-named state fields

116 ↗(On Diff #46707)

and we only need one function to handle input and validation for the whole component

118 ↗(On Diff #46707)

the 150 is a magic number. I assume it was implemented to keep processing times limited and prevent accidentaly enormous signing.

the bytecount is what really matters, but since this isn't really a spec limitation, I introduced a new constant limit of 200 to replace the magic number.

Cashtab isn't really optimized to support large msg signing, it's more mobile-first. So imo this is a good cutoff, we've never had complaints about 150.

tbh I don't think msg signing is used often at all. This will change when we make it the de facto way to sign into webapps with the extension. But the goal is to not have the user think about msg signing, just about how much more convenient it is than password mgmt.

emack requested changes to this revision.Apr 2 2024, 02:21
emack added a subscriber: emack.
emack added inline comments.
cashtab/src/components/SignVerifyMsg/SignVerifyMsg.js
180 ↗(On Diff #46707)

Having the switch in 'off' mode to signify verification is a bit weird and it contradicts the new styling used in SendToken.js. This type of look and feel needs to be consistent throughout the app. I would suggest just following SendToken.js and have two switches that hides and renders accordingly.

210 ↗(On Diff #46707)

Should output the wallet address as well, since it is part of the message+address+sig inputs used to verify. It would save the user from having to navigate away into the Receive component.

This revision now requires changes to proceed.Apr 2 2024, 02:21
bytesofman marked 2 inline comments as done.

Improve switch

cashtab/src/components/SignVerifyMsg/SignVerifyMsg.js
180 ↗(On Diff #46707)

Good point. In response to this review, I built it out with two switches. I tried two switches where only one can be enabled at a time, and also two switches where the user could see both fields at the same time.

Both cases ended up feeling a bit weird. If you can see both, then the verify switch is under the open sign form, and is not really obvious.

If you have two switches but can only see one, it's either weird to keep both switches at the top, or you have the same issue where the bottom switch (under forms) doesn't really stand out.

Since this screen will only ever have two modes, I customized the switch to be less "on/off" and more "sign/verify". Similar to the "equal" airdrop switch. I think it's the best of these options.

The switches for the SendToken page work and are modular, which is nice. But I still think it's a kind of temporary UX. Should be something like an accordion if we really want to allow only one thing at a time.

210 ↗(On Diff #46707)

I thought about this but decided against it.

  1. The usual use case for this screen is not checking a msg that you have signed yourself to see if it's valid. That is the usual dev case for us testing this component.
  2. The user can now copy his own address from the wallet header. Maybe this is not super intuitive -- but it is more intuitive than the old way this screen worked (user had to open the "sign" collapse, copy the own address there, then paste it in collapse).

If it were really important to make it easy to verify own address, I would add a button there, or pre-populate the for that way. imo tho users don't really need to check if a msg they have signed has a valid signature, they already know this (they aren't JS devs rightly distrustful of their own software). Verify msg is mostly useful if you are checking on some other msg and address. So, keeping the input blank is imo the best UX.

In either case, this component still isn't really about UX. Sign/Verify msg is a power user feature. The UX we are chasing is "one click secure app login with signing a msg". This will need to be worked out in the extension.

sign

image.png (450×529 px, 16 KB)

verify

image.png (583×529 px, 37 KB)

note user may toggle between modes without clearing any formdata, so the use case of "see if this works" is still possible.

we don't need a label now that this is part of the switch background

This revision is now accepted and ready to land.Apr 2 2024, 08:09