You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Z-Wave JS UI gives us deep visibility into a Z-Wave network: node management, provisioning, statistics, logs, and firmware updates all live there.
It grew feature by feature over several iterations, and that history now shows. Related settings are split across different tabs, some screens mix beginner and advanced actions on the same page, and terminology is inconsistent between sections.
With Z-Wave JS UI now bundled directly into the Z-Wave JS add-on (#199), more people potentially will open it as part of their everyday setup rather than only when troubleshooting, or maybe out of pure interest.
Thus, this is a good moment to revisit the interface as a whole so it reads as one coherent product instead of a set of features stacked on top of each other, and so people can find and understand the information they need without prior Z-Wave expertise.
Community signals
Navigation clarity was flagged directly by users and already partially addressed: a request to show labels on all navigation tabs was raised and shipped as a setting — https://github.com/zwave-js/zwave-js-ui/issues/4562 (implemented via https://github.com/zwave-js/zwave-js-ui/issues/4563). This shows navigation is confusing enough by default that the fix needed a manual toggle rather than being solved outright.
A feature request for the Smart Start / LR inclusion flow shows a user struggling to understand and predict UI state, explicitly prefacing their suggestion with "I'm not a UI/UX designer" while asking for more obvious, more consistent interaction patterns: https://github.com/zwave-js/zwave-js-ui/issues/3754
New functionality or features beyond what Z-Wave JS UI already offers
Changes to the underlying Z-Wave JS driver or protocol handling
Migration or data model changes tied to the add-on merge itself (tracked separately)
Foreseen solution
We audit the current Z-Wave JS UI interface screen by screen and map what exists today against how it is actually used. We are not aiming to reinvent the navigation, we are streamlining what's already there: grouping related settings, actions, and diagnostics into predictable places, applying consistent naming across screens, and aligning the visual style with the design direction already emerging for the merged add-on. We roll changes out incrementally, screen group by screen group, so we can validate each change against community feedback rather than shipping one large redesign at once.
Problem statement
Z-Wave JS UI gives us deep visibility into a Z-Wave network: node management, provisioning, statistics, logs, and firmware updates all live there.
It grew feature by feature over several iterations, and that history now shows. Related settings are split across different tabs, some screens mix beginner and advanced actions on the same page, and terminology is inconsistent between sections.
With Z-Wave JS UI now bundled directly into the Z-Wave JS add-on (#199), more people potentially will open it as part of their everyday setup rather than only when troubleshooting, or maybe out of pure interest.
Thus, this is a good moment to revisit the interface as a whole so it reads as one coherent product instead of a set of features stacked on top of each other, and so people can find and understand the information they need without prior Z-Wave expertise.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
We audit the current Z-Wave JS UI interface screen by screen and map what exists today against how it is actually used. We are not aiming to reinvent the navigation, we are streamlining what's already there: grouping related settings, actions, and diagnostics into predictable places, applying consistent naming across screens, and aligning the visual style with the design direction already emerging for the merged add-on. We roll changes out incrementally, screen group by screen group, so we can validate each change against community feedback rather than shipping one large redesign at once.
Risks & open questions
No response
Appetite
Medium - 1 cycle
Execution issues
No response
Decision log