Mockup: Integrations page, tabular view

The new, card-based Integrations page is attractive but I find it’s not space-efficient and lacks management features (like filtering/sorting/grouping integrations). Personally, I prefer the tabular view used by Devices, Entities, and Areas.

I decided to create a mockup of a tabular version of the Integrations page (using a spreadsheet). It’s effectively the existing Entities view but with a few extra visual cues like manufacturer’s icons and row-colors to identify Discovered (blue) and Ignored (gray) integrations as well as integrations that require your attention (yellow). Credit goes to SeanM for the use of color.

It offers the same functionality as the Entities view:

  • sort by column heading
  • filter by text
  • cherry-pick specific integrations to Ignore them in bulk

I intend to submit it as a proposal in the Architecture frontend repo but, before I do that, I’d like the community’s feedback on what they wish to see in a tabular view.

In the view (above) the rows are sorted by the Status column which would be the default presentation.

7 Likes

Just needs an actions column for Configure / Remove

I envisioned it would work like the existing Devices page. Click the desired integration-row and a new “Info” page is displayed with all the relevant menu commands for the selected integration (Configure, Ignore, Rename, etc whatever is applicable).

The manufacturer’s logo (larger than the icons shown above) would be displayed on that page as well because there would be ample space for it.

2 Likes

I have no objections to offering this as a view option, but that initial mockup seems to be lacking some crucial functionality. Some feedback:

Which Plex Media Server has expired credentials? You cannot tell whom it belongs to, so you don’t know which credentials to enter. I know my “attention required” mockup had the exact same flaw, but that’s an example of what I meant when I said things still needed to be figured out. And how do you re-enter the Plex credentials anyway? There’s no button to do so.

And to continue with the Plex example, how do you rename the config entry? The default config entry name might be Synology 1019+, how do you rename that to Taras Plex Server. How do you access the System Options so you can disable new entities from being added? Most importantly, how do you access the integration options? Integration options are absolutely crucial.

Bulk ignore sounds handy in theory, but currently some integrations can be ignored and others cannot. How is this going to be communicated to the user? It shouldn’t just fail silently, that would be no good. And if you select one integration that can be ignored and another that cannot be ignored, it would be annoying to get an error prompt telling you to unselect some stuff first. In the current design it has either two buttons (Configure/Ignore) or one button (Configure) if it can’t be ignored, so it is clear what actions can be performed.

I have doubts on how usable this would be on mobile in that current form. Go to the current integrations page on your mobile device and press the add integration button, that will give you a better idea of the available screen width after icon + integration name. Even if you shrink the text and icon size a great deal, you definitely wouldn’t be able to fit all 4 of those columns (desc, status, devices, entities). And unlike some of the other data tables used in HA, this one simply cannot make the entire row clickable.

Those are just some of the issues I see so far. I think it’s a good start to a very challenging problem. I still recommend holding onto this idea until a bit later when the core user experience for integrations is in a more mature place. But if you wanna try to figure out all this stuff sooner I’d be happy to provide feedback and suggestions where I can. If you can figure out all the UI and UX challenges and clearly demonstrate the benefits, the proposal would have a much higher chance of being considered / implemented. Good luck! :slight_smile:

(Btw don’t post this in architecture repo, that would be frowned upon as that’s for major backend proposals. This is purely a frontend suggestion, so post it there as a FR instead when you’re ready).

2 Likes

Thanks! You’ve given me a lot to think about. I don’t have replies to all of your questions but a few come to mind:

Some of the challenges you’ve described aren’t unique to the tabular view but also apply to the card view. In addition, some are addressed by the fact that choosing an integration (whatever its status) from the tabular view will open a new page with ample space for displaying relevant menu options and information.

I realize that was a generic answer and did not address the specifics of the Plex integration. That’s mostly because I have no experience with it and simply borrowed it from your suggestion. I’d have to know more about it to propose how its UI would handle the challenges you described.

The mobile vs desktop issue is difficult to solve with a single solution that doesn’t compromise some degree of functionality. I feel the current card-based Integrations page represents the opposite paradigm of the tabular-based Devices, Entities, and Areas views.

  • Card-based adapts well to mobile whereas tabular does not (at least not without degrading legibility).
  • Tabular-based on desktop/tablet offers more functionality compared to card-based.

I propose allowing a choice of card or tabular view in the Overflow menu (collective groan from developers). If I’m using a mobile client (i.e. small screen), I may prefer to use the card-based version whereas on desktop it would be tabular.

Otherwise, making one mandatory over the other comes with deficiencies. For example, I would not want the Devices, Entities, and Areas views to become card-based, and lose tabular’s advantages, just to satisfy the needs of a mobile device.

Thanks for the tip; I’ll post to frontend repo (if this proposal has legs).

But how will this work if you select more than one integration? You cannot show multiple pages at once, so it becomes about how do you lay out all this extremely different data and action buttons into one location without it being super confusing.

Like what type of screen and menu options would I see if I were to select Plex, Brother Printer, and Sonos from your mockup? These three integrations each have different statuses (attention, discovered, ignored) and each of those statuses have their own unique controls.

Plex would need a button to reauthorize credentials, the printer would need buttons to either “configure” or “ignore” the discovery. And Sonos would need a button to “stop ignoring” … So that’s four different buttons, each which only work for those specific integrations, so it has to be clear which button belongs to which integration.

And then on top of those buttons which vary depending on status, you have the four standard buttons (rename, delete, system options, integration options). I think it would be super complicated to create a good UI for all these actions without using cards. And if you have a table view that you ultimately just end up on a page with cards in the end if you actually wanna do anything besides view it, that feels counterproductive? I dunno.

I don’t mean to sound discouraging, simply pointing out there’s a LOT of scenarios that have to be taken into account to properly support something like this. It might seem pretty simple at first but it’s actually quite a challenging issue. You’ve already done far more than most though by making a mockup and offering good suggestions rather than just complaining, so props for that :slight_smile:

Maybe do the cards like they are now, but nest them and have the multiples of the integration under the main card?

The main header card could have an error message like “Attention Required” or “Reauth Needed” then the sub card would have the error bounding. It would save screen space like @123 would like (honestly I would too), plus give a general overview of the health of the integrations.

If you select more than one integration, just like in the existing Entities view, a sub-menu appears offering context-specific commands. In the case of Entities, it’s Enable, Disable, Remove selected items.

A similar menu would appear with commands applicable to Integrations, displaying commands that only make sense for managing multiple integrations (for example, Ignore/Unignore/Delete selected). You cannot use the checkboxes to run a command that cannot be logically applied to all selected items (i.e the menu would never include a command to Configure multiple items).

The same menu as mentioned above, namely one containing commands common to all Integrations. For example, Ignore/Unignore/Delete selected. The command would be applied to whichever selected items are eligible.

For your example, all three have different status so if the command is to Unignore then only Sonos changes status from Ignored to Discovered (the other two are ineligible and would be skipped). If the command is Ignore then the Brother Printer would change status from Discovered to Ignored (the other two would retain their status; unless someone says it’s allowed to change a Configured integration to Ignored).

What the menu would not offer are commands that, for all the reasons you’ve mentioned, are impractical or illogical for multiple integrations. For example, you can’t simultaneously configure more than one Integration nor can you simultaneously address the needs of multiple Integrations in Attention status.

For those operations, you click the Integration.

  • If it is has never been configured, it proceeds with the integration’s config flow.
  • If it has been configured, clicking it presents its status “Info” page containing manufacturer’s logo, links to its Devices/Services and Entities, documentation link, as well as commands for Rename, System Options, etc and any other details needed if the Integration’s status is Attention.

For integrations that can be modified after their initial configuration (only a few can currently do that, but it’s the future) the integration’s status page is where you would find the means of reconfiguring the integration.

That’s the thing, I’m not proposing a menu that varies based on status. As mentioned, it would contain commands that only make sense to use with multiple integrations. Beyond that, you have to open the integration to display its status “Info” page containing additional information and relevant commands.

This is the part I feel will be confusing for users though. Let’s say I have ten integrations in the “Discovered” state. I don’t want to add these to my system, so I select all ten with the intention of performing a bulk ignore. But on the backend side, only five of these are actually capable of being ignored.

So what does the menu show me in this scenario? Is it going to:

A) show me an “Ignore” button only applies to half of my selected items, and silently fail leaving me with a 50% success rate.

or

B) hide the “Ignore” button from me, and then require trial and error on the users part to figure out which ones can be ignored and which cannot.

I feel like both options are equally frustrating. It’s either going to silently fail on the user, or prevent them from carrying out their desired task, both without any indication of why it didn’t work. I’m not sure there’s really a clean solution to a scenario like that.

Realistically, I think the only bulk action that will be able to reliably be performed on a consistent basis is “Delete.” And there’s going to be far less reason to delete integrations when you can now simply fix your credentials etc.

Such a page doesn’t exist though, it’s just Devices and Entities. And even if it were created, I think it would make the table view feel a little inefficient if you had to access a subpage for most management options while the card view had that all on one screen.

Then only 5 of them will be ignored and the balance will be left intact. However, this seems like a contrived example because efforts have been made to permit ignoring discovered integrations (I recall users were displeased when Homekit discovery could not be silenced). Therefore the odds of having 50% of your discovered integrations not ignorable will become vanishingly small.

In any event, if the integration cannot be ignored “in bulk”, examining its status page would reveal there’s no Ignore button available (just like a card-based view would lack an Ignore button).

No less efficient than the existing status page for every Device.

This proposal uses concepts that are already employed elsewhere within Home Assistant’s Configuration menu. It doesn’t introduce much of anything new but simply borrows from existing functionality. I believe anyone familiar with the tabular Devices and Entities views will feel comfortable operating a tabular Integrations view. It’s just more of the same philosophy.

1 Like

Here’s another example of how this proposal simply borrows from existing concepts, consider how Add-Ons are currently managed.

Although the Supervisor > Dashboard page is not a tabular view, each Add-On is displayed in a compact card. In fact there’s an existing frontend Feature Request to make Integration cards more compact like Add-On cards. If creating a tabular view is deemed to be too onerous a task then compact cards are a fair compromise (even though they lack all the management features of the tabular view).

If you click an Add-On, it presents its Info page showing its logo, link to documentation, and menu items to configure and manage the Add-On. This is precisely what I’m proposing for Integrations (with the sole exception being a tabular view leads to an integration’s Info page).

1 Like

Fair enough :slight_smile:

I just don’t really think a tabular view is suitable for this particular purpose, it has far too many drawbacks IMO. Even something like sorting, where you’d think a tabular approach would have the advantage is actually far worse because it can only sort one column at a time. The existing card-based view sorts alphabetically by integration name and alphabetically by config entry and prioritizes by status simultaneously without requiring any user interaction at all.

It’s reasons like this why I suspect most wouldn’t use a table view if offered, the user experience just wouldn’t be as good. The main benefit (smaller icons) could be achieved in other ways that don’t have all these drawbacks.

A more compact card-based view would probably have a much greater chance of being implemented as it could re-use the existing codebase for the most part. Logo size would be changed to icon size, the bottom row of buttons would just get moved inside an overflow menu (3 vertical dots icon), and the other parts could stay mostly intact. Here’s a quick initial mockup:

But this has issues too. I’m not sure how to implement the integration grouping feature coming in 0.110 into such a tiny card, for example. You wouldn’t be able to fit a scrollable list into such a tiny card height. Don’t really have the time to figure it out right now, working on another project. But if you find something like this satisfactory I can look into it this weekend maybe.

The so-called ‘drawback’ you’ve identified exists in at least three existing views in Home Assistant (Devices, Entities, Areas). Therefore you’re expressing an opinion about a wide swath of Home Assistant’s current Configuration UI and not uniquely to this proposal.

One column at a time is the status quo throughout the other views and actually proves to be quite flexible (especially combined with search). In contrast, although the cards are pre-sorted in the aforementioned hierarchy, that’s all it’s capable of doing (one-trick pony).

The codebase to display a tabular view already exists and is used for Device, Entities, and Areas.

That can also be achieved in a tabular view if there’s an Integration column.

I look forward to seeing how the existing card-based view evolves in 0.110. Perhaps it will improve the situation or only serve to demonstrate that there’s an increased need for a tabular view.

2 Likes

