Paul/nicer multiout

[paullinator]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Requirements

If you have made any visual changes to the GUI. Make sure you have:

• Tested on iOS device
• Tested on Android device
• Tested on small-screen device (iPod Touch)
• Tested on large-screen device (tablet)

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1210238308727629

[Jon-edge]

I'm approving because it serves the needs of our internal use case (topping off a number of cards), and it's a pretty hidden feature. For the general public, I have a number of considerations for us to think about.

For this the scope of this PR, I'd recommend at least resolving 4 and 5:

Observations

1. Consider the use case of someone wanting to capture grab a batch of addresses, and either doesn't know or wants to adjust amounts later. This linear ratcheting flow doesn't work.
2. The multi output feature itself is very hidden like an Easter egg. There's no indication that the feature even exists. The only way for it to show up is if the user to finish entering the amount, though it's pretty easy to miss considering the person is likely already thinking about completing the flow by that point. Even while reviewing this, it took me some time to discover.
3. There's no way to edit amounts for a prior recipient. Yes, you could remove them and re-scan them, but what if you lost the QR code or address? Don't know which one it was in a loose pile of cards that were already processed? Not having this capability presents a real logistical challenge potentially requiring the user to start all over on a mistake.
4. Would consider a bug - clearing out a previous "fully populated" recipient whose payment amount is set automatically brings up the scanner again.
5. I found myself mentally straining to draw the separation between completed fields and what I'm currently editing. I had to really carefully read lots of similar text. Everything is in one big block.

1-4 stem from the main issue of the "amount" entry being the trigger to permanently progress the flow. Somewhat convenient for the "loading many cards" use case, but is not intuitive or flexible for other potential use cases.

---

Suggestions

I'd prefer:

A button that exists by default below the last amount entry field, agnostic of how many recipients there are nor if amounts are populated. This would resolve the first 4 points above.

a. "Add Recipient" as a secondary or tertiary control visually makes the feature obvious that it exists, from the beginning of the flow, and without "insider knowledge" that the first amount needs to be populated in order to activate the feature.
b. Not having to commit to amounts beforehand naturally gives a way to edit them at any time, without resorting to losing the address

---

If everything above is deemed out of scope, there's low hanging fruit that can be done as a minor change to address point 5; appropriate no matter the scope of changes chosen:

There are (at least) two very distinct sets of information in the flow as implemented:
(i). If we table my previous suggestions, keeping what's in the current PR, the organization is:
[Populated]
[Not Populated, currently editing]

(ii). If going the route of my higher impact suggestions (a, b), the organization is:
[Editable recipient 1]
[Editable recipient 2]
[Editable recipient 3]
(Add Recipient Button)
Depending on the composition of the new cards and how compact they are, this can just be a sectioned card.

The UI should communicate this separation of concerns with separate card groups, and even better if they are labeled with headers describing what the groups are. Having a card header for groups would also allow repetitive text to be lifted out of the card contents, giving room to put other text/UI in there instead if desired.

---

"Auto-scan" in general (somewhat out of scope, but would be nice to address here):
The scanner automatically showing up at the beginning of the send flow has always been egregiously invasive, and assumes the user even has a need for the scanner in the first place. Even for someone who is familiar with the app, it takes me a split second to think of how to enter an address manually. I can only imagine what a new user would feel. Of course the scanner's UI could be improved but that's besides the point, the takeaway I'm highlighting is more importantly a UX flow issue.

Examples: Someone could be primarily pasting addresses from their mobile browser, or trying to rebalance between a number of browsers, yet our UX assumes all users are primarily scanning codes in the physical world.

Suggest considering letting the user choose how to proceed as the default entry to the flow (i.e. always showing enter/scan/paste first). Only if they previously scanned should we bring up the scanner again automatically on the next entry into the Send scene. Then they would have at least seen the rest of the UI once, clearly showing them the supported options, instead of immediately having it completely hidden by the scanner the first time they enter the flow.

For multi-output, of course, if they scanned one address we should continue to auto-scan on each additional recipient, which the current implementation handles well.

[Jon-edge]

Approved because it's fairly hidden, but strongly suggest making at least some changes as outlined.