UI Overhaul: create tx view graph prototype

[soad003]

We want to develop a tx graph prototype that allows users to trace transactions on a transaction level. The current ui is based on addresses and aggregated flows which makes tx level tracing hard.

[soad003]

• [x] create branch
• [x] create new graph canvas and routing
• [x] Add nodes to graph
• [x] show basic property box on selecting a node
• [x] allow (multi) node selection
• [x] edge selection dialog
• [x] display edges on adding a node (how should this work?)
• [x] refining display

[myrho]

• [x] auto filter tx table depending on visible txs in graph (only show future/past txs)
• [x] highlight edges on hovering and selecting
• [x] show detailed tooltip on hovering tx edge
• [x] show short tooltip on hovering tx node
• [x] uncheck tx, addresses in tables
• [x] uncheck support in in- output table
• [x] never leave a tx node unaccompanied by i/o addresses
• [x] undo/redo, also via keyboard
• [x] delete things, also via keyboard
• [x] show node icon for a tagged one
• [x] display actor/tags in details box
• [x] show actor image somewhere else in the details box, not in the node icon
• [x] ask for confirmation before clearing the graph
• [ ] auto-link two subsequential address searches if they are neighbors

[soad003]

I have checked the bullet point show short tooltip on hovering tx node although not implemented. It's is hard to hit, and we are not sure if needed.

[soad003]

I did some usability testing of the UI based on the hackathon challenges we worked on in spring. I think for tracing purposes where a concrete starting transaction is known, the UI works well. I was able to relatively quickly (apart from a couple of performance hiccups) navigate the cases forward and backward. Obviously, for exploration purposes the old graph is more suited, so checking out what neighbors exist etc. But that is not the main purpose of the tx graph, IMHO.

We have already talked about it, but I think the one thing that would be important to add before we do user tests is to incorporate the cluster information in a smart way. Not necessarily as a (very long) list of addresses as in the address graph UI but, but in a visual way, e.g. by highlighting all nodes in the same cluster if one is hovered. Without that, it is really hard to see when money changes hands (leaves a cluster). Having this cluster information displayed would also help the user to identify which output is likely the payment in cases where the change is transferred to another address that still belongs to the same cluster. This would help to avoid following the change part of the transaction. Moreover, cluster information gives the users some intuition about what kind of entity they are dealing with even if no tags exist (> 1000 addresses, or more than 2k txs, likely not a regular user). We also got the same feedback from ZCB (in the den haag meeting) that the cluster info is very important for them, same goes for Bernhard. So I think we should have something in that regard before we show it to users.

On a similar note: One issue I had during replaying the investigations was that our tagging at the moment only works on the address level, we do not show cluster level information. Although that this it the most reliable way to do things, in our Hackathon investigations, many of the tags we relied on were tags on the cluster level. By only looking at the address tags we would have missed many exchanges. I think we should think about also showing cluster level tags to the user as lower quality tags/ inherited tags, maybe even with a switch where user can decide if they want to show direct or also inherited tags. Even though they are not as reliable as direct tags, the inherited tags are often important pointers that we should not ignore or hide from the user. Esp. in the case of exchange tags, its better to inherit some false ones that not showing them.

Regarding the auto expansion feature, we deactivated the backwards direction for now since there were some edge cases that we just did not know how to handle properly, e.g. this transaction 6350338602ec41ed32699f24891bb989b687c1ea56dea3f75243241d67481564 which is an inflow transaction to account 3JjPf13Rd8g6WAyvg8yiPnrsdjJt1NP4FC but is no net inflow since 3JjPf13Rd8g6WAyvg8yiPnrsdjJt1NP4FC is just getting the change back. Transactions of this type also show the downsides of the just expand the biggest in and outflow of a transaction, in this case it is just the change. For cases where the change address is just the sender, address we can handle these situations, but in general e.g. if users use fresh change addresses this is hard to handle. So, long story short, I am still skeptical about the auto expansion feature. One case where it really improved the workflow was if a lot of single transaction nodes (with one in and one out tx) were in the path, there it made it very convenient to move forward.

Notes and Nice to haves:

1. in the tx list it would be nice to see which one of the transactions is either a follow-up or previous tx to the ones on the graph (spending, spent_in endpoints). An alternative point to display this info is in the transaction details eg. as a button show spending tx on an output, or to show the spent output on the input side. This would allow the user to do the same navigation steps as the auto expansion feature does, and would probably make it easier to explain what the feature does.

TODOS Before User Test:

• [x] Add cluster info (what nodes belong together, visual, maybe display basic cluster statistics in details view)

TODOS in general:

• [ ] Rethink/ Discuss auto expansion / edge cases
• [x] How to deal with cluster tags

[soad003]

Tasks derived from comments by bhas.

Bugs:

• [x] search box does not disappear

Improvements

• [x] remove tx hash sorting in tx table (remove all sorting)
• [x] time filter shows previous day -> confusing
• [x] show filter line only if filter is set in tx list
• [x] do not show address tooltip if property box is open
• [x] change debit/credit to value in tx table
• [x] remove aggregation input/output aggregation indicator (not needed)
• [x] Show actor name if exchange and actor is available (remove tag label if exchange and no other tag)
• [x] extend search box dropdown (no truncation of address)
• [x] show timezone indicator in dates (eg utc+x)
• [x] Remove duplicate pathfinder logo in header

Harmonization:

• [x] show time in first/last seen
• [x] always show year with 4 digits
• [x] Harmonize address display
• [x] Harmonize date format (Month 3 letter day, year 4 digits, no dependence on user locale)
• [x] Harmonize font application wide (roboto and robotomono for hashes in tables)
• [x] change red and green colors
• [x] remove cluster id from property box once we have an alternative way to show clusters

At some point:

• [x] tagging, put tags into categories high, low, medium
• [x] search bar highlight typed part
• [ ] implement eth tracing, show 0x ...

[soad003]

Bigger open tasks which need design consideration:

• [x] Visually show clusters (e.g. by highlighting)
• [x] Tag details view (sep. tags into high, med, low confidence -> maybe also derived tags from cluster)
• [x] placement of buttons (e.g. one toolbar as in desktop tools?)
• [x] Tx List Settings
• [x] Display/ Settings take a lot of space (e.g. create a settings page)

Things to mention/discuss

• [ ] display shortcuts / discuss usability (came up in the selection of nodes)
• [ ] Make node arrows (next tx) more intuitive (auto expansion can be hard to grasp, but it's optional anyway, maybe context menu? Expand next best transaction)