Dashboard chapter 2: Let’s redesign the cards together!

We have been steadily shipping updates to our new dashboard design every month since we announced Project Grace, and our new grid system is finally maturing to a point where we would like our community of contributors to get involved!

If you are a UX/UI designer or a custom card developer who would like to contribute to the Home Assistant project, sign up to be part of our dashboard working group and read more about what you can do to improve compatibility of your custom cards.

What’s new since the last chapter?

Thanks to your feedback, we continued to build upon the grid system and the sections layout with features such as:

Check out the corresponding blogs for more details.

New badges!

In the upcoming 2024.8, we are introducing our redesigned badges.

The original badges was created as far back as version 0.7 in August 2015, and its design has not changed much since. Designed to sit at the top of a dashboard view, badges provide a summary of the most important information that you need to know, at a glance.

According to our case studies of dashboards created by our users, we found that these badges are underused, mainly due to its outmoded appearance, bulky size, and the lack of configurable options from the UI. Instead, we found that many users are using Mushroom Chip cards, created by @piitaya who also works at Nabu Casa, for similar purposes. Therefore, we decided to redesign our badges to match the design of the Mushroom Chip cards.

The new badges feature a wide range of configurable options from the UI. For each individual badge, you can now specify whether the icon, name, and/or state will be visible, and you can configure the contents within each of these components: States can include multiple attributes to be displayed, and icons can be replaced with the entity picture for a person’s avatar or a media_player’s record cover.

Visibility options are also available for the new badges, which allow you to show or hide them based on who is viewing the dashboard, what screen size it is displayed within, whether an entity is in a certain state, and more.

Badges can be easily reordered with drag-and-drop, and they also come with copy, paste, and duplicate features that cards in the new sections view have. Last but not least, the new badges work across both the new sections view and the old masonry view.

Notes for card developers

On a default installation, we offer one built-in badge, the entity badge. However, you are not limited to that, as you can build and use your own! Defining a badge is done in a very similar way to defining a custom card. For more information, check out our developer documentations.

We would love to see your new creations - perhaps a small sparkline graph, or how about a mini progress bar? What do users want to quickly find out on a dashboard at a glance, and what can you display in this small amount of space to get the message across? Let your creativity go wild!

What’s next for Dashboards?

As the new sections view matures in its featureset, we want to begin our focus on a bigger task: to revamp all the dashboard cards and bring them up to modern standards. To achieve this, we need you - the power of our contributor community!

How can we achieve this?

Once upon a time (I mean, Summer of 2018), a group of developers came together to create the Lovelace dashboard. It was built organically - developers contributed where they see a need, either for replicating a feature from the previous States UI, or for adding something that they use personally. While the cards that come with Lovelace are adequate, the usability and aesthetics left much to be improved. In order to raise the bar in our design standards, we need more design-minded contributors.

Enter (semi) open-source design.

Traditionally, open-source projects are built around code repositories such as GitHub. This allows easy submission of contributions by anyone who can code. We figured that we may be able to achieve the same for product direction and UX design, too.

However, it is not easy to start with a blank canvas, and designers and developers have different workflows. Therefore, as the maintainers of the Home Assistant project, we are providing the product goals, the base design framework, and the process to facilitate collaboration.

Product goals: What do we want to achieve?

The goal of Project Grace is to make customization and organization of dashboards easy and intuitive for all users in a household. Dashboards are created to help users monitor and control smart homes, and as cards are the building blocks of dashboards, by extension, cards should also achieve the same product goals:

  • Monitor: Allow users to monitor the states of the device and service entities, with data visualizations that are easy and quick to understand.
  • Control: Allow users to control the devices in their smart homes, mainly with touch screens, and on the desktop with a mouse occasionally.

To bring them up to modern standards, we want you to join us to:

  • Revamp existing cards to fit the new grid system. This will achieve the modularity and ease of customization we are looking to achieve with the sections view.
  • Standardize the design system. The new cards should adhere to the same design tokens for typography, iconography, shapes, dimensions, and more.
  • Create new cards. This will fill the current feature gaps that we have not addressed.
  • Extend existing cards with card features. Card features allow every card to be more modular and be always up-to-date.
  • Incorporate existing popular cards on HACS. This will reduce the need to install custom cards and also bring them up to the UX standards of the Home Assistant frontend.

[table of cards to be revamped]

Design framework: What will our card designs be based upon?

The grid system

