Improving the "Apps" Experience

[neon cairn]

In my opinion, the "Apps" deserve some tender loving care, from the way that it's framed to new users, to how we address the actual interface itself. This is a thread I have made to determine ways that it could be improved pre-design system.

I feel that being more upfront about what "Apps" are, the fact that they are containers, would be useful to both beginners and experts.

• For beginners, it would explain what the "App" is immediately. While they might not care about it at that very moment, having a fundamental understanding of what they are could contribute to some beginners that may understand enough about containerization to directly contribute back to Home Assistant in the future. Beginners specifically refers to anybody new to HA, and isn't knowledgeable in how to use it.
• For experts, in the short term (as in, if it were implemented today) it would make it far easier to understand what an App fundamentally is for anybody that might not have known but has been using Home Assistant for a fair amount of time and understands how to use it fluently, and may potentially convince some of these users to create Home Assistant "Apps" that others can use. 😄 Of course, it's likely a far smaller demographic that doesn't actually know what Apps are at their core, but for those that originally had no idea, it is a good way to inform!

So, my suggestion is to change the line,
"Run extra applications next to Home Assistant"
to something more straight-forward and explanatory:
"Manage application containers running in Home Assistant"

[median abyss]

Containers is a term we explicitly choose not to use. While it is a distribution method and runtime, there is a bigger layer around it; We do things, general containers wouldn't be able to do (not available in Docker for example). Besides that, we do not want to bring up that terminilogy, as we consider it too technical for end-users in the broader scope of knowledge levels we aim to target.

[neon cairn]

But it's a fairly fundamental part of how they function, right? What part of "container" is not reflecting how they actually function? If they are still sandboxed and unable to escape a "container" without explicit permission then they are a container, no?

[median abyss]

Sure, there are more fundamental technical building parts/blocks to it; it is an internal

The escape part is not true btw. If you think Apps are safe because of the container scape, I hate to bring it to you, but they are a dangerous thing

[neon cairn]

So the containers are allowed to escape and interact directly with Home Assistant's operating system without explicit permission?

[dusty hawk]

I could also see someone be vaguely interested in self-hosting reading about containers, thinking I've got container in my HA, why can't I run XYZ container in my HA

[drifting stone]

I think container is still a technical term. My parents wouldn't know about what a container on a computer is

Other than that, even if you use apps in Home Assistant, you are never confronted with the fact that you're running Docker, except when you are going to look for it

[median abyss]

I think you do not understand the underlying model. Again, they are a distribution and runtime method, the runtime isolation exists, but it can access everything just like any integration can.

[neon cairn]

It's less about the parents, and more about people who may know and understand containers, but have just picked up Home Assistant 😄

[median abyss]

Sorry, those are not the main focus. We target an wider audience; people with a bigger technical knowledge will have less of a problem understanding this.

[drifting stone]

and I think it'd be confusing for them as well. As in, if I have my own application written and packaged in a Docker container, let's say a Factorio server. That would work in Portainer. I believe I need to do more in order to run this in Home Assistant. It's not just "run this container now"

[neon cairn]

Hm. Then brings up the concern about how apps are portrayed in the developer documentation, the introduction should make it clear that has near-complete control over Home Assistant's OS.

[median abyss]

Developer docs != end-user

[neon cairn]

Still an issue!

That doesn't change the fact that the developer documentation is insufficient.

[median abyss]

on what?

that containers can have wide access? That is nothing new

[neon cairn]

Explaining what they are, how they work, and what kinds of permissions they are provided.

[median abyss]

read the Docker docs

we are not here to teach developers how containers work

[neon cairn]

But as a user, if I look up "what is an app in home assistant" the developer documentation is the first result.

So you expect the user to actively seek out information elsewhere? Where?

[neon cairn]

I mean like, I'm not getting anything like that

[median abyss]

So your suggestion is to not index the dev docs?

Or to copy over the end-user docs to the dev docs?

I'm not following your point. We do not control Google, until something is found something more relevant.

Note: this change is fairly new; indexes need time to adjust (takes a few months in general)

[drifting stone]

https://www.home-assistant.io/apps/ I think this does a job of at least explaining what they are

[neon cairn]

I would explain some parts of what the application is in the developer documentation (such as saying that it acts more as an internal service than a container), and the permissions it is granted.

[median abyss]

The permission is defined by the App author. Anyways, this went from a UX issue quickly into something else at this point

[neon cairn]

One thing I should note though, the user is never informed about the dangers of Apps.

[median abyss]

I honestly feel you have a wider problem with the naming, than being here for actual design or UX feedback.

[half fern]

in terms of UX, what are we trying to get at with this? developing an App is a pretty major undertaking, and understanding the underlying topology is probably not beyond the average developer's skill set.

[neon cairn]

But you're saying it can't be easier then?

[half fern]

everything can be made easier, I'm trying to understand the underlying UX issue.

if any.

[neon cairn]

That's a strange argument to make, "Instead of making it easier to understand what it is right off the bat, we shouldn't bother"?

[neon cairn]

It was a point about how users and developers may not fully understand what an "App" is immediately, and have to spend time actually learning about what it is, instead of being told upfront what they are and what they can do.

[half fern]

right, but in terms of UX, we have defined an artifact called App. it has a summary line in the settings, and https://www.home-assistant.io/apps/ exists for a more elaborate explanation. Aside from iterating on copywriting, I'm struggling to see where the UX angle comes in.

are they hard to find? hard to use? do we frontload users with too many abstractions?

it's also worth noting that HA will always struggle to distinguish Integration from App, simply because some of the differences are technical. We can't do anything about that.

"I have a robot vacuum. Do I need an App or an Integration?" is a real UX problem, and HA does what it can to guide you there, I think. Again, copywriting can always be 1% better.

[dusty hawk]

Even Google is struggling in that regard, have you ever tried to pair a third party device to Google Home? You don't do it through "Third-party connections" but rather "Works with Google Home" inside the "Apps and Services" Menu

[south delta]

There's some weird things too, like adding a Matter device via the Matter integration requires the Matter Server app. That's… partly hidden on HAOS because the flow for adding the Matter integration will install the Matter Server app for you, but that doesn't help folks with a Docker installation, and makes the integration/app difference kinda tricky.