Sorry for the late response, short on time this week and wanted to set aside 30 min to give you a detailed reply with specific examples. Long post warning.

  1. People expect things to work in logical ways. When you get a text or email on your phone there’s a red badge over the icon and your message is always right there at the top when you launch the app. That makes sense and is the same kind of thing we’re aiming for - stuff that requires attention gets floated to the very top and is unmissable. But on a table you can’t ever make this same guarantee, because the user is going to have it sorted by “Name” 99.9% of the time. Because alphabetical order is the logical way to view lists. So now when your “Withings” integration breaks, it’s out of sight at the very bottom possibly several pages deep. Is it hard to sort the table or scroll up and down? No, but it’s undeniably less convenient. One requires continual manual interaction and the other does not.

  2. Your mockup is incorrectly referring to expired credentials as an “Alert” but the actual status for what is depicted is going to be either “Error” or “Failure.” Alert is an entirely different status for things outside of the users control like API issues and service shutdowns etc (it’s basically integrating the https://alerts.home-assistant.io/ website). But what this means is that the “Status” column will have “Error” state listed towards the very bottom below Alert, Configured, Discovered (and only above Ignored) despite Error being the absolute highest priority of the bunch. That is the exact opposite of what we want.

  3. Related to my above point, isn’t Discovered more important than Configured? This is the way Home Assistant has always worked, your discovered integrations were always shown at the top of the Integrations page above your configured ones. You want to know when there’s something new you can add. But in a table the Discovered integrations are shown underneath all your working ones towards the bottom because “C” comes before “D” alphabetically. This is a regression of functionality, and an example of why it’s better to manually prioritize things. So these are some specific examples of how even when you have it sorted by Status, it’s still not always showing information in an ideal order.

  4. Tables cannot provide grouping, just sorting. The complaint Tom posted in the other thread about seeing 41 ESPHome cards/logos in 0.109 is always going to be an issue with a tabular view (they’ll just be icon-sized instead), because you need a table row for each config entry. But in 0.110 those 41 entries will be grouped into a single card which is the equivalent height to just ~5 table rows. I consider that particular issue to be solved, but you can judge for yourself when the beta drops on Wednesday and submit feedback if you disagree.

  5. Tables do not scale down well to mobile - there’s only room for two columns basically. Yes, this is also a problem with the existing tabular views you’ve mentioned (and one I’ve created an issue for in the past). But it’s even more pronounced here because you’re attempting to display even more things. The Devices page on mobile completely eliminates some columns like “Manufacturer” and “Model” for example but you also have a checkbox and icon which that page doesn’t. So you need to figure out which information gets sacrificed on mobile. You might be able to come up with something serviceable, but the simple fact that you’re forced to make cuts already makes it a worse experience on mobile in my eyes.

  6. You have another problem that Devices and Entities table pages don’t have to deal with, because the Integrations page has an orange “Add integration” (+) button that will always be partially covering the bottom table rows on mobile.

  7. Tables as described involve more clicks to perform any task compared to the current view. Currently it’s just one click to access rename, one click to access the integration options, one click to access devices, one click to access entities. And depending on integration status, just one click to configure/ignore/unignore/reauthorize/view alert. But by putting everything on another sub-page you’re adding at least one more click and page load before you can access those same buttons. And then another to get back to Integrations page. In this table view, you’d also need to click on something just to see what you’re even capable of doing which hurts discovery of feature set.

  8. The integrations subpage you’re asking for was intentionally removed in favor of Devices pages. I don’t think there will be any desire to undo that work and add it back, especially since it’s only needed here to compensate for a limitation of a completely optional view that hasn’t even been implemented yet. Either this page is super empty with a handful of buttons, or it will be a full-fledged page that basically duplicates everything on “Device details” … But that would require a ton of continued maintenance to keep it in lockstep as that page evolves. This part is likely the biggest hurdle for your proposal IMO.

With all that taken into consideration, would enough people use a tabular view over the default? I don’t believe so. It can’t surface important information reliably, it requires more clicks to carry out the same identical tasks, and the experience will be worse on mobile (which eclipses desktop usage).

What real benefits do you get that are impossible to achieve in a card-based view? What use case is it making easier or faster over the existing view? Does it make sense to create an entirely new view rather than just focusing on improving the existing one?

But it’s OK to disagree on this. I encourage you to post it on the frontend repo and see what others think; I won’t get involved or argue against it or anything. Just wanted to give you a thorough response that you probably wouldn’t receive over there.

I appreciate the time you’ve take to reply but I can’t help but feel that, for reasons unclear to me, the rebuttal disregards what modern web-based tables are capable of achieving.

because the user is going to have it sorted by “Name” 99.9% of the time.

The user will have it sorted whatever way they want.
With cards it will be sorted the way the developer wants.

Is it hard to sort the table or scroll up and down? No, but it’s undeniably less convenient.

It amounts to a single column-click.
What’s truly “less convenient” is no sorting at all.

the “Status” column will have “Error” state listed towards the very bottom below Alert, Configured, Discovered (and only above Ignored)

It’s a mockup and those are status titles in English but they could be in another language so you never actually sort by the literal status name but by a status code. The code (integer values) can either be revealed in the UI or used internally exclusively for sorting purposes.

sorted by Status, it’s still not always showing information in an ideal order.

Addressed in my previous reply: use hidden status codes (1=error, 2=discovered, 3=configured, 4=ignored)

Tables cannot provide grouping, just sorting.

Tables with collapsible rows can (like a treeview)

Tables do not scale down well to mobile - there’s only room for two columns basically.

Agreed, unless you rotate the device in landscape orientation and then there’s room for more than two columns.
The alternative is the card-based view which, for all practical purposes, is one or two columns even in landscape mode.

Integrations page has an orange “Add integration” (+) button that will always be partially covering the bottom table rows on mobile.

This has been true since FABs were introduced in Material Design ages ago. The world is accustomed to that behavior so I’m not sure why that’s raised as an issue in this context.

Currently it’s just one click to access rename, one click to access the integration options, one click to access devices, one click to access entities.

It’s one click to access integration options, devices, or entities, and it’s the same with the proposed tabular view.

In this table view, you’d also need to click on something just to see what you’re even capable of doing which hurts discovery of feature set.

You’ve just described how many other views currently work and it hasn’t proven to be hurdle to discovering features. Clicking on a table row is quite intuitive to most people; you click to explore that item.

Either this page is super empty with a handful of buttons, or it will be a full-fledged page that basically duplicates everything on “Device details”

It’s neither empty nor a duplicate of the Devices page. It would be like what’s found for Add-Ons.

With all that taken into consideration, would enough people use a tabular view over the default? I don’t believe so.

Do you believe people are willing to have the tabular views of Devices and Entities replaced by cards? I don’t believe so. In the same vein I believe they would enjoy the flexibility of a tabular Integrations view.

What real benefits do you get that are impossible to achieve in a card-based view?

Maybe not impossible to get with cards but challenging are: space-efficiency, sorting, grouping, and batch operations.

Does it make sense to create an entirely new view rather than just focusing on improving the existing one?

The proposal is not technically an entirely new view. It already has siblings elsewhere in the product. In contrast, the card-based Integration view is entirely new. Plus, it’s only the first version and more development effort will be invested. Therefore, one way or the other, there’s work to be done.

1 Like

You could sort the table view by whatever criteria the user wants but you can force those items identified by the system as needing further attention separately to the top. You already do that now it seems in the card view already.

HACS does exactly that right now in table view (except it doesn’t allow for sorting on different columns but that shouldn’t make any difference to this functionality) - Things are sorted alphabetically (sort of) but any item needing attention is elevated to a top section of the list and is given a different icon/coloration.

And of course it’s easy enough to add either view as an option, again, as HACS currently does. So it’s up to the user to decide how they want to view the information depending on their needs/desires.

I just updated to 109 and really dislike the card view for the integrations. It’s really too busy. You also need to figure out if the cards are sorted right to left or top to bottom. It’s not intuitive one way or another and is different based on if you are on mobile (which I never use for any configuration just access to controls) or on Desktop.

And as more integrations are forced to be added to the list then it’s only going to get worse.

1 Like

I’m in the same camp. I do recognize that the new Integrations view is laudable for dumping the display of entity-icons. It never amounted to more than eye-candy, seeing all those tiny entity-icons in a row.

I’m far less enamored with the over-sized logos (some occupy 50% of the card’s space). I like the suggestion made to reduce the cards to the size used by Add-Ons. Buttons can be replaced by icons to save space. It would not only be more space-efficient, I feel it would be more attractive. Currently, I have ten large “Rename” buttons staring at me and I’ve yet to find the need to rename a single Integration.

Anyway, 0.110 is on the horizon so I’ll reserve final judgement until I see the rumored improvements.

1 Like

Which is a good thing as far as I’m concerned. Information would always be presented in a consistent and logical way, would never require any thought or interaction on the users part, and could be easily explained in documentation.

I acknowledged it was easy to change the column sorts, but that’s besides the point. It’s constant manual adjustments that can be completely avoided altogether if that information was just always sorted optimally in the first place. With a table it just can’t ever be 100% ideal because when you change one column it screws up the others.

I’ve honestly never seen a single complaint against integrations being sorted alphabetically, nor have I ever seen a single feature request for someone wanting them displayed in descending order instead. The current sort aligns exactly with the way people expect it to work.

While this might work, I feel like it’s a choice between two unsatisfactory options - something ugly (numbers in front) or something confusing. Sorting by invisible criteria that is inconsistent with the behavior of all other columns feels like bad UX imo. Personally I do not feel a “Status” column should ever be sorted the opposite way - it literally defeats the entire purpose of said feature if you’re showing crucial information on the bottom.

How though? If you’re clicking on a table row to navigate to a subpage, that’s your first click right there before you can even see any buttons. Or if you’re clicking a checkbox to show options at the top of the table, that’s your first click right there. In either scenario it’s adding an extra step in-between which the current view doesn’t have.

Batch operations is the only challenging one, grouping was already added and sorting would be trivial with cards - it’d just be a dropdown instead.

As for space-efficiency, I encourage you to visit your Integrations page and count how many cards are visible on that screen. And then click the Devices page and count how many table rows are visible on that screen. I think you will be very surprised to see just how close those two figures actually are. For many people they’re actually going to see a bit more cards than rows because nearly all monitors have more vertical screen real estate than horizontal.

It does actually because if HACS was using a real tabular view it wouldn’t be able to guarantee the placement of things. Despite HACS using the term table view, it’s really just actually a list with a single sort option. So it has a more predictable behavior.

But the way HACS works is overall extremely similar to the aim here - surfacing things that require attention to the top, color-coding them by status, etc. On the “Installed” tab in HACS (the equivalent to this HA Integrations page) it also sorts your integrations in alphabetical order with no available sorting options. those are only in the store pages.

I feel the primary issue here is mostly about presentation, some don’t like the large logo size and whatnot which is fair criticism. I plan to look into a more compact mode and see if something can be figured out there.

It wouldn’t really be saving space tho, the icons and button text are the same height. If those buttons were converted to purely icons, it would free up room on the inside of the card but not make the overall size of the card smaller. It would just make each card a little more empty looking.

Here’s a good example of the types of often atrocious default generated names that demonstrate the need for renaming Integrations page name overflows on long names · Issue #5806 · home-assistant/frontend · GitHub yuck :face_vomiting:

I’m more than willing to continue debating this with everyone but ask that they avoid employing contrived deficiencies. It undermines the credibility of their rebuttal. I believe everyone wants the best experience for users so let’s focus our collective energy on that.

I’m not single-minded about a tabular view, just the functionality it provides. If most of the desired functionality can be achieved with a card-based view then I’m fully onboard.

Here’s the list:

  • Space-efficiency.
  • Grouping by integration.
  • Color-coded status.
  • Batch operations.
  • Sorting by name or status.

Space-efficiency

I firmly believe the logos are unnecessarily large. Unless the manufacturer is paying for advertising space, I see no practical reason to exceed the size of the stamp-sized icon used elsewhere in the application.

Grouping by integration

I believe Sean confirmed this will be addressed in 0.110 and I applaud that decision. In my case, I currently see four instances of the homekit_controller integration, each one representing a single physical device (with 5 entities). It should be one instance of the integration indicating 4 devices and 20 entities. For example, I currently see a single instance of the MQTT integration and it reports 6 devices and 51 entities.

Color-coded status

Sean proposed this enhancement and I hope it is adopted.

Batch operations

There ought to be a means of selecting multiple integrations to allow for batch operations like Ignore, Delete, Hide, etc. Selecting an ineligible item for a given command is not a dealbreaker. In fact, the current Entities view already handles this situation. I attempted to delete several ineligible entities and was presented with this popup:

Screenshot from 2020-05-05 16-38-53

Sorting by name or status

These options could be tucked away in the Overflow menu. It provides the user with the ability to quickly toggle the order of the integrations by either their name or their status.

If all of that can be achieved with the card-based view then there’s far less justification for using a tabular view.

1 Like