When a large number of search results (e.g. many ROAs listing the ASN searched for) is visualized in the tree, the tree gets very wide. As the entire tree alignment is based on centering, the trunk, the vertical part from root to rir, is somewhere in the center of that very wide tree. But the interface focuses on the first ROA, and thus the view on the tree is limited to the far left part of the tree only. The trunk is not visible, possibly confusing the user.
Restructuring the tree in a way that the trunk is always on the left side of the tree could solve this problem, though only for search results that live under one single RIR and not too many different delegations.
Alternatives to explore:
upon rendering the graphical tree, show the whole tree and automatically zoom in to the focused part (e.g. the first ROA). This does require the user to pay attention somewhat, might not be ideal.
reintroduce the ability to collapse certain parts of the tree. Might be tricky, as collapsing is used in the first place to hide children, thus in a vertical manner, while for this problem we might need a more horizontal oriented collapse.
When a large number of search results (e.g. many ROAs listing the ASN searched for) is visualized in the tree, the tree gets very wide. As the entire tree alignment is based on centering, the trunk, the vertical part from root to rir, is somewhere in the center of that very wide tree. But the interface focuses on the first ROA, and thus the view on the tree is limited to the far left part of the tree only. The trunk is not visible, possibly confusing the user.
Restructuring the tree in a way that the trunk is always on the left side of the tree could solve this problem, though only for search results that live under one single RIR and not too many different delegations.
Alternatives to explore: