Favorites bar concept #66
Replies: 13 comments 71 replies
|
(about the mobile design) One tip, it's not very common to use hamburg menu icon on tab bars only as sidebar indicator. Perhaps we could use a "..." icon or the user picture instead, I'll browse other apps to collect more ideas |
Good call. Two things I want to try:
|
|
Scrolling through Mobbin right now I do see the hamburger menu pop up in the tab bar quite often actually, for what it's worth. Edit: there's also A LOT of "profile" buttons (with or without user avatars) in that spot, presumably opening up some sort of menu rather than immediately going to the user's profile. |
|
I like the distribution - I feel the hamburger menu for all the items (traditionally everything on Menu) and then the shortcuts exposed could be very benefitial and cover a lot of edge cases. One question - how do you envision this living with the "hide/show in profile" feature? There are some important cases where this is interesting - for example, guest access. They can always find the option to show again, but its not very public. I am aware this is not a problem this needs to solve, but right now we don't offer a healthy alternative, so just thinking. Maybe it makes total sense to just keep this functionality if this became a reality, and then remove it later on. Thinking too much as a PM here 🤣 |
|
Going into solution mode: we can keep that feature and keep it as today. In this concept that would mean you move the hamburger menu to the top left and hide everything else. We can show it on your profile as part of Appearance. Yet this is still a bit hidden. CleanShot.2026-07-21.at.11.48.49.mp4 |
|
yeah its a bit hidden... but not really a problem. |
|
I've updated the design and added the options |
|
I think this is great. Not sure I'd consider these bookmarks though. I've seen other apps that offered the same functionality but framed as customising the main navigation, not managing bookmarks. Worth a thought, but other than that, I love it. I fully support taking certain pages out of settings (automations being a big one, but I'm biased). Apart from how this sort of global navigation works I always thought our overall page structure had unnecessary nesting. |
I'm all up for better naming, in the manage bookmarks dialog I call it favorites. Maybe that is clear enough, I'm all ears for suggestions. Note that you add personal favorites / quick links / shortcuts to a smaller rail from the main navigation. You don't customize the main navigation. |
|
I think my personal opinion would be that framing it as navigation customisation would be the best, even though strictly speaking you're only customising part of it as we keep some elements stable (the parts you refer to as the main navigation). But there may be vastly better ideas! |
|
Changed it to favorites |
|
An idea.. |
|
I played with this, and removed it. For example on desktop it is confusing to have the "overall" search icon next to a search input that, I let, filter the menu items. The overall search is great in also searching pages. And want to guide users to this search more. |
Agreed, also from a AI perspective as we envision the search to be a nice starting point to ask your home to do something. |
|
It's a global search vs specific search situation. But I guess it's not important for now |
|
Kept the current hamburger on mobile as a slide in page in the latest iteration |
|
I like the idea that as a user I can add things that I couldn't have added before, some thoughts:
|
I like that, will add it to the list to explore.
It depends on the mental model I would say. I have experimented with a position below the favorites, or all the way at the bottom. All have their pros and cons. I placed it at the top right now, as this is where we have the current icon. I will experiment with it a bit, including the different icon.
Good point, will add it back. What would you do on mobile?
I think we should make settings less important by moving out things that are not settings, as I envision in the opening post. For example, automations and your devices. If we make it less important you don't need to visit it as often as today, and then it's up to a user to decide to make it a favorite page or not.
Non-admins don't have Settings if I'm correct? In this concept the page is also called the profile page My account, with a Language and region, and Appearance page like we have today. |
|
regarding the settings: even if it's filled with things that are not settings, it gives me a better mental map where these things are. right now the menu list in the prototype feels too long for me and I personally have a harder time finding things in a long list, than in a tree navigation with shorter lists. |
|
You're right on that, at least for today. We can't be certain what could a non-admin get in the future. |
Yes, I think we can make a better organization with different layers. I would argue that have everything in a top level "settings" menu is incorrect. We would find it weird if you would need to go to settings on your phone or laptop to do everyday tasks. This concept would be stronger with this better organization, and maybe find a way to condense the long list. |
What if there was a button in the lower left or right that expanded to the opposite side. The button would always be on top of everything. When the button expands, it provides the menu shown in the mobile mock up. This would give the mobile view the full page while providing easy access to the settings. |
For this one, we could make use of the existing adaptive [popover](https://github.com/home- For the bottom menu I would suggest setting a fixed amount of items, there is a defined standard right now of 4 tabs for bottom navigation, so the popover/sheet would be the 4th item if sticking to this standard (context). I've also had thoughts that this could be swipeable, but its probably less discoverable this way I'm all for flattening the panels and reducing nesting. The favorites/bookmarks more items popover/sheet/panel could use a search as previously stated, but I think we should use the quick search as the base for all as it already has this kind of navigation in place already. The favorites/bookmarks menu could reuse the logic bts on this (solutionizing a bit here) In general I'd also be a fan of bringing UI from the top app bar into a bottom bar, or just away from the top of the screen which is always hard to reach on modern mobile devices (especially tablets). How far this scope goes though is another thing and possibly unrelated. In a future epic, I'd suggest making this a labs feature so we can iterate the UI more gradually, as this is a big feature even at its base and we might want to make breaking changes as we go to storage etc. |
Ah yes. The current tabs in settings are.. unique. In this concept I dropped this pattern and went for the usual pattern. It was limiting the number of things we could group. And having a different tabbar per page is not a best practice.
Yes, lets design for every screen. Yet I wonder if we should show the left rail in that case? |
|
Yes, a foldable in a landscape is more of a small tablet experience than a phone in portrait. |
I do agree that Quick search should be a primary way of accessing every navigation item that is not "bookmarked" in the sidebar. This is kinda the current situation, and there are users already using it. Introducing another list of navigation items would be duplicating functionality. @matthiasdebaat you mentioned the HACS example, and you can go to it quite easliy with quick search. If the issue is discoverability, we could make the Search a centerpiece field in the app bar on desktop, which is pretty empty right now. This is also aligned with trends in UI of interacting with products via a "box". MacOS has greatly improved Spotlight as a means to do stuff, and to navigate. Raycast has great success in this also, and this UI pattern opens a lot more opportunities than a single-purpose flyout menu. |
|
I really like your idea! I have not touched search and assist in this concept, as I knew you were working on some good stuff. I think this could work great together. Personally I use Spotlight a lot for navigating. There is also a type of user that doesn't think like that yet. As I see searching as something you learn over time. For example, you need to know that HACS exists before you think about searching it. And some prefer to just point and click for easy things. When it starts to get more complicated, for example needs a lot of clicks or a screen with a lot of content, then a conversational UI would be even better. So I would do both, search navigation and tap navigation. And think about conversational UI on top of that. |
|
Really like these concepts. A global search bar (triggered via cmd/ctrl+k) surfacing quick search (with improvements as it goes) is probably a good solution. Another side thought: We could combine assist into a global search too, if no match is found, the final option would be "ask assist X" and integrate that in more. I personally rarely use assist, this, combined with tool access in the backend (sure this has been talked about, giving assist more powers) would make the experience much nicer. I actually might make that action in quick search, its a pretty small simple one to add |
|
just an idea that i haven't really thought through: why confine this bookmark bar to only pages? it could be a shortcuts bar, mirroring all capabilities of a shortcut card. |
|
Yes, once we nail down the basics, we could expand it with adding anything you like. |
|
What kind of capabilities are you thinking of? |
|
i think i didn't see correctly in the video. i thought in the prototype you could only navigate to dashboards, but now i see you can also go to other pages, so it should already have all the capabilities of a shortcuts card. (strong indicator to me to align the name of both) |
|
Hi, I hope this isn't far out of scope, but since we are discussing UI/UX, I'd like to bring this proposal forward and highlight the ideas for the mobile header layout: https://github.com/orgs/home-assistant/discussions/192. It would be greatly appreciated, if these elements where taken into consideration with the new mobile concepts. |
|
Cool stuff. This concept is focusing on the generic navigation, the feature request is more about custom dashboard. Feel free to create your own UX design that include this feature request in a new discussion. |
|
There's actually two parts to this FR, the one under |
|
The concepts are great, however I'm not a fan of the "Middle of the bar" grouping in the desktop view. A minor gripe in an otherwise very nice proposal. |
I tried to make a clear separation between user space and instance space. When I move the favorites upwards it gets mixed, what I dislike as it gets confusing. |
|
I like the concept of a bookmark bar, though I would personally call it Favorites rather than bookmarks. However, I really do not like the idea of a large tab bar on the bottom taking up screen space on mobile. When using the app on a mobile device, screen space is limited and has high value. This remains true even on larger smartphones. The primary focus should be on interacting with the dashboard, not the navigation interface: We have actually seen this exact interface issue before in Home Assistant history. Years ago, the top header was unnecessarily large. This forced many users, including myself, to rely on community mods to shrink it. The community feedback was so overwhelming that the development team eventually integrated a native Compact Header directly into the frontend to give space back to the users: It is important to remember that the top bar is also used to move between views, so a large header severely impacted dashboard usability, because users want to see as many dashboard views as possible in the header, cluttering the screen space with a bulky navigation bar makes dashboard usability much worse. 
|
|
I assume users don't see the need in this. When the open the app on iOS or Android, they would have their familiar tabbar. When the open it on web, they would have the frontend tabbar.
In the latest prototype I tried to mimic this mixture and I don't see this as an issue right now. I was also thinking about trying out a native topbar, yet I feel that is out of scope for this concept.
When we think about building it, I agree. Right now we are still ideating on the tabbar and we shouldn't scope it down to much.
We already do this with the desktop toggle. I don't see the harm in giving users this choice on mobile too, with the note that it shouldn't break the design we aim for. |
|
@marcinbauer-ohf The idea was never to be native-only, we were just agreeing native would be a better experience then to mimic the native version. It's important to think about this from the beginning, so when we have a decision, frontend devs can build with this in mind, otherwise if they dont take this into consideration we may endup on a situation where code refactor is needed |
|
I may have missed a few messages, and it may have already been mentioned, but I do like the compromise most of my apps are taking when it comes to "Size of the bottom bar" vs "content" by making it either disappear or smaller when I start to interact with the content. ScreenRecording_07-27-2026.09-32-35_1.MP4 |
|
Both of your points addressed, you can open https://ux-design-concepts.openhomefoundation.org/favorites-bar/ on your phone to see this. |
|
I like the idea of this and think for mobile at least its long overdue. Hopefully customizable via theme variables since I prefer the floating nav-bar on mobile like IOS style but this is good still. I've been using nav-bar card for a while to basically give the same experience and it's very good on both desktop on mobile. 
|
|
Small update. I pushed a batch of changes based on your feedback.
Still open:
|
Why do we need to name "this" at all? Calling it Favorites might confuse with favorites in dashboards. We could just skip the name and be direct: "Manage"
What happens with access to this when I drill down to a sub-page and I see a "<- Back" button? This is maybe fine with 1 level, but a user can dive into much more and then we have the same issue we have today - there's no easy way to have access to the top-level navigation items (other the ones that fit in the bottom navigation).
|
Yes that could work too. I see it as similar pattern, different visualization. Maybe a bit harder to maintain in 3 different places, like frontend, iOS and Android. What do you think?
Good question. Its on the edge of the scope of this concept, but it is what we have today. I have moved the + as a FAB in the concept btw. I do find it weird to have Assist in the topbar as just an icon. I would rather have it as combination with search. |
|
@matthiasdebaat why do you think it would be difficult to maintain? You mean the animation? |
|
Just looking from a interaction pattern, in both mockups there is a button that opens a menu. Good to explore how we can visualize this the best. It feels the mock up you made is relying more on the native apps. I guess its a question how much scoping we want to have on this concept. |
Fair to challenge, I'm open for changing it. We can come far to just call it manage, yet not always. For example, how to call it on the user account page. Apple calls it items, on the Dock. And Windows calls it pinning applications on the taskbar. We often call the left rail, sidebar. Yet we have many sidebars, for example the right column on automations. I would like to find the best name for the concept, to have a shared language what this is. That can't be Dock, Taskbar or Sidebar in my opinion. Bookmark, Favorites and Shortcuts came across as candidates. What would you suggest? And should we name the thing on it?
On mobile I see two issues in the current application:
My proposal is to rework the hierarchy and move things out of Settings. The rough idea is to separate what you operate (automations, scripts, scenes, devices, dashboards) from what you configure once (network, storage, backups, users). That gives us:
|
|
Interesting. I don't know if the sidebar and favorite bar being 2 different concepts, that live next to one another and make the app content smaller, is what I had expected. One of your earlier mockups had the "..." as a more button at the bottom of the favorites, and then an overview page, that could show things in different ways. I think I liked that more. The overview page becomes like a "data of your smart home" launch pad, and managing how that page looks could also offer how favorites are managed. |
|
Went for this approach as I assumed it would be easier. Seeing the discussion above I think it makes sense to also ideate on this version. Currently on vacation, will do it in a couple of days. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
As discussed earlier in Discord, I want to open up a discussion about a "Favorites bar" concept. It iterates on the current menu bar and gives people more personalisation options.
Edit Wo 22 Jul: I pushed a batch of changes based on your feedback, see the summary.
The pain point
Right now we show all pages in the bar and let people hide the ones they are not interested in. The problem is that hiding a page makes it hidden for good, even when you might want to open it once in a while. There are also some exceptions to what shows up in the bar, like adding an app in the sidebar or adding a page through configuration.yaml.
A related pain point is that we simply have too many pages. Hiding pages is the current answer, but it makes navigation harder. Take HACS. You do not always need it, but sometimes you want to open it.
The concept
The favorites bar puts all pages in a menu and lets you decide what to favorite in the bar. So every person decides for themselves what they want quick access to. That includes apps, settings, and dashboards. It also means you can add developer tools back to your rail if you use them often.
This is not a new pattern. It looks a lot like the Windows taskbar and the Apple Dock.
Desktop vs mobile
On desktop the number of favorites is unlimited.
On mobile the bottom bar has 4 favorites plus Search, and it auto-hides on scroll. The menu moved to a top-left hamburger that reveals a left panel, like we have right now for the muscle memory.
A stronger version with a settings redesign
The concept gets more powerful if we also redesign the settings page. The idea is to move Devices and Automations out of Settings and let them each be their own "Page". This concept alreay did this, yet it would even be better if we do a bigger shuffle of features and pages.
Recordings and prototype
I have a screen recording for both desktop and mobile. They show the concept with a favorites rail that has personalised and focused menu pages, how to add favorites, and how to navigate with all pages.
CleanShot.2026-07-22.at.22.53.42.mp4
CleanShot.2026-07-22.at.22.55.07.mp4
Prototype: https://ux-design-concepts.openhomefoundation.org/favorites-bar/
A note on the visuals
I used a concept visual design here, because I got stuck in the current visual design.
There are more small decisions in this concept that I have not named.
Curious about your feedback!
All reactions