Summary of Direction/Type columns problem and a new suggested trade-off

[hebasto]

As mentioned in #372, the "Type" column without the "Direction" one looks indeed like unfinished business.

Personally, I'm using the "Type" column sorting every time I open the GUI. And I'll be very disappointed if we end up with reverting this feature back (see #372).

One of the flaws in the current state is mixing of independent data in the "Address" column content. It leads to unwanted issues (see #397, #400).

Currently, we have two alternative PRs that add the "Direction" column: #317 and #363.

#317 (#289)

• has support of 5 developers (including pr authors)
• 2 developers expressed their satisfaction with the current state (one of these opinions includes a suggestion for a different approach)
• 1 developer submitted an alternative PR

#363

• has support of 1 developer (pr author only)
• 2 developers expressed their disagreement

---

Nevertheless, I still believe we could find the common ground and reach the rough consensus in this problem.

Here is my attempt at formulating the distinguished issues related to the problem.

Issue 1: Mixing of independent data

The fact is that a connection direction and a peer address are completely independent data, therefore, a table that presents such data to users shouldn't mix them into one column, as this definitely hurts UX.

For historical notes, see:

• Remote peer debug window: Show connection direction (in/out) bitcoin/bitcoin#13483
• GUI: Peer table: Visualize inbound/outbound state for every row bitcoin/bitcoin#13537

Issue 2: Semantics of "arrows"

The fact is that arrow symbols—neither "up" and "down" (current state), nor "left" and "right"—have no implicit or ubiquitous semantics of "inbound" and "outbound". They mean nothing without a context.

Issue 3: Horizontal space and Localization

One of the concerns about adding a new "Direction" column is that it consumes more horizontal space then a symbol does.
As an alternative, the "in" and "out" short words were suggested (disregarding letter capitalization).

The main flaw of such an approach is that the shortest translated words with the suitable meanings could be much longer. It makes this approach practically useless.

---

Note about symbols

We could replace arrows with symbols with suitable semantics, for example:

• https://github.com/bitcoin-core/gui/blob/master/src/qt/res/icons/tx_input.png
  
• https://github.com/bitcoin-core/gui/blob/master/src/qt/res/icons/tx_output.png
  

Or we could choose any other free icons with appropriate semantics.

Note about data mixing

After replacing the meaningless "arrow" symbols with some meaningful ones, it'll still require to move it out from the "Address" column:

• (A) into a new dedicated "Direction" column
• (B) into the current "Type" column

Note about horizontal space and Localization

Unfortunately, the (A) solution won't save the horizontal space in all cases. The "Direction" column still require a header title, e.g., the word "Direction". And, again, its localized variant could be much longer.

---

Suggested trade-off approach: a combined "Direction/Type" column instead of the current "Type" one

The combining a direction and a type data into one column looks pretty legitimate because these data are closely entangled (see #203).

Here are possible implementations:

• (B.1) an icon-prefixed string
• (B.2) considering that in the current "Type" column cells are empty iif a connection is inbound, we could use the "Inbound" word as a type of inbound connection, and connections with other types are implicitly outbound. In that case no icons/symbols are required at all.

I think the B.2 solution is a good trade-off. And it does not increase the horizontal space usage. Actually, this solution decreases it by removing arrow symbols from the "Address" column.

Searching for productive discussion without opinions based on personal taste.

[hebasto]

Closed in favor of #317.

[ghost]

Thank you very much.
I already thought about if for every inbound connection, the type is definitely empty. I do not know if this is guaranteed because it is (at least currently) technically not detectable?

My suggestion:

(B.3) Put the inbound/outbound icon prefix (which I like very much) before every connection type. If connection is inbound, the connection type should be "Not detectable" (if this is technically correct) or alternatively "Unknown" unspecific "Inbound". Alternatives could be "Universal", "Generic" or "Common".

This would also be fine for sorting, as the connection type "Inbound" and connection "inbound" are always coupled.

With this commit it looks like so:

Sorting of the Type column works.
What is missing in the screenshot are the new icons suggested by Hebasto, I just used the arrows here.

[RandyMcMillan]

I generally agree with this line of thinking.
Long term - establishing a symbolic "language" will have benefits.
git/github tackled this issue years ago.
I would suggest drawing from the established iconography - the work has already been done.

https://github.com/primer/octicons