ha-dialog-automation-save: small improvements & fixes

[ildar170975]

Breaking change

Proposed change

Currently in ha-dialog-automation-save (both for automations & scripts), when all fields are added, vertical spaces between fields are different (happens due to a "helper" element in ha-textarea):

Another imperfection is, when all fields are shown, a vertical space between the last field & "save/cancel" buttons also differs from an initial state (when ha-chip-set is not empty):

And another imperfection - even an empty ha-chip-set has some margin-top:

To solve the 1st issue, proposing to move the "description" field to the bottom.
Some users are not using this field, some are, so it is a questionable point:

• whether we need to move the "description" to the top (and have a bigger vertical separator between "major fields" & "minor fields") - i.e. the current implementation;
• or we do not consider fields as "major/minor", so the "description" is just one of other fields.

To solve the 2nd & 3rd issues, some CSS styles were changed:

1. In ha-dialog-automation-save.
2. In ha-textarea for a "helper" element - a known value was set for line-height instead of some browser-dependent normal value.
3. Also ha-labels-picker: remove margin-bottom for ha-chip-set #28559 is required to remove an unintended margin-bottom for ha-labels-picker.

Results:
Equal vertical spacings between fields:

Almost same vertical spacing between the last element & "save/cancel" buttons:

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[BBE-FR]

If I may comment, on the order of the boxes only:

I am a strong user of the description field. As for the time being there is no real and solid way to comment the code, this is where I put my personal summary of the automation.
For me it is almost a mandatory field, and at least a very good habit to take => pushing it to the last box is showing a lowest priority that it does not deserve.

Moreover, with the curent design of Home, adding an area expose to everybody in the house a way to de-activate an automation, thus, (to my personal point of view) as long as there is no filtering capacity in Home dashboard area subview, it is a good habit not to attribute an area to an automation. Having area above description (both not being mandatory) is for me controversial in that context.

Name is the only mandatory field and deserved to be first, all other are optional.
I would have put description 2nd or 3rd as it was previously to show that commenting is a good habit.

I do not have Icon for the first "save", I have it in second:

[ildar170975]

I am a strong user of the description field. As for the time being there is no real and solid way to comment the code, this is where I put my personal summary of the automation.
For me it is almost a mandatory field, and at least a very good habit to take => pushing it to the last box is showing a lowest priority that it does not deserve.

This is one opinion.
Another opinion is that "Category" is used by some users to describe/differentiate automations/scripts where the "Description" is used to add a detailed description. Also, the "Category" is shown in a table, we can filter / sort by it. And the "Description" can only be seen if you go down to a particular automation/script's properties.
Besides, both "Category" & "Description" properties cannot be retrieved by any jinja template (for now), so we cannot show them on a dashboard (like in a Markdown card).
Means - here only "Category" (+ "Area") can be seen on pages in tables (unless you go deeper) & only these properties can be used to filter / sort.

I do not have Icon for the first "save", I have it in second:

Icon can be set on the described dialog only for scripts.

[ildar170975]

Also, I may propose a PR to add a separate column "Description" to tables, but it will show only a short beginning part of a description.

Or - better - make it like it was done for labels:

i.e. smth like:

But the problem is that descriptions for automations & scripts are kept in yaml file(s), and to get descriptions for tables you need to pull a file or many files, which could happen not fast. So, showing a description in tables might be not worth it...

[BBE-FR]

Also, I may propose a PR to add a separate column "Description" to tables, but it will show only a short beginning part of a description.

Maybe instead of table it could be a "pop up" (tooltip? not sure of the name... "infobulle" in french) on hover, or by clic on an "info" icon, To keep a clutter free table while allowing access to the description without opening the automation/script.

[ildar170975]

@BBE-FR
Sorry, probable we should not discuss it here, not related to the topic directly.
Currently I am busy with implementing a design proposing here.
PR is not ready yet, in progress: #28592

[marcinbauer85]

@ildar170975 I'd recommend to leave the ordering as it is, since description is really an extension of the name of an automation, so these two go hand-in-hand. The next three: category, label, area are grouping meta data so thats why they are also close to each other.

For your first point on the inconsistent height, I'd just show the helper always, since showing/hiding it every time we focus on that field is more distracting. Also make the "Markdown" link in this case the same color as the helper text color, so it doesn't stand out as much.

And yes, remove the empty chipsset when they are not needed 👍

[ildar170975]

@marcinbauer85
Thanks for the feedback. OK, will do.
Also, your note about a description - since you think that this is a "extension of a name" - we probably should give it some more accent in a table view (#28592).

[ildar170975]

@marcinbauer85
I did as you suggested - except a weblink color.
Imho it will be not great that in some places a "markdown helper" is shown with a classic weblink color, and here - with a similar color.
Please check this: