Pins and Library, a staged navigation migration

[matthiasdebaat]

Problem statement

Home Assistant has many pages, and the sidebar shows them all. The only lever we give people is hiding a page, which hides it for good, even when you want it once in a while, and it makes navigation harder.

Settings has also become a catch-all. It is where a long list of pages ends up, and a lot of them are not settings. A setting is rarely-needed technical configuration, the things you set once and forget, like your network or your backups. Your devices and your automations are not that. They are what you use to run your home, but today they sit in Settings anyway.

Design

This is the next iteration from the favorites bar ideation, worked out into how we actually get there, staged so no one loses their pages along the way.
This round is a design review, not ideation. The ask is to pressure-test the structure. Visual design is out of scope for now.

We will introduce this as a Labs feature first, so people can opt in and try it before it becomes the default.

CleanShot.2026-09-04.at.13.16.19.mp4

CleanShot.2026-09-04.at.13.19.09.mp4

Prototype: https://ux-design-concepts.openhomefoundation.org/ha-pins-and-library-migration/
Tip: use the dropdown in the bottom right of the mockup to switch between stages.

What it is

• A rail of pins on desktop, a bottom bar on mobile. You pin the pages you use, the rest live one tap away.
• A Library, the page behind the "..." that holds everything, grouped, with a needs-attention band on top for devices discovered, maintenance and notifications.
• Overview stays the page you open into, for control and insight. The Library never becomes the landing, it is for getting around and tending the system.
• Search and assist stay modals, pinned at the top, merging into one later. That merge waits on the search and assist concept.

What moves, and why

• Settings becomes the rarely-needed technical setup, like a computer's system settings. Anything you use to live in or run your home moves out.
• For example, Devices moves out, it is about your home, with an edit-the-device action later. Integrations stays, it is the technical setup that makes devices work.
• Automations, scenes and scripts move out too.

The stages

1. New navigation. Rail, Library and a mobile bottom bar arrive in Labs. Pages stay where they are.
2. Pages move. Ten pages leave Settings for the top level, and Settings flattens to the rarely-needed technical setup. The preview graduates.
3. Manage from the Library. Arranging the Library sets your pins, the separate manage dialog goes, and notifications converge into the attention band.
4. Zones into Map. Zones leave Settings for the map. Waits on the vector map.
5. Store and blueprints into HACS. Waits on HACS.
6. Search and assist merge. The two pinned entries at the top of the rail become one. Waits on the search and assist concept.

Stages 4 to 6 wait on other projects and can land in any order.

The Library grouping

Grouped by what each thing is to a person, not by object type. The grouping is fixed from the first stage, the groups just fill as pages move.

• Needs attention: what wants a decision or action now, so you act instead of hunt. Devices discovered, maintenance, notifications.
• Dashboards: the views you open to see and run your home.
• Your home: the people, devices and things in it, and how you reach them, not their technical setup.
• Automate: what makes your home act on its own.
• Plans: your upcoming things, about you rather than the system.
• Records: the system's account of what happened.
• Extend: getting more and running extras beyond the core.
• System: the rarely-needed technical setup, deliberately last.

A visual decision I already made

One visual choice shapes the review, so I am noting it. The rail moves to the background and the page content comes forward. The chrome shares one background with no dividers, and pages get a big title that collapses on scroll. The rail should get less attention, the content more.

Sub-navigation stays

Pages with sub-pages, like Settings and Developer tools, keep their own sub-navigation, a submenu on the left on desktop and a stepper on mobile. That pattern stays through the end vision.

Related

The favorites bar concept this iterates on, the vector map that zones move into, and the household concept it sits under.

Open questions for the review

• Does the Settings split hold? Is "rarely-needed technical setup, everything else out" the right line, and are Devices out and Integrations stays the right calls? Any page you would move differently?
• Can you predict where a page lives from the groups? Any page in the wrong group, or a label that does not read right?
• Is the Overview and Library split clear? Overview as the home you open into, the Library as navigation plus what needs tending. Is keeping Overview as the landing the right call?
• Does the staging make sense? New navigation in Labs, then pages move, then manage from the Library, with the map, HACS and the search and assist merge gated on other work.
• At which stage should we open this to Labs? The plan turns it on at stage 1, before pages move. Is that right, or should Labs wait until there is more to curate?
• On mobile: a bottom bar with no hamburger, notifications on the Library, a clean topbar. Does this hold for deep sub-pages and for immersive or kiosk use?

Have a look at the mockup and drop your thoughts.

[n8ohu]

If you add User Interfaces presets that include one that is functionally identical to the current UI layout, the change wouldn't bother me.

[matthiasdebaat]

Can you elaborate on what you need in your setup?

[n8ohu]

I would like to have a user experience after this change that is essentially identical to the one I have now. I initially adopted Home Assistant because it did not look or work like Google Home or Apple Home. My dashboards are built around information display rather than being a way to turn lights on and off or change the temperature on my HVAC system. I understand that you want to make HA more usable and user-friendly for newer users that are coming from other platforms that are more hands on, but it shouldn't be done to the exclusion of users that might prefer to use it another way. My hope is that this can be done and be done in such way that I can make the UI on mobile and desktop consistent, rather than having to hunt for the UI elements to do everything each time I go from one to the other.

[matthiasdebaat]

What changes in this design doesn't work in your setup?

[n8ohu]

It's not a "works or doesn't work in my setup" question. It's a matter of having a Library of sorts already that has everything in one place that I'd like to keep, instead of moving things around. I understand that this is a companion to other changes, namely giving more access to traditionally maintainer controlled settings to end users (well, it's the actual implementation of that), but as another commenter said, there are people other than me that don't want it to change for them and the ability to use presets to get the old style settings page that I suggested would help with it.

[n8ohu]

A point of clarification: I'm aware that everything that was in the old Settings location is still there in the new Library. My main complaint is that the change doesn't reflect how I use Home Assistant and the change will make it more difficult to use, at least for me. The same is true about the bottom bar in the mobile view; it will break my workflow because I expect visual consistency between the Desktop Browse view and the Mobile App view. I don't like having totally different user experiences when using one method or the other. I'm not yet sure how I feel about the change to Notifications and Assist; those may work fine. The one change that I do like is the one that puts the zone editing on the same page as the map; that works very well for me.

[bgoncal]

I love the direction where it is going on mobile side, I think we are close to agreeing on something to be implemented.

Question... what the user sees when tapping the profile picture? Same as they see nowadays? We could combine into a menu "Edit profile", "Settings", and then when settings is selected we open a full screen of configurations items, no dashboards, just config.

[matthiasdebaat]

Good call out. I see a lot of opportunities to improve the Profile / Account page. Yet it deservers its own separate project, like Zones into Map, Store and blueprints into HACS, and Search and assist merge.

In the favorites bar ideation I had this.

CleanShot.2026-09-07.at.13.11.56.mp4

[bramkragten]

https://ux-design-concepts.openhomefoundation.org/ha-pins-and-library-migration/#/my/profile

[matthiasdebaat]

ux-design-concepts.openhomefoundation.org/ha-pins-and-library-migration#/my/profile

Hahaha nice, you found the secret link 😊
Note that it has way more content than fits the scope of this discussion.

[mkerstner]

I too like it!

For the mobile view:

I'd argue that there is too much whitespace before scrolling at the top.
Looks much more condensed once it's in scrolling mode - while still offering access to the profile and further options in the 3-dots-menu

vs.

[matthiasdebaat]

I'd argue that there is too much whitespace before scrolling at the top. Looks much more condensed once it's in scrolling mode - while still offering access to the profile and further options in the 3-dots-menu

Thanks, good to have this challenged.

I have used the common patterns Android and iOS use. I have picked this to make it calm. The moment you scroll it collapses to the condensed version you like.

It is a visual design choice, so curious what @mbb365 thinks.

[mbb365]

I don't think the space here is an issue. As MdB says, the " The moment you scroll it collapses to the condensed version you like." if it stayed as a large header when scrolling effectively taking half the page then that would be an issue.

As for visual design - it creates space (calm), confirmation on the location, affirming the users correct navigation (or incorrect), and (when used across area pages, overview pages.... any pages..) consistency.

[mkerstner]

Yeah, I saw the scrolling and minimization of the header thereafter. Just felt a bit of a lost space when looking at it for the first time :)

[timmo001]

Agree on the previous comments, these are prototype examples, but I'd try not to lose too much space, especially if wanting to manage navigation on mobile.

I'd also say that pins could also be managed on the tiles.

The overflow would be a pin in this case, matching existing patterns for cards/badges, hovering a tile would allow to pin/unpin instead of a dialog (or additional to)

[matthiasdebaat]

try not to lose too much space, especially if wanting to manage navigation on mobile.

See my reply here: #69 (reply in thread)

The overflow would be a pin in this case, matching existing patterns for cards/badges, hovering a tile would allow to pin/unpin instead of a dialog (or additional to)

Good idea. Will work on a design.

[marcinbauer-ohf]

I appreciate that you've separated the implementation to stages @matthiasdebaat 💯

Some things that I've noticed:

1. While centering the favorites items on desktop looks nice, it creates three areas of interaction. In a case where a user would have a minimal amount of favorites, this space looks a bit off.

• If we account for future merging of Search and Ask (Stage 6), and the HA logo serving as a way to go to the default set dashboard, I think there are more usability benefits to have those two sections closer, rather than farther apart. On the other side if the user would have more than the space that is available, the items should align to the top (start at the top). This I think makes it a strong case to start with aligment at the top always.

2. In "All pages" I wouldn't think to find things like: Needs attention. Shouldn't this be more in Settings?
3. On mobile I always see my avatar up top, although I'm not sure if that touchpoint needs it's own place on mobile and desktop. If I navigate to a view where we need to render something else up top, I won't be able to access my "Profile" since it won't be there.
   Have you tried to merge the two into a Settings/Profile item, and have the Profile touchpoint a link on that view? Similarly like Apple does on MacOS with Settings -> Apple ID, and place it always at the end on mobile.
4. On desktop and mobile I'm able to remove (drag-out) settings. I think I shouldn't be able to do that?
5. Showing items from `All pages' in a grid on mobile requires a Z reading pattern, instead of an "F" one which is faster to skip and scroll vertically since scrolling is cheap on mobile.

[matthiasdebaat]

Thanks, good to challenge. Going through them:

1. The rail has three bands on purpose: search and assist at the top, your pins in the middle, your account at the bottom. I want those three to read as three separate things. I do think the near-empty example is more of an edge case. The default have more than a couple of pins, and my hunch is most people will want more than two, so you would mostly get there by choosing to remove them. If search and assist move to the topbar later, the pins can move up.
2. Needs attention is what you should see and act on, repairs, updates, discovered devices. That is the opposite of Settings, which becomes the rarely-needed technical setup, like a computer's system settings. So it lives on the Library, the hub, not buried in Settings. More on that in What moves, and why.
3. I would not merge the account into Settings. The account is becoming more personal and important, while Settings becomes less important. Merging them pulls in the wrong direction.
4. Settings is a pin like any other, so you can pin or unpin it. Unpinning does not hide it, it still lives in the Library under System. With Settings becoming less important, I can see a future where it is not a default pin.
5. Good point on the reading pattern. Will experiment with a list versus a grid on mobile.

[pcan08]

Here my contribution,

First, I think it sounds good 👍

A few questions and comments:

• Where are Entities and Helpers pages ? especially Helpers (I guess entities can be reached from device), maybe we could have a dedicated page at the same level as the "Devices" page showing both Entities and Helpers (in the end, helpers are entities). Also, Helpers are entities you create, as you create an automation or a dashboard, so it could be treat in consequences.
• Does the "Devices" page also hold "Services" ? (devices and services are the same kind/level of item in the sense they both hold entities), If yes, is "Devices" the right word to use ?
• Are they only Apps in the "Extend" section of "All pages" ? if yes, I propose to keep only one of App or extension/extend
• What is "YAML" under "Settings" ?

About the questions you ask to reviewers, here my opinion and ideas

Does the Settings split hold?

For what I see yes, except for Integration/Devices.
In one hand, having a access to the Devices page from all pages/favorites is good, in the other hand remove it from settings is weird because you go tho the device page to reach a device and/or its entities most of the time to configure it -> the purpose is settings
I think some debates are coming about this :)

Can you predict where a page lives from the groups? Any page in the wrong group, or a label that does not read right?

Yes except the "Automate" section in "All pages" that, IMO could be an item of "Your home" (so a page) with subnav like Settings and Tools.

For labels see previous comments about devices/services

Is the Overview and Library split clear?

I guess yes

Is keeping Overview as the landing the right call?

By default, why not, and because it still be changed in user preferences as currently I think it is fine.

Does the staging make sense?

From a developer point of view I think this is a good choice to split into steps.
This also allows feedback step by step and maybe to react/update route in consequences as soon as possible on a reduce scope at each step.
But in the other hand, open to labs at step 3

Also, looking closer to the difference between step 2 and 3 give me an idea: why not keep the alerting of step 2 in favor of a "Needs attention" page ? I talk about this:

[matthiasdebaat]

Great questions, thanks. Going through them.

• Entities and helpers live under Devices for now. Helpers are entities you make yourself, so a dedicated view is worth exploring. I had a concept that merged the Developer tools states page with the Entities page, which points in that direction.
• Devices does not hold integrations. Integrations are the technical setup that makes devices work, so they stay in Settings. That is also why it is called Devices and not Devices and services. On the word services, I would rather keep that for specific service pages we could add later, like Commute and Waste, not for integrations.
• Extend and Apps. Fair, and I have had similar feedback elsewhere. The group holds HACS and the add-ons, with Apps sitting inside it, which doubles up. I will look at this grouping again.
• YAML is the advanced configuration page, reload and check config, with the YAML tab from Developer tools and the entity ID format folded in. Open to a better name.

On the review questions:

• My take on Settings split and Devices: configuring a device, its name, area and controls, is about your home, so Devices moves out. Adding or removing the integration that powers it is the technical part, so Integrations stays in Settings. You go to Devices to use your home, to Integrations to wire it up.
• Automate under Your home. Here I see it differently. Your home is the things and people in it, devices, media, people. Automations, scenes and scripts are not things in your home, they are the behaviour you build on top, which is a different job, so they earn their own group.
• Notifications in Needs attention. I folded notifications into the band because today's notifications are mostly things that need attention. I do not have a strong opinion on keeping them separate. What I am sure of is that the current notifications either need to slim down or grow into a real notifications center. For the scope here I went with slimming down. A dedicated Needs attention page is a fine option for the expanded view, will keep it in mind.

[pcan08]

Thanks for your reply,

Devices does not hold integrations

I think there is a misunderstanding about "Services" here because you interpret it as "Integration". I don't talk about Integration, but Services provided by some integrations, as integrations provide devices.

Example of Services and Devices in the current integration page:

In this example the Open Meteo integration provides a service having an entity and MusicCast integration provides here 5 devices, each having some entities.

Then Services and Devices are both listed in the Devices page/table:

[matthiasdebaat]

Note this is an older sandboxed design with future ideas.

CleanShot.2026-09-09.at.15.49.11.mp4

This is what I have in mind for Service like pages, to split them to specific service domain pages. For example, Weather, Commute, and Waste. Open-Meteo would be an integration for the Weather page. And you can use the entities of this integration to build your own dashboards and automations.

[teskanoo]

I had a concept that merged the Developer tools states page with the Entities page, which points in that direction.

Please do not merge these, they have distinct and separate purpose. They convey similar data but functionality differs.

States is the only place where we can wildcard filter related entities and monitor raw state and attributes of more than one entity at the same time. It is a development tool. Merging will likely remove that functionality.

Additionally, splitting up YAML from developer tools breaks dev workflow from single tabbed interface to multiple browser tabs. I cannot see that going down well.

[matthiasdebaat]

Please do not merge these, they have distinct and separate purpose. They convey similar data but functionality differs.

States is the only place where we can wildcard filter related entities and monitor raw state and attributes of more than one entity at the same time. It is a development tool. Merging will likely remove that functionality.

Merging this is just a wild idea for now, and is not in scope of this design. Will reflect this better in this design.

Just to make clear: I don't want to remove functionality but order the pages and functionality. I see overlap in the Entities table and States table, and I think this could be one. Will start a separate design discussion for this.

Additionally, splitting up YAML from developer tools breaks dev workflow from single tabbed interface to multiple browser tabs. I cannot see that going down well.

Same for this one. YAML is an important page.

To not scope creep this design, I will keep it as is, and start a new discussion with the reasoning what my thinking is

[pcan08]

Also, IMO the "Manage pins" shortcut in "All pages" feels far from the pins themselves . It could be closer, but I don't have any ideas to share about this.

[matthiasdebaat]

Agreed. @timmo001 had the same feedback. Will work on a design.

[HACS-bank]

1. The chat in the Forum gets dominated by people who want to keep it the same (no change) so I guess it is important to enable them, e.g. by publishing how they can add things back to the sidebar. Personally I get used to change 😀 but I think it is worth considering ... and note that they are all admin users.

2. Does this reorganisation have any implications for the work to separate out admin use from day to day? E.g. should any elements get controls to become admin-only or to give the home manager choices about hiding from users?

3. A downside to being an admin user is that you forget what non-admins can see. This might be an opportunity to give admin users the same UX as non admins, and an easy way to "take control" and reveal the admin functions. This would need to be a setting which can be (for admins only) either 'always on' or 'admin on demand'

[matthiasdebaat]

1. Trying to get this validated in this discussion for the people that have their setup in a specific way. I think the flexibility this new pin structure gives, gives people more choice what they want to have in their rail. For example, people that want to have (Developer) Tools can pin it back.
2. This design doesn't touch the current roles and permissions. Maintainers have more admin pages, residents have less pages.
3. Agreed! I think you would be interested in this discussion: Home Assistant for the whole household #40

[n8ohu]

1: It's not that they don't want things to change, most likely. It's that they want to have a way to easily recreate the user experience they prefer if there is a change made, which they haven't had before. I'm still annoyed by the changes to dashboard elements that I have to manually switch from default option to something else that makes more sense for how I use them, for example. Another example is the change to how Integration installation ends. The old way let me easily move on to installing more that were detected or that I knew I wanted to install; the new way takes me straight to the integration's "dashboard", which means I have to go back a level or two to do anything more with the process of installing them.

2 and 3: It's already possible for them to have the same experience as a normal user by creating a normal user account for themselves, which is probably how I will do it when I redo my newer Home Assistant installation before I decommission my Home Assistant Yellow. That's not to say that I would oppose such a change as part of a different set of changes to Home Assistant, as it would be a valid option to provide for those who would like it.

[dhoeben]

I love this!! For the applications it would be lovely if the title would be passed on to globally, so that it can be used as "stock" title. Meaning, iOS using its style header and Android using theirs.

I love the floating design idea, it gives the focus to the content. Don't forget the styling variables to allow users to make it their own. Something that is still missing in current tile card.

[bgoncal]

For the mobile tab bar I created an opportunity to be worked on after the navigation style is decided, it aims to have the tab bar implemented on the native apps themselves, following the platforms specifics. OpenHomeFoundation/roadmap#244

[oerix]

@matthiasdebaat This looks and feels great, along with @bgoncal's native mobile nav bar. Will this be coming in the upcoming beta/release as a labs feature? Feel like the earlier the better, so we can provide you valuable feedback.