Note: This issue includes and therefore supersedes https://github.com/ipfs-shipyard/ipfs-webui/issues/1037 and https://github.com/ipfs-shipyard/ipfs-webui/issues/1117.
Enhance Peers page by adding table columns for transfer rates and IPFS version, and removing unused "Notes" column.
TotalIn and TotalOut, or -- if sum(TotalIn, TotalOut) = 0sum(TotalIn, TotalOut)0.2 kB in favor of 211 B)sum(RateIn, RateOut) > 0 ), add an "indicator light" whose colors are the same as the in/out colors on Status page; for edge case in which out/in values are the same, split the circle in two as per mockupRateIn and RateOut as well as TotalIn and TotalOut, per mockupdirection to the hover text as such: /multi/addr (outbound) (note this doesn't appear if using js-ipfs)AgentVersion via ipfs id <PeerId>DHT, Bitswap (note this doesn't appear if using js-ipfs)
Transfer column: We risk having multiple values we can sort on here. I assume the highest-impact one, and therefore the sort trigger, is "transfer in" -- thoughts on this?
What about separating it between in & out into their own columns? Would be better for sorting
@rafaelramalho19 Wondered that too, but ended up settling that breaking them into two columns might be disconnecting them too much, and giving each too much importance. If the primary question we're trying to answer is "which peers am I trading with", a single column would be better at indicating that (particularly with the addition of the orange/teal indicator light). Curious what @lidel thinks though.
Some answers:
sum(in+out) then we always promote peer that generates the biggest traffic – should be enoughnits/ideas:
ipfs id → AgentVersion and decrease vagueness (in IPFS we have many protocols, each has "version", but there is only one "Agent"). Feel free to ignore if I am overthinking this or "Agent" is not the best word for some reason?@lidel Thanks! I'll update mockup in the morning but one question in the meantime:
Would use of icon/emoji instead of text "in"/"out" help? I worry that translation of these words may be pretty long in some languages
We could, but I don't believe we would be able to include those icons/emoji in the hover state, and that would introduce inconsistency. Thoughts?
@lidel and @rafaelramalho19 -- updated https://github.com/ipfs-shipyard/ipfs-webui/issues/1602#issue-686601595 to include notes mentioned above. This includes a rough first pass at out/in icons based on our existing stroke_link_external.
Wondering if including an "indicator light" adds noise rather than value -- https://github.com/ipfs-shipyard/ipfs-webui/issues/1602#issue-686601595 now includes two screenshots, one with lights, one without.
Further thoughts?
I like both, unsure how many active transfers regular desktop user would see (more on that later).
In the context of the other visuals, the entire screen got a bit noisy, but I don't think the main offender being the "indicator light". If anything, I think in/out icons are more distracting.
Some ideas (but not feeling too strong about them):
4 kB • 0 B)RateIn/Out and TotalIn/Out in the hover, for additional clarityTweaking noise vs signal ration made me think about how often user will look at Peers screen _while there is an ongoing transfer on that exact moment_. Desktop users won't have that many data, so unless they happen to download something big at the same time, they will just see boring empty column for the most of the time:
What if we optimize for the most common, boring state when "nothing happens", and:
-- otherwise)sum(TotalIn, TotalOut)sum(RateIn, RateOut) > 0 (and then current Rates and Totals on hover)(Just an idea, I'm ok with us implementing rates as the default first, and then re-evaluating after looking how it behaves irl)
@lidel these are _excellent_ ideas! Adjusted mockup (note German just for idea of longer words) and specifications accordingly.
I'm not 100% convinced that total in/out is more valuable than current in/out, but if we keep the indicator light, that allows us to convey enough info (_is_ a transfer happening right now?) all at once.
I think we might be ready to go here ... any other thoughts?
Thank you @jessicaschilling, looks good to me, ready for impl.
(I agree it's not ideal, but a good starting point. Just like with the map, where we tweaked clustering so regular users with 100-300 peers have a nice view, we may revisit various aspects after we see how it behaves in real situations.)
Thank you! @rafaelramalho19, do you still have time to take this on? Anything I can help with?
Yes, after the breadcrumbs work I'll pick up this 😄
As this work did not start yet, I propose we move it to v2.12.
This will enable us to ship v2.11 sooner and be ready for upcoming ipfs-desktop with go-ipfs 0.7.0
Y/n?
OK.
Note - https://github.com/ipfs-shipyard/ipfs-webui/pull/1616 stubs everything out and meets visual spec, but still needs wiring up.
It's great to see the progress, looks great!
Would you consider changing the values in the Peer ID column to links that open the Explore page with that particular IPNS address?
@andrasfuchs -- nice thought!
@lidel, do you see any reason not to?
@andrasfuchs @jessicaschilling
Main concern: most addresses will never resolve because most of the peers never published anything under the self key, which means user clicks on a link the Explore page tries to resolve /ipns/<peerid> and displays spinner forever, or timeouts after a minute. And that's pretty bad user experience.
What I would do instead, is to copy value clipboard when user clicks on table cell (with some visual feedback).
It could be enabled for all columns, but especially for Peer ID and Connection.
@lidel Good idea!
Is it technically difficult/expensice to detect if someone is sharing anything publicly?
If it's cheap(er) then the value in the Peer ID column could be clickable only if there is actually something to see there.
@lidel What would be copied in the Connection column?
Note: Added an additional to-do item to https://github.com/ipfs-shipyard/ipfs-webui/pull/1616 for feedback upon copy (think we can just use the snackbar for this).
@jessicaschilling the original Multiaddr value we currently show onhover in title (/ip4/.../p2p/Qm...)
@lidel Thanks for the clarification - added that as a to-do item in https://github.com/ipfs-shipyard/ipfs-webui/pull/1616.
Identified two more things that go-ipfs provides and what we could surface on the Peers screen:
$ ipfs swarm peers --streams --direction
/ip4/A.B.C.D/udp/4001/quic/p2p/QmPeerId outbound
/ipfs/bitswap/1.2.0
/ipfs/kad/1.0.0
...
I think those are in the same category as "agent version".
Perhaps we could show them alongside under "agent details" somehow.
This could be a part of #1616 or separate PR in the future.
@jessicaschilling thoughts?
@lidel Would "streams" activity type make sense as a hover state for a value in the Agent column? We could add that to requirements for #1616.
I'm struggling a bit with where we'd want to display who initiated the connection, particularly since "direction" as a term is easily confused with the data in the in/out column. Do you have any thoughts on how we might be able to word this more clearly in the hover state for the Agent column?
streams could be onhover in Agent column for nowdirection could be appended to the onhover text in Connection column (/multi/addr (outbound))streams/direction, UI should work fine when API does not return them (we don't want to break webui in js-ipfs)@lidel SGTM. Does that mean you're going to implement the rest of #1616? ;)
@lidel Requirements have been updated both in the first comment of this issue, and in PR #1616. Anything else I can get you to make this easier?
Most helpful comment
Yes, after the breadcrumbs work I'll pick up this 😄