Skip to content

Let people reach the pages they use without digging through Settings #255

Description

@matthiasdebaat

Problem statement

Home Assistant has many pages and the sidebar shows all of them. The only control people have is hiding a page. A hidden page stays hidden, also when someone wants it once in a while, so hiding makes navigation harder.

Settings has become the place where a long list of pages ends up, and many of them are not settings. Devices, automations, scenes and scripts are what people use to run their home, and they sit next to network and backup configuration. People expect daily-use pages outside a space they associate with configuration. This is the navigation part of the "Invisible system" problem in #129, and it serves #7 Make Home Assistant More Approachable, whose stretch goal asks for common tasks to be discoverable without deep technical knowledge.

Community signals

  • Community forum thread on automations sitting under Settings, as summarised in #129 A five-year user says finding critical automation pieces takes more than two to three clicks. Thread
  • ux-design Discussion #66, bookmark bar concept (Jul 20, 2026): a collaborator and a maintainer respond positively to pins plus a full menu. The maintainer asks how hide/show in the profile and guest access work next to it.
  • ux-design Discussion #69, pins and Library (Sep 4, 2026): four reactions and one comment, from a user who accepts the change if a preset matches the current layout. The author's request for details has no reply yet.

Scope & Boundaries

In scope

  • A rail of pins on desktop and a bottom bar on mobile, with every other page one tap away in a Library
  • A Library that groups every page by what it is to a person, with a needs-attention band for discovered devices, maintenance and notifications
  • Ten pages leaving Settings, among them devices, automations, scenes and scripts, so Settings holds rarely-needed technical setup only
  • Arranging pins from the Library, replacing the separate manage dialog
  • Overview staying the page people open into
  • Rollout through Labs, opt-in, before it becomes the default

Not in scope

  • Reshaping the content of the device page, which sits in #130. This opportunity changes where the page lives.
  • Resident permissions, search exposure and privacy of shared data, the other two problems in #129
  • Visual design, which the current design review leaves out
  • Zones into Map, store and blueprints into HACS, and merging search and assist. These wait on the vector map, HACS and the search and assist concept.

Foreseen solution

People pin the pages they use to a rail on desktop or a bottom bar on mobile. Every other page sits in the Library, grouped as needs attention, dashboards, your home, automate, plans, records, extend and system. The groups are fixed from the first stage and fill as pages move. Overview stays the landing page, and the Library is for getting around and tending the system. Settings keeps rarely-needed technical setup, so devices, automations, scenes and scripts move out and integrations stay. Pages with sub-pages keep their own sub-navigation.

The new navigation arrives in Labs first, with pages where they are (stage 1). Then ten pages move and the preview graduates (stage 2), and pins get arranged from the Library (stage 3). Stages 4 to 6 land when the projects they wait on land. Prototype.

Risks & open questions

  • Stage 2 moves Devices to the top level while Focus on device page as first area of UI improvements #130 reshapes the device page. Which goes first?
  • Does the Settings line hold? Is "rarely-needed technical setup, everything else out" right, with devices out and integrations in?
  • When does Labs open, at stage 1 before pages move or later? Does a preset matching today's layout stay once this becomes the default?
  • How do hide/show pages in the profile and guest access work next to pins?
  • Does a bottom bar without a hamburger hold for deep sub-pages and for kiosk or other immersive use?
  • The evidence is two design discussions and one forum thread. No user testing of the prototype is cited.

Appetite

No response

Execution issues

No response

Decision log

Date Decision Outcome

Metadata

Metadata

Labels

No labels
No labels

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions