move the node list from a char box in the upper right to a dedicated column on the left side of the page

[gruns]

• the node list in a box in the upper right is cramped. eg #37

• the bottom chart, Global Bandwidth Served is forced below the fold on small(er) screens, eg laptops

• by moving the node list to a dedicated column on the left, the first thing

• include an entry in the column on the left for All nodes, or similar, to show chart data that includes all nodes

• a nice to have would be to show the location of each node, with both country emoji and city name, along with each node's id. eg each row of the nodes table on the left of the page could be: [country flag emoji] [city name] [node id]. can play with it to see what fits in the given space

example of prior art enumerating items in the left column in arc's portal:

[gruns]

• [ ] also include the nodeid in the dashboard url once selected

  right now, after a specific node is selected, the url isn't updated to reflect that selection. for example, the url remains the same https://dashboard.strn.network/address/[wallet] whether or not a specific node has been selected or not

  instead, the url should be updated, like:

  • url all nodes of a wallet: http://127.0.0.1:3010/webui/address/[wallet]
  • url with a specific node selected: http://127.0.0.1:3010/webui/address/[wallet]/[nodeid]

[gruns]

wrt priority, this is a low-ish priority improvement. it does not block other updates to the dashboard (though obviously the earlier this ships the better so other updates to the dashboard dont need to be rewritten/modified for this new, final layout)

[AmeanAsad]

@gruns one benefit of the nodes table above is that it allows node operators to quickly filter/sort their nodes by some metrics. I feel like this functionality is useful to node ops but would be hard to replicate with a sidebar UI wise.

[gruns]

@gruns one benefit of the nodes table above is that it allows node operators to quickly filter/sort their nodes by some metrics. I feel like this functionality is useful to node ops but would be hard to replicate with a sidebar UI wise.

this is an excellent point 👏. sorting, like by payout status and earnings, is definitely a useful feature we don't want to lose, if we dont have to 👍

i think the solution here is still to move the nodes list to a wide(r) sidebar on the left, but also to be more cognizant of horizontal space. if we can get the width down to 400px-ish, i think that should be ok

to cut the going from left to right in the columns:

• 1st column, with the dedicated render node info buttons, can be cut entirely
• 2nd column, node id, remains, but the copy button is hidden by default and only becomes displayed, position: absolute on mouseover. thus it takes up no permanent, static space
• 3rd column, estimated earnings, can be shortened by truncating the FIL from XXX FIL to just XXX (and (FIL) is included in the column header) or XXX (F) where (F) is a skinnier filecoin logo
• 4th column, payout status, can be shrunk by replacing valid and pending with two different icons that, on mouseover, show the full Valid or Pending. for example, a green checkbox logo that, on mouseover, displays Valid and a yellow clock logo that, on mouseover, displays Pending
• 5th column, bandwidth, no changes
• 6th column, retrievals, shorten from the full 72,102, 4,003,018 to use metric suffix: 72k, 4M, etc

hopefully all these horizontal space saving reductions can fit all the nodes in the sidebar + their metrics in a sortable manner. if not, let's readdress a different UX here

a sidebar, of course, only works well on desktop. on mobile? i see two solutions:

1) the sidebar, which enumerates nodes, becomes a tray that slides in and out. there's a button in the upper left, or upper right, that when tapped slides out the list of nodes that can be selected. not dissimilar to the navbar on saturn.tech

2) the sidebar, which enumerates nodes, becomes a table that's displayed above the other graphs. like the current design on mobile, but with the overview and nodes boxes swapped

of these two, i think the second will be much easier to implement, and thus we should go with that for now. wdyt?