I am an experienced HA user but I had the pleasure of helping and observing a new HA user create simple light automations for 3 hours this weekend. From that I have identified several pain points in the automation UI and have suggestions for how to improve them. I am posting these here for input/discussion.
Cheers,
-David
Problem 1: Choose entity pop-up requires repeated searching for the same items.
Proposal 1: List the 5 most recently used entities at the top of the pop-up
(Most frustrating by far: this made the experience go from “oh cool” to “arg, not again”.)
The most frustrating part of using the UI by far was having to search for “bedroom light strip” dozens of times to create 10 automations. If the pop-up list remembers the last 5 most recently used items at the top, this would have made the process of creating automatons immensely more enjoyable.
This was most frustrating in simple things like if/then/else blocks where the same entity needed to be searched for 2 or 3 times in creating just one automation.
Problem 2: The Add Action menu has unclearly-named items organized alphabetically
Proposal 2: Clarify the names, re-order by common usage, and group by function
(The new user would not have figured this out without my help)
Here is a simple problem the new user ran into: To figure out how to turn a light on or off you have to know that the item is “Call service” and then you search for a “service” called “light.turn_on” or “home assistant.turn_on”. This is not intuitive unless you are used to writing YAML and using “service: “ in your code.
Further, the items are sorted alphabetically, which means that you have to look through the whole list to find items by function and the very uncommonly used by beginners “Condition” is the third item they see. For example, choose, if-then, and repeat are all control-flow items, so they should be together so you can see the options for control flow, while call service, scene, and play media are all actions that should be together.
In addition, “device” is unclear: what does “device” do? When I select it, I see that it provides common actions for most devices. This is probably the most useful item in the list for new users, but they will only discover it by accident since it is the 5th one down and not clear what it means.
Here is an alternative organization that will make the menu easier for new users by 1) clarifying the names, 2) putting the most common ones at top, and 3) grouping the items by what they do. In particular, this provides 4 example services so that users can see what the most common services look like and see how to explore other services.
- Common Device Actions <— (renamed from “Device” to say what it does)
- Activate Scene
- =======
- Simple Turn On <— (inserts a homeassistant.turn_on service call)
- Simple Turn Off <— (inserts a homeassistant.turn_off service call)
- Simple Toggle <— (inserts a homeassistant.toggle service call)
- Advanced Light Turn On (color/brightness) <— (inserts a light.turn_on service call)
- Play Media
- Other Actions… <— (inserts a service call, but renamed to make it clear what that is)
- =======
- If-then
- Repeat
- Choose (multiple If-then) <— (explain what this does in the title)
- Stop Condition <— (explain what “Condition” really does)
- ======= <— (special/advanced items at the bottom)
- Generate Event
- Define Variable
- Run in parallel
- Wait for a template
- Wait for a trigger
Problem 3: Searching for services does not find names that do not match YAML
Proposal 3: Ignore “.” “_” “:" and “ “ in searching the add service pop-up
(This problem occurred every single time the new user went to add a service because you can only remember the “.” and “:” if you are coming from YAML.)
If you search for the service “light turn on” in the add service pop-up you find nothing. You have to search for “light.turn_on”. This is a problem for new users, as they have no reason to use either . or _ in their search. The search should ignore those characters so “light turn” will find “light.turn_on” and “light.turn_off”.
Problem 4: light.turn_on is extremely complicated if you just want to set the brightness
Proposal 4: Hide most of the advanced functions unless the user chooses to show them
(The new users got lost in the list of options for light.turn_on each time and was never clear on which of the four brightness options should be used.)
Most new users just want to use light.turn_on to set the brightness or color, so those should be the most visible options. But right now we have 6 color options and 4 brightness options to choose from.
This can be simplified by showing only the common options first, and having the others shown only if the user chooses to show them:
- Target
- Transition
- Color
- Color temperature
- Brightness
- Effect
- Advanced color/brightness <— (hidden by default)
- RGBW-color
- RGBWW-color
- Color name
- Hue/Sat color
- XY-color
- Color temp (Kelvin)
- Brightness value
- =======
- Brightness step value
- Brightness step
- Profile
- Flash
Problem 5: It is easy to get lost in the automation list when there are if/then or choice blocks
Proposal 5: Color each depth level the same (and increasingly dark) shade
(The new users was constantly scrolling up and down to try and figure out where they were in if/then blocks and choose blocks. The worst was adding an OR block which made the if/then even harder to follow.)
This can be solved by using increasingly dark shades of gray (or alternating) as background colors for each level of depth in the hierarchy. This would make sure everything in the “if" part was visually separated from the "then” part and that the items in the “or” part in the “if” part were visually grouped. (Clearly there are problems with how many levels deep and how dark, but doing this for just the first 4 levels would probably cover 99% of new users.)
Problem 6: Not clear if you should use a Device or an Entity as a target
Proposal 6: Hide one or the other
(Low-priority: the new user just always used entity, but did not know why.)
It is not clear why you should choose a device or an entity when applying a service call. Both are available and most things are listed in both. If one is preferred, it should be shown and the other hidden.
Problem 7: The Create helper dialog calls “input_select” a “Dropdown” but the call service menu has no service for “dropdown”.
Proposal 7: Searching for “dropdown” in the call service menu should find “input_select”.
(Low-priority: It’s impossible to write automations for “Dropdowns” for new users as they do not know they have to search for “input_select”.)
