Network page: improve topology readability and spacing without changing behavior
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript
- Ambito
- frontend
Direzione di ricerca
Start by reading the existing Network topology renderer and its Treeviz integration, then inspect the existing Selenium coverage for the Network page. Use that coverage to understand current node rendering, interactions, and resize behavior; the issue proposes extending it to check readable sizing, spacing, and preserved behavior. Done means improving topology readability and resize handling while retaining the listed interactions and link styles, with the design question about pan/zoom acceptance resolved.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Is there an existing issue for this?
- I have searched the existing open and closed issues
Is your feature request related to a problem? Please describe
The Network topology is functionally correct, but it can become difficult to read on wide displays and as the number of devices grows.
At the moment:
- Nodes can become very small because the layout tries to fit the topology into the available height.
- Node text can end up difficult to read.
- Device names can be truncated early.
- Treeviz can stretch topology levels across the full canvas width, which leads to very long parent-child links and large areas of unused space.
- The tree does not adapt naturally when the browser window is resized.
The goal would be to improve readability while preserving the existing topology model and all current behavior.
Describe the solution you'd like
I'd like to explore a small, frontend-only improvement to the existing Network topology renderer.
The proposal would be to:
- keep topology nodes at a consistently readable size;
- prevent topology levels from stretching excessively across the full canvas;
- keep small networks making good use of the available space;
- allow medium and large networks to rely on the existing pan/zoom behavior rather than shrinking nodes until everything fits on one screen;
- make the graph viewport follow browser resizing more naturally.
The intention would be to keep the current Treeviz integration and preserve all existing behavior, including:
- sorting;
- filters;
- collapse/expand;
- click and hover interactions;
- relationship colors;
- Ethernet/Wi-Fi/virtual line styles;
- port numbers;
- VLAN/SSID labels.
A possible implementation direction would be to use a readable fixed node size together with bounded Treeviz depth/sibling spacing instead of the current stretch-to-fill layout.
No new settings, no backend or database changes, no plugin changes, no new graph library, and no broader Network-page redesign.
Describe alternatives you've considered
- Keep the current stretch-to-fill layout and only increase node size. This improves readability somewhat, but still leaves very long parent-child links on wide displays.
- Use constant fixed spacing everywhere. This is simpler, but small networks may end up as a compact block in a large empty canvas.
Anything else?
The main design question is whether, for medium and large networks, it is acceptable to prioritize readable nodes and use the existing pan/zoom behavior rather than forcing the entire topology onto one screen at initial load.
If this direction fits the project, I am happy to implement it.
For testing, I would extend the existing Selenium coverage for the Network page to check:
- rendered nodes;
- minimum readable sizing;
- no overlap;
- bounded parent-child spacing;
- unchanged link styles;
- collapse/expand;
- click-to-tab behavior;
- resizing.
I would also manually check Light, Dark and System themes and test against a larger generated topology.
Am I willing to test this? 🧪
- I will do my best to test this feature on the
netlertx-devimage when requested within 48h and report bugs to help deliver a great user experience for everyone and not to break existing installations.
Can I help implement this? 👩💻👨💻
- Yes
- No
- Lingua principale
- Python
- Stelle
- 7.2k
- Fork
- 456
- Merge medio
- 16h 25m
- PR unite (30g)
- 30
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di netalertx/NetAlertX
-
Docker 🐋
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug 🐛 Contributors 🙏 help wanted 🆘
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
bug 🐛 next release/in dev image 🚀 Waiting for reply⏳
Difficoltà 3/5 Mezza giornata Idoneità per principianti 57/100
netalertx/NetAlertX#1852 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug 🐛 next release/in dev image 🚀 Waiting for reply⏳
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
netalertx/NetAlertX#1831 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Feature request ➕ please feedback 💬
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
netalertx/NetAlertX#1827 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di netalertx/NetAlertX
Issue simili
-
difficulty:2 enhancement good first issue
Difficoltà 1/5 1-3 ore Idoneità per principianti 92/100
MakazhanAlpamys/Soup#2178 ·
I maintainer di solito rispondono entro 1 giorno
-
Slang input: int8_t4_packed and uint8_t4_packed are copied into CrossGLForse già presa @ninglinLiu l’ha presa oggi. Apertaarea:frontend backend:slang bug direction:input
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 13 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
Kozea/Radicale#2301 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug ci good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno