Observing a new user for 3 hours: Automation UI improvements

Feature Requests
21

Ironically, those who skip reading the manual often end up searching forum posts.

Only later to be told it’s in the manual.

… still needs to know basic concepts like the difference between an automation, script, and scene otherwise they won’t even know where to begin when they want to start automating.

If they choose to create an automation, one of the first questions is if you want to make one from scratch or a “blueprint” (new unfamiliar term). If they choose from scratch, they’ll need to understand what Trigger, Condition, and Action are, and how to create them properly, because it’s not self-evident (unless they have previously used similar software).

Perhaps what could be helpful are links in the Visual Automation Editor that lead to the appropriate pages in the documentation (or streamlined versions of the documentation). One way or another, more learning is ultimately needed, sourced from somewhere, because there’s only so much you can convey in one sentence in the UI.

It’s the equivalent of Home Assistant in many respects. Plus it offers a Basic Rule Editor for the so-called ‘non-technical consumer’, so it has a leg up in that regard.

None of which offer the power, sophistication, and flexibility of Home Assistant (or openHAB). Arguably, it’s easier to present things more simply when the product is, in fact, simpler.

I suggest that Hubitat Elevation represents a better comparison. For less money than Home Assistant Yellow, it offers a combined hardware/software solution with free remote access. The breadth of products it supports approaches that of Home Assistant (or at least more than Google/Hue/Amazon etc).

It provides several editors each one purpose-built for automating specific, common tasks such lighting, climate, security, etc plus a general-purpose Rule Editor. The task-specific editors help a new user through the process whereas the Rule Editor does far less hand-holding. In addition, the Rule Editor is far more ‘conversational’ than Home Assistant’s Visual Automation Editor; it employs a sentence to describe things that Home Assistant might do with a word or two.

Having looked at both openHAB and Hubitat’s approach to creating automations, it’s clear to me that there’s room for improvement for Home Assistant. However, I’m not a developer so I can’t submit a PR to make the magic happen.

1 Like
22

as I’ve said many times in these forums…

you have 3 options - cheap, easy, powerful.

Pick two because you can’t have all three.

Google, Amazon, Hue, etc are in the cheap and easy category but you can’t do as much with them as you can HA - not powerful.

I hear there are commercial (paid for) apps around that are fairly easy and can do a lot. but they aren’t cheap.

HA is in the cheap and powerful category. It’s definitely easier than it used to be to do the basic stuff but as soon as you move away from that the user still needs to know quite a bit of how the more complex things work. There’s no way to explain templating in the UI. Or even the finer points of logical program flow control (if-then-else-choose-repeat-etc).

the only way to get that is to RTFM.

23

@123 Dear Taras,
Thank you for your constructive idea about putting manual links on each automation.

I really do not want to argue about how much the user should be expected to read before they can use the UI. I have designed multiple UIs for online and client systems, and I see the point of the UI as simple: make the system as easy to use as possible. This thread is about how we can do that based on real-world experience. I believe that goal valuable, and I hope you can continue to contribute constructively towards that goal in this thread.

1 Like
24

Precisely! This is exactly why I put it at the bottom of the list. Users should see the intuitive options before this one so they can ignore it unless they know what it is, or want to explore it. That gives you easy for most users and powerful for the ones who know what to look for and it is cheap because you just need to re-order a list. But you can’t always get all three.

My philosophy is that UIs should expose the most frequently used and important operations most obviously. That is why I put four examples of frequent/important operations first (on/off/toggle and light turn on) on the actions list, and the generic “action” after that. That provides the users with examples of how the system works that are intuitive for them to find.

Similarly, by grouping the control-flow actions, users who understand even the basics of if-then-else see that there is also a repeat and a choose. I also suggested re-naming choose so that it is more clear what it means. These are all intended to help users see most of the functionality without needing to get into all the complexity, and most of them are cheap to implement.

But are right that we cannot be cheap, easy, and powerful all the time. Here are some of the tradeoffs in what I proposed:

  • re-ordering the actions menu makes it easy (for new users to find the most common choices) and powerful (advanced users have them at the bottom) and is cheap to implement.
  • hiding the advanced parts of the light.turn_on pane makes it easy (for new users to find the most common choices) and powerful (advanced users just click “advanced” to get the others) and is reasonably cheap to implement (hiding/showing a div, but it will add more test cases).
  • adding most recent items to the search makes it easy (for everyone) and it is still powerful (can still find anything) but is expensive because you have to add and test state.
  • fixing search to no match YAML names makes it easy (new users don’t have to know YAML) while keeping it powerful (advanced users can still find what they know) and is cheap (just need to do a regex replace on the search term and the search list).
  • coloring the automation blocks makes it easy (for everyone) but it is still powerful, however, it is expensive as there are many corner cases to consider.
  • fixing the search to find “Dropdown” for “input_select” makes it easy (for users who do not create helpers in YAML) but keeps it powerful (for everyone who knows YAML) and is reasonably cheap (as you need to add extra search terms to the menu items).

So I’d argue that it isn’t that we can only have two of the three, but we need to strike a balance.

My point of this discussion was to get input on how valuable these are for the easy side (none of them hurt the powerful side) and then people with more developer knowledge can judge the cost side.

-David

1 Like
25

Dear David,
You’re welcome.

Here’s a contribution based on nearly five years of experience with Home Assistant: cultivate patience.

No matter how good your ideas/suggestions may be, merit doesn’t ensure implementation. Browse the Feature Requests section and you’ll find useful (and popular) requests that are several years old.

Ultimately, a developer is needed to implement it and many ideas remain merely ideas for various reasons: a shortage of interested developers, deemed not worthy of their time, are beyond their skills to build, violate architectural/design principles, don’t pass muster with the development team, etc. An idea may become a Pull Request only to languish as a PR for months because there’s no other developer available to vet it.

As recommended by petro, state each one of your ideas in a separate Feature Request and hope the most easily implemented ones are picked up soon. Good luck.