Open soad003 opened 6 months ago
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.
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:
TODOS Before User Test:
TODOS in general:
Tasks derived from comments by bhas.
Bugs:
Improvements
Harmonization:
At some point:
Bigger open tasks which need design consideration:
Things to mention/discuss
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.