Trying to decide between ISY, Castleos and CQC

If you like setting up all that complex A/V equipment and programming inputs a simple HA system will be right up your alley. With ISY994i you just plug it in and start using pulldown menus to control things.
 
Insteon can do remote control as devices can be interconnected into "scenes" without any smart box, also. You just can't do any logic, like "only if the light is on". There you have just written an HA  program.
 
Pull down menus are still a thing?? :huh:

It would be either pulldown/up/across/flyout menus or either run time errors or compile time errors.
 
Did you have a better way?
 
LarrylLix said:
Did you have a better way?
 
I meant my previous comment as a joke, but here's a serious answer to your question: contextually aware user interfaces and natural user interfaces. 
 
LOL
 
Those styles of operation sound really cool but somebody still writes the programming to do these higher level coding functions using syntax checking, proofing, else they use pulldown menus to avoid the needs for all that.
 
I think most HA systems today use pulldown menus. My 1980 HA X10 software did and my current ISY994i does and keeps fingers off the keyboard so that we don't wear them out. :)
 
LarrylLix said:
LOL
 
Those styles of operation sound really cool but somebody still writes the programming to do these higher level coding functions using syntax checking, proofing, else they use pulldown menus to avoid the needs for all that.
 
I think most HA systems today use pulldown menus. My 1980 HA X10 software did and my current ISY994i does and keeps fingers off the keyboard so that we don't wear them out. :)
 
Actually it's pretty rare now in HA interfaces... You won't find a single one in CastleOS, nor as far as I know in any of our contemporaneous competitors Like SmartThings, Wink, etc... 
 
You have to have a means for selecting among a set of possible values, when that set is a small enumerated list or a small numerical range, and you have to do it generically (i.e. not something that can just be hard coded as choices.) Plenty of programs use some sort of popup or drop down list or combo box or spin box for such things. No matter what you use, it's basically some variation of that. Even if you dynamically generate the interface every time to present the available options, that's still basically the same thing, except it takes up a lot more space. Of course some of those schemes also allow type in matching along with a drop down, but unless you expect the user to memorize all of the possibilities, presenting the list is still necessary.
 
A drop down list (aka combo box) isn't a pull down menu. This is a pull down menu:
 
100+-Excellent-jQuery-Plugins-for-Navigation-and-Menus-Stunning-Mesh-2011-12-03-15-58-26.png
 
Oh, I thought you mean drop down lists in general. Though, to be fair, it's not THAT different when you use a popup context menu, which is extremely common.
 
And, also to be fair, for the less technical user the context menu might be less obvious since there's nothing to visually prompt you to interact with a thing. There are lots of programs that have really obscure popup menus all over the place that you might never find except by accident.
 
Well, like was asked, what's better than that? Contextual awareness in the UI removes the need for that. Companies like Savant take it to the next level with a photo-based GUI. Want to turn on that lamp? Tap the lamp in the picture you took of your living room. (For the record, I'm not sure that's the best solution, but it's a solution.)

UIs like we see on a lot of legacy home automation software are going the way of the dinosaur. They're not only confusing, they're less efficient. The trade off is building contextually aware UIs is harder and more costly to develop. It's the same change Microsoft made in dropping the pull down menus in favor of the contextually aware "ribbon"... 
 
Photo based would be extremely limited. A lot of the stuff you want to control isn't visible anyway, and a lot of the things you want to do wouldn't be invoked by anything you could take a picture of, and of course some that are might not be visible from any given angle.
 
Though of course any automation system that has a customizable GUI could do that if the customer wanted. With CQC you'd just drop transparent buttons on top of the objects in the picture. It's commonly enough done for home layout based screens. I'd argue that a home layout type scheme is superior anyway since it doesn't have any of the issues that a picture does.
 
LarrylLix said:
Just semantics.  A menu is a list of items to pick from. The rest is just mechanics of presentation.
 
Sorry, that's just not true. There are literally scholarly articles on this... It's easy to say when the mouse is your navigator, but touch is a different animal.  What is true is often the lines are blurred, but there is a paradigm change happening... 
 
Back
Top