Transaction Detail View

[snreynolds]

Right now users are able to see transaction details like to, from, gas price, gas limit, etc... by clicking on the transaction in their history and being redirected to etherscan. It would be nice for users to view basic transaction details inside MetaMask (like to, from, and total transaction fee).

Additional features to consider: show deduction of transaction fee?

[bdresser]

@cjeria could you link your invision mocks?

[cjeria]

Full screen mode
https://consensys.invisionapp.com/share/TYGK6CKMJ7F#/290468286_cancelled_Success_-_End_2

Extension mode
https://projects.invisionapp.com/prototype/cjg0fbrv1000bv2010gi42iix/play

[cjeria]

Screenshots as well

[bdresser]

these are really sharp @cjeria

We're currently using slightly different terms to describe transaction states. Here's the complete list:

Unapproved: the user has not responded (generally not shown in UI)
Rejected – the user rejected the tx
Approved – the user has approved the tx (generally not shown in UI)
Signed – the tx is signed (generally not shown in UI)
Submitted – the tx is sent to a server
Confirmed – the tx has been included in a block.
Failed – the tx failed for some reason, included on tx data.
Dropped – the tx nonce was already used

I think we can consolidate a little with what's currently in these mocks

• "pending" and "waiting" could just be "submitted" ?
• what is the functional difference between "created" and "submitted" in the activity log - can a tx be one but not the other?
• our current terms might not be perfect.. if you think we can tune them up with some light user testing, let's!

Some other miscellanea

• transaction headers are different in extension view & full-page ("Outgoing" vs. "Sent Ether"), maybe we should make consistent. Perhaps we can pull whatever we've identified as the function name and use that as the header for each row?
• as @danfinlay mentioned, maybe we should allow users to click somewhere to expand what's in the data tab on the new confirm screen (function name, parameters, hex data, etc)

Sorry for the braindump, let's put this on the list for next design review

[bdresser]

re: cancellation - relates to
MetaMask/metamask-extension#4022
MetaMask/metamask-extension#3312
MetaMask/metamask-extension#4425

could include a "cancel" button for the first submitted tx that's still pending. or a "cancel all" as described in 4022

[bdresser]

from @owocki in slack

id suggest putting an orange warning message up at the top of the wallet if the user has > 3 pending txs with the first one being a low nonce. a lot of people dont know about this aspect of the ethereum ecosystem (low gas fee / low nonce txs blockcing everything), and putting this specific info up to in a dismissable warning would be 💯

[cjeria]

@bdresser I agree, perhaps tx state terms could be simplified!

Tx states

"pending" and "waiting" could just be "submitted" ?

Pending is the latest transaction submitted to the tx pool trying to be mined.

Waiting txs are the blocked tx's "waiting" to be submitted to the tx pool, but that the user has "approved".

This is an important differentiation because tx's can be queued up locally in chronological order under the top grouping labelled "Pending". The grouping label should probably change to Queue instead?

The txs in the history are ordered in reverse chronological order.

what is the functional difference between "created" and "submitted" in the activity log - can a tx be one but not the other?

Txs can be "created" but not approved. It's the state of the tx before the user hits the "confirm" button. It's purpose is to distinguish when a transaction was created and when it was submitted (or approved) by the user. That's why you can see a "1" in the extension icon.

transaction headers are different in extension view & full-page ("Outgoing" vs. "Sent Ether"), maybe we should make consistent. Perhaps we can pull whatever we've identified as the function name and use that as the header for each row?

Good catch! I'd say the full-screen mocks are the latest designs while the mobile form factor mocks are little outdated. Totally agreed that tx headers need to be consistent and should be named clearly to avoid confusion. More user-testing should be conducted!

[owocki]

excited for this :)

[bdresser]

Txs can be "created" but not approved. It's the state of the tx before the user hits the "confirm" button.

TIL :)

The grouping label should probably change to Queue instead?

Sounds good

Some questions on cancellation, since it's coming up more:

• What about the "cancel all" button you mention in Design for multiple pending TX cancellation metamask-extension#3312 & Add "Cancel all" button for stalled transactions metamask-extension#4022? Or should we handle that separately?
• Cancelling will prompt the user to submit a 0 ETH transaction with some gas. Does the confirm screen need any helper detail to let the user know why they have to pay?
• The buttons on the screenie below are a new UI pattern and took me a while to notice. What about including them below all the detail? Or maybe some user testing to see what real peep think?
• Does the "speed up?" prompt stay the same? Should we provide the option to cancel alongside the option to reprice?

@cjeria

[danjm]

Given MetaMask/metamask-extension#4826, should we only show the "Speed Up" button in the details of the first / "Pending" transaction @danfinlay?

[cjeria]

Yes, that's correct @danjm ! The speed up button is only intended for the first pending tx.

[bdresser]

also, what does the "Speed up?" suggestion look like when the pending transaction detail isn't expanded?

[cjeria]

@bdresser the user would get a tooltip on hovering over the status. clicking anywhere on the transaction container should expand the transaction details.

[cjeria]

perhaps the status indicator for pending could have a spinner to better indicate that it's trying to be processed by the network.

[bdresser]

@cjeria could we add a "cancel all" button to these designs?

[cjeria]

I've been thinking about the problem we've been seeing lately with users having multiple "stuck" transactions. This begs the question - Why don't we try preventing the problem from occurring in the first place by blocking new transaction from being created while a slow/stuck transaction is waiting to be mined? My hypothesis is that if we apply this constraint we will prevent people from making mistakes or running into this problem altogether. @bdresser @danfinlay

[bdresser]

yeah @cjeria that makes a lot of sense.

As we discussed the other day, we could show a small warning on the Confirm screen when a user has other pending transactions before the one they're about to submit. If that sounds reasonable, I'll open a separate issue.

This won't always solve the problem, since some folks will want to approve multiple tx and just let them confirm sequentially, so I think "cancel all" is still important - we can track this separately.

[cjeria]

Here's the updated transaction details screen with the "Cancel All" button included. The style of the detail components also better matches the extension format designs posted above.

[bdresser]

heads up @danfinlay @danjm @alextsg - any final feedback? otherwise moving to "done"

[danfinlay]

I like this, it adds all the cancel buttons we've been wanting, I'm all for it.

[kingjacob]

If I may suggest flipping the USD and Eth in the transaction detail and the right column, since it's ether being sent and usd is just a reference. Additionally, it would make it more uniform with the rest of the UI e.g the token-list.

Edit: Clearer distinction between the primary asset and the descriptor would also prevent the possibility of confusion if someone is using a token as their conversion currency.

[sidenote: also noticed you can't pick ETH as your conversion currency, is this an open issue?]

[bdresser]

@kingjacob yep, same response to your other post - suggestions welcome on MetaMask/metamask-extension#4510

[danfinlay]

TX Queue

• “Outgoing” word is probably not as useful as it could be, not the interesting part.
  • We should upgrade to better label when possible (we show method names when possible already)
  • Maybe upgrade further when possible - “Sent tokens” or “Sent ether” or “Sent x GNO”?

In short: These tx cells are about as open ended as our confirmation screens. The more transaction-specific clarity the better.

Edited: Was distracted when first writing, lots of unclear bits.

[bdresser]

to the above ^

Since everything is "outgoing" we should use that string to describe the type of interaction instead. (discussed here, but I think it got missed).

• For basic sending ETH we should say "Sent Ether" (as in the mocks)
• For token transfers we should say "Transferred [Token name]" (The value is redundant, it's on the right side already. Also cool with "Sent [token]" if you prefer)
• For known function names we should use the function name
• For unknown function names, we could say "Sent to contract"

@cjeria @alextsg make sense? anything to add?

active PR with mocks MetaMask/metamask-extension#4919

[alextsg]

@bdresser Since we're showing the number of tokens transferred along with the token symbol on the right side, can we say "Sent Tokens" instead of "Send [token]" or "Transferred [Token name]"?

[bdresser]

@alextsg yeah good call

[bdresser]

Since we started showing the "speed up" link on only the first transaction, we've gotten a bit of feedback on how it's harder to find. I've also seen two reports that mention how the new ui's language ("increase the gas price") is more vague than the old ui's ("retry with a higher gas price here").

I'm not suggesting we change designs at this point, but let's keep our ears open for feedback on how the "Speed up" button is placed once this rolls out – I'm still worried folks won't see the tooltip when hovering over the "Pending" state, and I'm not sure the shorter "Speed up" phrase is as beginner-friendly as the full problem-solution statement we have in the old UI. @cjeria