There was a lengthy and heated discussion in this WTH about why a lot of people here think this is an important technical distinction even though from an non-techie users perspective it makes no sense.
1 Like
I agree with OP in general. It’s worth to say, it’s not only HA. It’s a common problem of a lot software development teams and their products.
It’s proven that developers tends to create user-facing part of system in a way exactly reflecting software internal structure or processes.
It comes from several facts:
- they are not users of their software
- they know well how their sw does work under the hood so they feel no need to make user-facing behavior different
- they have no knowledge or imagination about ouside of their desk (ie designing systems working with local time only or hard linking date format with a language)
- there are no user-journy analysts in dev teams
The most common example are front edit forms and their workflow follows exactly relational database model used by the system.
Let’s look at Hacs current GUI. One page with filters next to useless.
Another example is mentioned NodeRed. To make it working you need NodeRed extended with HA nodes (add-on), NR custom extension , available in hacs, and integration running.
End-user really don’t want to cope with all dependencies.
Speaking add-ons. This issue comes back again and again with every WTH. Users often don’t understand the difference between addon and integration or custom integration. And guess what… HA devs did nothing to this situation.
While I understand the differences I agree that at least naming is confusing. At the end I can imagine installing and maintaining all extensions from single page.
In a lot if cases making interfacing with a user must not be expensive or complex. In others might need additional effort. But if we stand on user site and look from user POV, it hard to jot agree that HA has a huge room for improvement.
1 Like
Thats exactly what I’m saying. I don’t know how this works or even what you mean by “Syntax” in this case. I’m not a developer.
All I’m saying is that as it currently is, you buy e.g. an Ecowitt Weather station and on the Ecowitt App you get human readable wind directions along with a nice animated compass. But on HA you can’t get human readable wind directions without coding in YAML and a compass would require a custom card from HACS that is not easy to set up either.
From a non-techie users perspective this is not and never will be understandable.
2 Likes
THIS exactly - and it makes said software basically unusable for people who have no understanding of software structures and coding.
As a non-developer coming to this forum can be extremely frustrating because some people just tell you that not knowing software / coding is the problem aka. “RTFM” and to “just learn YAML”.
3 Likes
I did do a separate WTH for TTS ability to speak entity states and values from the gui instead of depending on templating. Nobody has read it.
Sure, the integration should provide it out of the box. The goal would not be to simplify templates but to make them unnecessary for this use case, but there are a lot of such cases and time is limited.
There was a lengthy and heated discussion in this WTH about why a lot of people here think this is an important technical distinction even though from an non-techie users perspective it makes no sense
This thread has shown exactly why it makes sense - there are complaints about nonuniform UI between Zwave and Z2A addons and the rest of Home Assistant, which of course cannot be solved by HA because they are not internal applications. There’s definitely improvements to be made in how this is explained, but saying that they’re all basically the same is just going to lead to more confusion.
4 Likes
Or it’s a technical product, like, say, a PCB layout application. Can someone with no electrical engineering rightfully demand to be able to lay out a PCB with zero understanding of track widths, layers, etc.?
It’s not that hard to understand. Do you expect Windows to come with every application you need?
Many users don’t want to read or learn either. Did the first general users of computer had to learn new things to deal with a new interface? They sure did.
What should they have done? The thread you linked explains this.
If HA controlled a whole ecosystem in the same way say Apple does, then perhaps you can make things super easy, but HA is a middleman. You necessarily will have to understand a few things. You cannot abstract everything away (not without some simplification and some loss of functionality).
5 Likes
You don’t need to be a developer.
Again how should you write so that HA knows you mean “get the state of this entity” and not speak out loud “sensor.wind_direction” and how should you write to get the wind direction?
You always have to differentiate between text and programming text what ever the language is. Since we still only use the same keyboard then we must somehow tell the program running/reading what is what.
And seriously is it really that hard to understand what {{ states('sensor.wind_direction') }} is or how to change it to something else?
Looking at developer tools you see a few examples and clicking on the links lead you to the documentations.
1 Like
I’m not offering arguments. I’m simply explaining how things currently work with the questions/statements you directed to me. Sorry if that’s not clear.
1 Like
Lol. Yes, it is! Soso much.
This is exactly the “just do it in YAML” mentality that makes HA inacessible!
If you dont know coding, how would you know what “states” is and why & what all these funny brackets and punctuation should be and how you could change that to something else? And to even be able to do that you first have to install File Editor and find out what a config file is and where & in what indentation structure a template is built.
And btw. for this example its not just changing (or rather adding, because it’s not there to begin with) this:
{{ states('sensor.wind_direction') }}
…it is this completely illegible heap of symbols:
template:
- sensor:
- name: "Wind Direction TXT"
unique_id: wind_direction_txt
availability: "{{ has_value('sensor.ecowitt_wind_direction') }}"
state: >-
{% set dir = states('sensor.ecowitt_wind_direction') | int(0) %}
{% set navDir = [ 'N', 'NNE', 'NE', 'ENE', 'E', 'ESE', 'SE', 'SSE', 'S', 'SSW', 'SW', 'WSW', 'W', 'WNW', 'NW', 'NNW', 'N' ] %}
{{ navDir[ (dir/22.5) | int(0) ] }}
All this is SO INSANELY FAR outside of what one can expect from a normal user, it’s funny to me that anyone would not see that.
@parautenbach posted this a a few post up and i think it really is susch a good explanation of what all this is about:
Average Familiarity
How could anyone consider themselves a well-rounded adult without a basic understanding of silicate geochemistry? Silicates are everywhere! It’s hard to throw a rock without throwing one!
4 Likes
Then HA is not for you.
Seriously.
1 Like
Seriously? This again?
There is an official WTH section where people are encuraged to bring up things that don’t make sense to them so they can be improved - but when they do, this is the answer they get.
And people are seriously wondering why newcomers get frustrated.
I’d say the WTH section is not for you…
4 Likes
If you don’t understand that simple then it really isn’t for you.
Why do everyone think everything is for everyone.
If it’s not for you then it isn’t.
I know soccer isn’t for me and if someone says so then I don’t start crying and say it’s the second time someone said so.
I know I’m not smart enough to be a rocket scientist either.
So just know your limits
I think one can perfectly use and set up HA for a lot of things without ever understanding that. First, it’s really not needed for a lot of basic things. Second, for more advanced things it’s often a matter of copy pasting code shared by someone else.
I guess the problem for some people is the sheer breadth of what HA makes possible, compared to major commercial competition. It feels like you can do everything in HA, and that’s true, but not everything is easy to achieve.
2 Likes
Ok, cool. Imma tap out at this point, no point in wasting anymore time on this thread.
1 Like
The best analogy I can come up with is Excel: You can do many things out of the box, but for advanced things you’ll need to learn macros and functions — and even some scripting.
This might be too philosophical for many, but keep in mind that the more you standardise a solution, the more watered down it becomes. To do the more advanced things, you add new building blocks, but now you just sit with a new language (in a very general sense) and nomenclature to learn. There’s no ideal abstraction at the top. There’s no top.
I’ll say again that the input method (UX/UI) is one thing, and yes, there the tooling can (and I’m sure will be) built out more, but the analytical thinking needed to solve some very specific and custom problems will remain a lot of work — and not everybody has developed that ability. Many people cannot describe in normal language what they want. Some can, but don’t know how to translate it and I’d argue that those that can solve the problem with pen and paper will be able to learn the technical aspects to do it.
6 Likes
Actually it’s HA owners recently to make HA more accessible.
Plz stop discouraging people from using HA or from giving ideas about what should be improved. It’s not the point of WTH. Otherwise the only correct reaction on any WTH would be “it’s open source , program it yourself”
5 Likes
This falls under the be careful what you wish for section to me. New users often show up, demand that Home Assistant be made easier, complain that the learning curve is to steep, the documentation is too confusing, YAML is too hard, etc. There may be some truth to all of those, what they forget is why they were drawn to HA in the first place, the alternatives are too limiting.
The power of HA comes at the cost of complexity, if it focuses only on simplifying the user experience, that will result in less functionality, and less developer interest. Developers, by human nature, focus on what interests them, and the majority are interested in increasing base functionality and fixing problems that affect them. That’s likely not UI issues, since they are unlikely to be seen as an issue to a dev in the first place.
All I’m really saying is that there are already significant barriers to getting changes into HA, let’s not add more in a pursuit of enforcing simplicity.
8 Likes
@ToonK: I couldn’t agree more with your initial post!
That said, I’m honestly baffled that so many Nabu Casa staff, including site admins, expresses their opinion against the posts and seems to prefer “status quo,” acting like everything’s fine and framing it as “you’re just a clueless user who doesn’t get how HA works.”
If you’re part of the Nabu Casa staff, I think you should stay neutral in these cases, IMO
Someone mentioned they’ve brought in more people to address the UI/UX issues, but if it’s Nabu Casa leading that effort, it risks being a case of the blind leading the blind. They really need to involve people who aren’t already steeped in the current culture, IMHO.
3 Likes
No, because Windows is an OS. But lot of software packages bundles Java, getting rid of this dependency during installation…. if you love analogies.
1 Like