Idea: Shortcut buttons to reduce number of taps

[tficharmers]

To reduce the number of taps to bring up the 'send from camera' (3 taps) and the 'rapid receive from QR code' (2 taps), place some shortcut buttons on the wallet preview page to facilitate this in 1 tap. If someone is at a point of payment, 3 taps to bring up the camera is a bit too much work. Likewise if they were just wanting to flash a QR code at someone to scan to pay them, 1 tap is better than 2.

I also think it would probably make more sense, that if the user jumps to the camera or QR code using these shortcuts, I think the 'Cancel' or 'Back' buttons should take the user back to the previous screen from where they came from. I noticed currently that the new 'rapid receive from QR code' back button, takes you back to the Receive landing page, even though this isn't where you initially came from. I can see why this is happening (there is a brief flash of this page as you transition), but I think it would be expected that a back/cancel button would take you back to the page that the button was pressed on. Consider the user tapping a shortcut and then saying "oh, actually I don't want to pay with that wallet". They would need to return back to the wallet overview screen in order to select the correct wallet.

If this was implemented, I would revert the new 'rapid receive from QR code' to its previous action. This would then go back to having the same type of functionality as its corresponding 'Send from' button. I would also switch these buttons around so they match the order in the bottom navigation panel. Just seems like a logical thing.

The 'Quick Send' and 'Quick Receive' terminology are just place holders ('Quick Sand' hehe). This would need some more thought if implemented. I have only spent a few minutes thinking about it, but it did make me consider the current terminology of the buttons. I wonder if the 'Send From' and 'Receive At' buttons should just be 'Send' and 'Receive' (just less noise). However, this then made me think, should 'Send' actually be 'Pay'? ;-)

[tficharmers]

By the way, in the second screen, I have switched the buttons around to illustrate what it would look like. This might not have been clear from the in-image text.

[paulshapiro]

Totally open suggestions; just sharing some impressions:

However, this then made me think, should 'Send' actually be 'Pay'? ;-)

Considered this but one might also say though that 'Receive At' would be closer to being 'Pay' as, in the button context, it's "pay this wallet"

I wonder if the 'Send From' and 'Receive At' buttons should just be 'Send' and 'Receive' (just less noise)

Probably fine, yeah. User can probably get enough hints from the relative difference between the icons... though there is still some ambiguity. Guess the user will just have to try the functions to know what they do.

I would also switch these buttons around so they match the order in the bottom navigation panel. Just seems like a logical thing.

Hm maybe I'm biased but I placed Send From on the right side and Receive At on the left side to keep a left-to-right flow of funds association in the context of the wallet itself. The ordering in the tabs would be different as it indicates (in my existing concept of it at least) more of a feature priority within the whole app (Send > Requests > Contacts > Preferences)

If this was implemented, I would revert the new 'rapid receive from QR code' to its previous action.

Just want to confirm, do you mean the 'Receive At' btn on the Wallet Details page should no longer immediately show the QR code for the wallet but should do what it did in 1.0.0 where it creates a new request? (Reason would be, if I understand, that the 'Quick Receive' on the Wallet List Cell would show the QR code immediately (as we do in 1.1.0 - except displaying the modal in the Wallets tab instead so Cancel takes them back to the click location)

Interesting…

By the way, if that's correct, do you think we should still keep the new Request list items for quick-displaying the QR code for wallets? (The ones which are auto-managed)

I think the 'Cancel' or 'Back' buttons should take the user back to the previous screen from where they came from

Very sensible, to me

'send from camera' (3 taps)

Just want to confirm, the 3 taps here would be Wallet List Cell -> Send From (selects the wallet in the dropdown) -> Use Camera?

Very neat idea to combine them. Exactly the sort of thing I was hoping to add. Maybe what can happen is the 'Scan QR code' camera view can pop up from the place they tap the 'Quick Pay/Send' button (so, within the Wallets tab), then if they don't cancel but get a QR, the app can then switch to the Send tab, select the wallet, and populate the rest of the form. (That way a cancel drops them back in the same place)

Thanks for the awesome brainstorm & feedback!! 🔥

[tficharmers]

Thanks for the thorough response. It's great to see that you have a justification for everything. It's my design philosophy too.

The thought process for this collection of ideas started from 'it takes 3 taps to bring up the camera view to scan a QR code'. So this is correct...

Just want to confirm, the 3 taps here would be Wallet List Cell -> Send From (selects the wallet in the dropdown) -> Use Camera?

And this is also how I envisaged it working...

Maybe what can happen is the 'Scan QR code' camera view can pop up from the place they tap the 'Quick Pay/Send' button (so, within the Wallets tab), then if they don't cancel but get a QR, the app can then switch to the Send tab, select the wallet, and populate the rest of the form. (That way a cancel drops them back in the same place)

If these 'quick' buttons were added, I think this would lead potential design changes through the rest of the app. The rest of my post was trying to second guess these and that was probably premature (I just went with the flow man!). Firstly, if the 'quick' buttons have merit and are adopted, then we can approach these other design changes afterwards.

I think you are right about the pay/send terminology issue.

[paulshapiro]

After thinking about it, moving the Send tab to the middle on mobile, specifically, might make more sense.

[paulshapiro]

I'm still not 100% on the design of the buttons in the cells. At first I was thinking about implementing them with lightweight/flat visuals, probably just the icons and some blue text (wasn't crazy about it though). Then I started to wonder if the buttons are redundant after seeing Copay's usage of a single button for the camera. Is the use-case of scanning QR codes is prominent enough to merit a button that persists in the UI on all screens like Copay's?

Also, one alternative to buttons in the cells (which would allow us to keep the List Cells less busy visually, unless we solve the design problem of buttons in cells) would be to replace the buttons on the Wallet Details page with the "Quick Pay" (show camera) and "Get Paid" (aka "Receive at") features that you proposed, and then, to make sure the user is aware of these buttons upon adding or creating their wallet for the first time in the app, when they log in to a wallet, after a short delay, we programmatically select the corresponding wallet list cell to push the details page for that wallet.

Any thoughts?

[paulshapiro]

Forgot to say, cell buttons could possibly be styled with (rounded) border stroke of text & icon color

[paulshapiro]

oh, blue icon with white sans serif could work