The new cards will be based on the design grid system as defined previously, finalized with a few tweaks for better information density and aesthetics. We have reduced the height of each row on the grid to eliminate the empty space between the card contents and card features:

The finalized grid dimensions are as follows:

  • Row height: 66px → 56px
  • Gutter: 8px
  • Icon size: 40px → 36px
  • Feature height : 40px → 42px

Design guidelines

We have also researched on the design of the Tile card, and here are some of the guidelines we have deduced from the research:

  • Each card used for controls should have a clear primary action.
  • Affordance: Everything that is designed to invite users to interact with should look clickable.
  • Features get better results than icon buttons.
  • Don’t clutter up the card.

As for the rest of the design system, we have been gradually moving towards Material 3 for the past year, but we have yet to finalize and adapt it fully on our frontend. We would like to hear your input on how we can bring it to our cards.

Process: How can we work together?

Since open-source design is not attempted often, there are not a lot of precedents we can refer to. We are experimenting with our process and will tweak it as we learn more. For now, we come up with the following process:

  1. Working group, assemble! If you are an UX designer, product person, or a frontend developer, you are welcomed to sign up to be part of the dashboard working group! We pick based on experience in dashboard and card design and development.
  2. Meet and greet. We will organize introduction workshops where everyone comes together to learn about what we can offer and define our project goals.
  3. Start small. We will parcel out each individual card as a project. We will start with the easier cards first. Every working group member can work on as many cards as they like.
  4. Research and design. We will quickly research, ideate, prototype, and validate our designs together, and share our designs and work-in-progress live on Figma.
  5. Let’s build it! We will clean up and finalize our designs, develop the cards, and launch the new cards with the next HA release!

Action items: What can you do as a custom card developer now?

If you have already created some custom cards, this is a great time to start upgrading your work to the next level!

1. Fit your custom card into grid system

In order for your custom card to work well with the sections view, you need to specify the default, minimum, and maximum width and height of your card:

  • Default width and height is the size of the card when it is first added to the dashboard.
  • Minimum width and height is the size of the card when its content cannot shrink further in size to adapt to and be usable with the provided area.
  • Maximum width and height is the size of the card when its content cannot expand further in size to adapt to and be usable with the provided area.

Our grid system has a fixed row height, which means that you can estimate how many rows your card will need by dividing the height of your card by the sum of the row height and the gutter.

For more information on how you can implement the card resizing logic, check out our developer documentation.

2. Follow usability guidelines from our user research

Audit the usability of your custom card with the guidelines as mentioned above.

3. Create new card features

Card features are widgets that can be placed inside cards for displaying or controlling an attribute of the entity. By building custom card features, you can expand the abilities of many cards that support card features. You can also allow your custom card to use card features, similar to what we had done to the [Thermostat card].

4. Ensure features are editable in UI

The inclusion of a visual editor is key to the ease of use of your custom cards, allowing more people to be able to edit and use them on their dashboards. Be sure to include only the necessary options in the visual editor, while also hide away the less used options in YAML or in an accordion UI to avoid clutter.

That’s all from us this time! To learn more about the UX research and design thinking behind the dashboard, be sure to check out our Dashboard Chapter 2 live stream!


This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2024/07/26/dashboard-chapter-2
20 Likes

Please for the love of all that’s holy don’t decide to “help” users by changing all of their existing cards. In fact it would be better if you left everyone’s existing cards, and layouts exactly as they were, and make it so the only way you can get the new cards is to explicitly, purposefully, and intentionally put them there.

It’s an extremely frustrating and aggravating experience when some developer thinks they are making your life “better” by forcing a UI/UX change on you.

11 Likes

This is great news, Im really looking forward to this!

I’m not a UX/UI designer but if there is any way regular users can provide feedback and contribute to this that would be great.

5 Likes

I think that the new “badges” are quite confusing… When I think of badges I think of a counter which displayes the number of new updates in the upper right corner of the entity icon, or displays some additional information on the entity card, or entity icon itself, but not a way to display a mini entity card (chip card?), how it is used right now…

It is so commonly used on the Apple and Android eco-systems that I feel the naming of “badges” feels really wrong in the subject of how this is used in the upcoming home assistant release.

Is this only me?

7 Likes

They already had the name before: Badges

1 Like

Not sure where to report, but at the end of the “PRODUCT GOALS: WHAT DO WE WANT TO ACHIEVE?” section it says “[table of cards to be revamped]”

image

I assume that should have been an actual table?

Das anyone now if there is a migration plant?

These new badges wouldn’t work for me.

