LOL right .. the arrow is covering the word virtual < never mind !
1 Like
There is a lot more history behind how these apps came into existence that goes back 10+ years. Some of these apps existed even before Hubitat was born. They are truly an evolution based on feedback from hundreds upon hundreds of users before you. They have been merged then split then consolidated to best serve our users' needs.
While consolidation may seem the solution, in reality disambiguation for a more targeted purpose is more effective in many cases.
7 Likes
There may be a case for providing additional resources to new users that can help them understand some of the differences between some of the apps and situations where they are best suited, but once people find what works for them the pay-off for smarts around app selection or refining the options on-screen would likely be minimal. It would add extra complexity for the development of the platform and may require extra steps, as others have commented on.
Also, peoples choice of which app they want to choose may not always be based on what they are doing, but other variables such as the complexity of the automation, the complexity of the app itself, or even just wanting to keep automations together under the one spot.
6 Likes
This 100%.
3 Likes
To continue on from my last post, I am an advocate for providing information at the point it may be required, so I would not be against some optional wizard or matrix or something else that would present the information within the HE interface, assisting people in making their choice of app, but for those that know what they want, they can still go straight to the app they want, like we do currently.
2 Likes
As a professional software developer, this thread reminds me that it is important to get the feedback and opinions of many users, and then make the best decision you can, using the information you have and that the users may not have.
Every user has needs that aren't met by the system. Most users believe they know what they need. Many of them believe they know what everyone else needs. Some of them think everyone else thinks and works the same way they do.
12 Likes
Yup.
And this is why choice is good. As is being given the tools needed to create your own solution. For some, that means using a built-in or community app, or writing their own app in Groovy. For others, it means making use of MakerAPI to use an external automation engine.
And, in any event, finding a tool optimal for one's use is a poor reason to prevent others from using other tools.
7 Likes
One of the things I mentioned many moons ago is the lack of a consistent naming convention for 1st party Hubitat apps / Integrations . Eg we have
Amazon Echo Skill
Home kit Integration
AirPlay Integration
Google Home Integration Helper
ChromeCast Integration
Basic Rules
Rule Machine
Hubitat Dashboard
And so on..
My suggestion was to add the OEM name to all of the 1st party integrations e.g.
āApple HomeKit Integrationā,
āGoogle Chrome Cast Integrationā.
It keeps the various brand integrations together making them easier to quickly find if needed.
In addition it might be a good idea to add collapsible sections to the Apps list eg
-
Hubitat Automation Applications:
-
Hubitat Device Integrations:
-
Community Automation Applications:
-
Community Device Integrations:
Or something along these lines - this would IMO make navigation easier, especially for those of us with a lot of apps installed.
I would suggest that it would make it easier for new users to comprehend the list of apps too and allow Hubitat to pre-load more of them by default without risking visual overload.
/2.5c
10 Likes
Yeah that would irritate me like mad
I do sometimes choose which app to use based on a desire to categorise and group my rules. Talking of which, a.n.other smart home system has recently introduced user categories and tags to group devices and automations.
2 Likes
Yeah, I mentioned the HA update on another topic the other day. I liked the look of it, from what I saw on YT.
1 Like
This happens in other fields too (I donāt work in IT).
It can be a real challenge to work around.
4 Likes
I agree, and is kinda my point. Take tax software as an example. Most have two options, a wizard and a form. Generally they assume most people want a wizard, so that's the default, but you can change it. There's not two installations or two executables. In Hubitat, offering options to switch how the input works does add yet more complexity (especially since the UI is so limited) - I don't deny that. So I'm not saying, in Hubitat, it always must be better being inside an app rather than two apps/child apps. But, alls I'm suggesting is that having a choice to branch inside an app really.... not some horrible burden some seem to make it out to be. Rather than, hypothetically, selecting "Easy Rules" vs "Rule Genie" (which gets the the exact same endpoint), could just as easily have a choice at the top, and/or it branches one way or the other.
(Again, I've backpedalled on it being a mistake by Hubitat, but still urge them to expand the UI capabilities to make really flexible UIs more practical.)
(This will sound totally entitled, judgemental, etc, but just IMO.) I think that's where Hubitat devs messed up. Totally 100% understandable - they don't have resourcesfor prototyping and focus groups, and instead they built a product that works.
But fundamentally, planning ahead is what I'm recommending. If they want to encourage developers to do ease-of-use, lay out a plan to do that. If they want focus on end-user experience themselves, do that. (I am very possibly totally wrong) but it seems from an outside perspective the incremental improvements they make are [not] towards any specific end-goal. Rather than just "make it better", I'm suggesting they focus there efforts (and on what depends on where they want to take it).
And to Hubitat/bobbyD, I think teasing us with the overall goals isn't the same as telling us about in-progress development. If nothing else this thread proves we (the community) would like to have a place in that discussion.
I don't think any of us are aware of your background and if any of your skills have given you these opinions. They are certainly interesting opinions, and varied too. 
But without more insight into the quality of analytical skills that form the opinions, it's hard to differentiate between rant and reason. 
As my buddy Steve has said:
I'm sure there are Communities in all sorts of realms that wish they were in the path of decisions. Hubitat doesn't owe us that, just like Samsung doesn't owe us that.
11 Likes
I wonder the same thing too! 
But it's the ones who claim to know for sure that are most definitely full of crap 
And I'd imagine the same is true for Hubitat devs. They may be geniuses in their field, but that doesn't mean they have all the answers, so... hopefully my (and our) opinions help in some way.
1 Like
I'm happy that I get the feeling when I slam my shoulder into this large ship called Hubitat, that it feels like I moved it. It's entirely unlikely, but I really feel it in my shoulder.
1 Like
From your posts it looks like you're asking one entry point that you can branch off to the appropriate app depending on your requirements.
Have a look at webCoRE. 
(I did mention this above and this post is tongue in cheek BTW). 
I think that knowing the background of where Hubitat became an idea and then reality (same for many apps we use like Rule Machine). It all started with a bunch of tinkerers that love what they do and love to tinker around but were fed up with existing systems that were just not working as advertised, so they decided to make a better machine that just works. This is what made it's reputation of a solid local system that did not necessarily needed internet to work (unless you chose to use cloud connected devices).
Now that the reputation of Hubitat is made as a solid machine and that the main stream users are starting to take notice, they need to shift a big part of there focus on making the experience for the common person more enjoyable and easier than what the tinkerer will tolerate (or even enjoy like those HA fan guys) before the competition takes the lead.
Seeing that they are now starting to actually change this focus over to the user experience with some changes that have already been done (adding rooms, collapsible lists in apps and more, device page with user selectable columns, etc.) and other changes that are in Beta. I believe they are moving in the right direction, but will this be fast enough for the growing market and new hubs coming out that are clearly more appealing to the common user, we will have to wait and see.
5 Likes
Not sure what you mean by "tongue in cheek" , if I'm just missing the joke, but webcore, at least when I used it about 4 years ago or so, was not the sort of branching I mean.
By branching, I mean like... (As a prior example) you open a tax app. You don't (necessarily) know beforehand which forms you need. You start with a wizard. Maybe you follow it all the way through. Maybe you click a button/link to go to a form view. Maybe on a sub form, you click a help button, and that prompts an abbreviated wizard. In other words, ideally, UIs should adapt to the momentary needs of each user, not the other way around. Of course, putting that in practice is way harder to do than to say, and makes it all way more complex to design.
1 Like
