starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

UI improvement: Use active nav-tab instead of a button on sub-panels in the Device Type view #5496

New Issue
Closed
opened 2025-12-29 19:28:42 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:28:42 +01:00
Owner
Copy Link

Originally created by @jbakklund on GitHub (Oct 8, 2021).

NetBox version

v3.0.6

Feature type

Change to existing functionality

Proposed functionality

IMO, the appearance of active sub-panel navigation tabs (button class="nav-link active") in the object view for Device Types, breaks the consistency of the UI:

Button class nav-link active

I suggest to change it, making it appear like a regular active tab instead:

tab class nav-link active

Use case

Makes the UI more consistent.

Database changes

None

External dependencies

None

Originally created by @jbakklund on GitHub (Oct 8, 2021). ### NetBox version v3.0.6 ### Feature type Change to existing functionality ### Proposed functionality IMO, the appearance of active sub-panel navigation tabs (button class="nav-link active") in the object view for Device Types, breaks the consistency of the UI: ![Button class nav-link active](https://user-images.githubusercontent.com/33431806/136548905-e3261903-61b3-4d30-afa8-d9cab167b244.png) I suggest to change it, making it appear like a regular active tab instead: ![tab class nav-link active](https://user-images.githubusercontent.com/33431806/136549877-3dc1a2fa-6b91-4d7d-b416-e9f464494179.png) ### Use case Makes the UI more consistent. ### Database changes None ### External dependencies None
adam added the type: feature label 2025-12-29 19:28:42 +01:00
adam closed this issue 2025-12-29 19:28:42 +01:00
adam commented 2025-12-29 19:28:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 8, 2021):

From what I recall, the intent early on was to split these into separate views, similar to how device components are managed, but we haven't gotten that done yet. We're using nav "pills" to toggle between these panels as it would look odd to have have a row of tabs inside the top-level tab. Once the component lists are split out into separate views, we can move these to the top-level tabs.

@jeremystretch commented on GitHub (Oct 8, 2021): From what I recall, the intent early on was to split these into separate views, similar to how device components are managed, but we haven't gotten that done yet. We're using nav "pills" to toggle between these panels as it would look odd to have have a row of tabs inside the top-level tab. Once the component lists are split out into separate views, we can move these to the top-level tabs.
adam commented 2025-12-29 19:28:43 +01:00
Author
Owner
Copy Link

@jbakklund commented on GitHub (Oct 11, 2021):

I am concerned of the risk that the top row of nav-tabs gets so cramped that it might split in two if all these lists are moved to separate views and the screen real estate is not big enough to fit all tabs in one single row. It will look messy, having nav-tabs split across more than one row.

I think the current layout works pretty well, and I find nothing odd about having sub ordinate folders inside a main folder. They did occur inside old archive filing jacket folders too, as far as I remember, and modelling such sub folders to appear as they are floating in front of the parent view, is something I believe to be quite common.

The use of a button-like 'nav-pill' instead of a regular 'active' nav-tab, is though a first to me. A button implies that pressing it will cause some action, in my eyes, but that is not the case here - is it?

Distance and spacing between the top-level tabs and the tabs above the sub panels, is more than sufficient to maintain a clean and tidy look. My suggestion is not to move the tabs for the sub panels inside the top-level, but keeping them where they are while getting rid of the intrusive looking button like nav-pill currently used to flag active sub-panels.

@jbakklund commented on GitHub (Oct 11, 2021): I am concerned of the risk that the top row of nav-tabs gets so cramped that it might split in two if all these lists are moved to separate views and the screen real estate is not big enough to fit all tabs in one single row. It will look messy, having nav-tabs split across more than one row. I think the current layout works pretty well, and I find nothing odd about having sub ordinate folders inside a main folder. They did occur inside old archive filing jacket folders too, as far as I remember, and modelling such sub folders to appear as they are floating in front of the parent view, is something I believe to be quite common. The use of a button-like 'nav-pill' instead of a regular 'active' nav-tab, is though a first to me. A button implies that pressing it will cause some action, in my eyes, but that is not the case here - is it? Distance and spacing between the top-level tabs and the tabs above the sub panels, is more than sufficient to maintain a clean and tidy look. My suggestion is not to move the tabs for the sub panels inside the top-level, but keeping them where they are while getting rid of the intrusive looking button like nav-pill currently used to flag active sub-panels.
adam commented 2025-12-29 19:28:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 11, 2021):

I am concerned of the risk that the top row of nav-tabs gets so cramped that it might split in two if all these lists are moved to separate views and the screen real estate is not big enough to fit all tabs in one single row.

This is how the device view works currently and it hasn't been a problem. I'd like to stay consistent between the two views.

@jeremystretch commented on GitHub (Oct 11, 2021): > I am concerned of the risk that the top row of nav-tabs gets so cramped that it might split in two if all these lists are moved to separate views and the screen real estate is not big enough to fit all tabs in one single row. This is how the device view works currently and it hasn't been a problem. I'd like to stay consistent between the two views.
adam commented 2025-12-29 19:28:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 12, 2021):

I've opened #7530 to move these tables to separate views as described above.

@jeremystretch commented on GitHub (Oct 12, 2021): I've opened #7530 to move these tables to separate views as described above.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5496
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?