I use them because they’re horizontally dense and works nicely on mobile too. I limit them to one row (i.e. 6 badges).

With text to the right of an icon, but no option for text below an icon instead, this will not work for me.

Rather call this something new. It resembles pills, which is a common UI element nowadays. These are just pills used in a specific way.



11 Likes

Do all of the changes mean that the existing cards are being removed or will all existing cards/lovelace functionality still work as they do now?

I am awaiting a header row that permits me to have a header that is the width of my screen, then the number of columns i want below that. I like to have a markdown header that is the same on all my dashboards then each of the dashboards have specified cards under the header. Is a full width header in the works?

6 Likes

I’m excited to play with the new badges, but the main reason I haven’t used the old ones is that they are always centered. I’d love to have an option to align them left or right, maybe even depending on screen size (centered badges on a big screen are just weird in my opinion).

1 Like

Wow, love the depth of the study here, and the way Madelena and the Frontend team are approaching this. Compliments to you all.

I will certainly keep ‘experimenting’ with all you throw at us!

Having said that please allow me below observations

+1 to that

using the current badges as Pieter does, and having experimented with the ‘chips’ as we have them now, I can’t say I am 100% happy the latter are going to replace the former.

Please just introduce a new item/card, and at least for the time being keep the current badges. Aware it is not ‘hip’ to say we like them, but hey, it’s all about choice isnt it?

Even though I really really like what I see when you demonstrate the creation of these new chips in the UI, my main objective isn’t the creation itself, but the end result in the Dashboard :wink:

Just as we wont be using Tiles all over, and a pure entities card is still a very vital part of the Dashboards, (if only because of the density we have there), the new ‘chips’ wont be the 1 panacee to all for the smaller floating details outside a card.

Which reminds me:

please allow the new chips throughout the dashboard, not only atop of the view, or in the new sections (not sure if this the case, but, just in case…)
While core badges are only available atop the view, Thomas Loven’s Badge card allows us to use them all over.
That would be a great way to make new chips available at introduction.

Also, the main icon on these tiles are going to be smaller, which to my eyes is a bit of a let down, I feel they will be unbalanced because of that. It would be great if we could size them like we want, using a main theme variable.


In all honesty, I wont be using much of these new options, moving sections around, or using tiles all over. Use sections at all probably, because: why?

So probably won’t benefit from these generic evolutions a lot. On the contrary I fear, as they take away several essential things I used to build my Interface, and that’s why I do hope these upcoming changes also help people with evolved UI’s remain as they like them/configured them carefully over the years… (or allow fixing them with a few tiny theme variables…)


Afterthought
If you ask us what custom cards would you like to see incorporated in core, for me, 2 things come to mind prominently, that seem to be very much related to current development on views and visibility:

custom: layout-card
and allow us to set max columns on regular views. I’ve asked elsewhere, as simple as can be, use a regular masonry view with 1 column all over… I need a custom card for that currently.

custom: state-switch
and allow us to set an ‘if’ option below the conditionals. currently, we need to configure a card twice if we want to show depending on different states. Adding a ‘default’ option to visibility would be awesome.

Thanks!

6 Likes

This is really great news! As a user concerned about security, installing HACS modules is a no-go… but unfortunately, this is hurting a bit in terms of UI. Having new, modern cards with all the good stuff that you see around in external modules is certainly helping a lot!!

When the alternative is either old cards or untrusted HACS, they are helping users indeed, sorry!

2 Likes

I strongly disagree with this approach. It’s impossible to improve the interface design if we would to keep everything untouched. And the older cards desperately need improvements. If you duplicated all the cards and had old and he versions at the same time, it would be a huge mess and very confusing for new users.

11 Likes

Overall I have to say I really like the plans shown here and I hope it will work out. I think this is one aspect of HA that is in the most need of improving and I can’t wait to see what will come out of it.

3 Likes

This may be more “Section” related than “Card” related or it could be a little of both.
But while you are re-designing any chance that we could have a card or cards that would span 2 or more sections? I currently have the need to display information that does not fit in a single column.

2 Likes

+1 for that.

3 Likes

I’d love to be able to groups multiple tile cards together and have a condition on the group. Currently I have a few devices that each have their own panel. If the device is off, there’s one tile available to turn the device on. If it’s on, a dozen tiles appear with various sensors. Now I have to repeat the hide-if-off condition for every tile.

This sounds really good. I’m slowly moving away from custom cards and using tile cards literally for everything. I’m not a developer, but like others have said I would love to help

2 Likes