What is wrong with CQC?

[Dean Roddey]

It wouldn't have made things any better for you, and it would have made things a lot worse for me, so I don't see the point in it. It wasn't like it was a lot of work, and I didn't end up with a hodgepodge of third party bits and pieces to create it. It's all integrated into my existing build infrastructure nicely, and I can use my own tools to create the intermediate bits, which makes it nicer.

 

[123]

DISCLAIMER: I haven't looked at CQC for several years. My comments below are based on an impression I developed years ago when I evaluated it for my needs. The CQC Field Browser image (below) is a screen-grab from a recent video tutorial. It's appearance and functionality support my initial impression.
 
(Click images to magnify.)
 
It's been awhile since I evaluated CQC but the impression that has remained is that it doesn't feel like a native Windows application. It's the same reaction you get to using a Linux app ported to Windows; things feel 'off'. The experience begins with the installation and continues throughout the system. "Windows Uncanny Valley".
 
OK, given enough time and practice, I could get used to the 'fish out of water' look. However, I can't say the same for the extremely modal nature of the application. It luxuriates in multi-level dialog boxes and turns a blind eye to graphical representations of its data (I'll settle for a tree-view of Devices). Modal dialogs create hurdles between the user and the data; they interfere with "flow". Here's a simple example of what I mean.
 
The CQC Field Browser lets you browse a Device's fields. The fields are displayed and their values are visible but cannot be altered interactively but through a modal dialog-box after clicking the "Change Fld..." button. Beyond its modal nature, I don't understand the purpose of displaying a field's name and value twice (in the list and then below the list). At minimum, show all of the field's attributes in the list and make them interactive (i.e. editable).
 

 
Compare it to this property browser. I've selected "Receiver" in the Explorer pane (showing a tree-view of devices) and all its properties are listed in the Properties pane. I can view them Categorized or Sorted alphabetically. I can alter any property's value interactively (unless it is gray indicating read-only).
 
 

 

• "PowerState" is a "Boolean". If I click the option-box the value becomes "On".
• "Volume" is a "PerCent". If I click the value I can drag its slider.
• "TunerCommands" is a "MultiValue". If I click the value it displays a drop-list with multiple choices.
• "Current Source" is an "ObjectReference". If I click the value it opens a dialog-box allowing me to select an appropriate AudioVideoStream source.

 
If I select a property, its description (if any) is displayed at the very bottom of the Property pane (see ELK M1_Panel example below).
 

 
None of this is ground-breaking. The examples come from an HA product developed 15 years ago (and was discontinued 9 years ago). It also uses interactive diagrams to depict equipment connections. 
 
I won't suggest that CQC be revised to be become more "Windows-like" but I will suggest future versions attempt to minimize modal operations.

 

[Dean Roddey]

I get all of that, and don't disagree. For years we've been in a situation where we were missing core functionality that had to get done. If it came down between a less than perfect but workable interface and a big chunk of functionality required to meet people's needs, we had to go with the latter. But, those days are coming to an end, and the product is starting to get to the point where it's got all the features it needs, or at least any missing ones are not more important than exposing what we do have in a better way.
 
It may be that after we get 4.7 out, that we start on 5.0 and that it be almost purely about improving the tools, and also I'm sure continuing to take the auto-generation system further.

 

[dgage]

I get all of that, and don't disagree. For years we've been in a situation where we were missing core functionality that had to get done. If it came down between a less than perfect but workable interface and a big chunk of functionality required to meet people's needs, we had to go with the latter. But, those days are coming to an end, and the product is starting to get to the point where it's got all the features it needs, or at least any missing ones are not more important than exposing what we do have in a better way.
 
It may be that after we get 4.7 out, that we start on 5.0 and that it be almost purely about improving the tools, and also I'm sure continuing to take the auto-generation system further.

 
At this point I would agree.  I'm not one that pushes the functionality of CQC as I use just a small part but at this point I would personally benefit most from CQC reaching a wider audience...the RadioRa2 bug being one example that really didn't get addressed until someone else reported the same problem I had been seeing for a while.  I would also expect reaching a wider audience would need additional drivers so the whole user commnity would gain there too.  So I think your plan for 5.0, along with a marketing push based on the new and improved CQC, would help you as well as all of your users.  You've got a great core, it's now time to take it prime time and I wish you nothing but success in making that happen.

 

[123]

BTW, I'm not singling out CQC for having a "high-friction" UI. It's far from alone in this regard.
 
I posted a similar suggestion on the Elve forum in 2012. I went as far as to create a mockup showing how to eliminate a modal dialog-box.
 
Imagine a spreadsheet where each cell is modified via a dialog-box and you get a sense of what "high-friction" means.
 
In the image below (click to magnify), the left-hand side shows how the product displays an array. The array's elements are shown in a list (obscured by the dialog-box). However, you cannot simply edit the displayed values directly but must do so via a dialog-box. 
 
The right-hand side shows a mockup of the same product where the array values can be altered directly without the hurdle of a dialog-box.
 

 

[Deane Johnson]

In the example "123" included in post #167, notice the abbreviations in CQC and the full descriptive entries in his example.
 
I can probably guess that DevSim might mean Device Simulator, but throughout CQC there is no way to figure out what they stand for.  I've bitched about this from the beginning of my time with CQC, but  the abbreviations are a major deterrent for many individuals not being able to use CQC.  It certainly contributes heavily to the conception that CQC has a steep learning curve.

 

[Dean Roddey]

Well, DevSim is a driver moniker, so that is a user provided value. You could call it whatever you want.
 
I will say that, once you get beyond simplistic systems, it becomes really impractical from a performance point of view to just have a screen in which every field in the system is presented. We have systems out there in which there could be thousands of fields and the overhead on the overall system to both grab all of them and keep them updated just because you opened this one screen is not really practical. So there are some real world reasons that a program that has to be able to scale up quite large can't always take the same approach as a smaller, simpler one.

 

[Deane Johnson]

Dean, I understand the user's ability to use his name of choice, but many of the CQC built in function choices are heavily abbreviated.  That's what makes it tough for a user to decide what choice they should make for a desired result.  

 

[123]

My guess is that the complexity of the average automated home falls in the 'simple to moderate' category. The device with the most fields is probably the security system and even 15 year-old HA software has no trouble displaying a device with a few hundred dynamic fields.
 
The important question is "Which market are you trying to expand?" If your sales are driven by the Pareto principle, where 80% of your sales come from 20% of your clients (namely the commercial clients with sky-high field-counts), then CQC must forever cater to their special needs.
 
If the goal is to expand the 'simple to moderate' market then CQC ought to be more appealing to this demographic. Compromises made to handle a gazillion fields are lost on the average HA enthusiast (more so to vanilla consumers). All they see is a product that doesn't take full advantage of UI concepts developed over the past 15 years. In other words, a product with a dauntingly steep learning-curve and, ultimately, a low acceptance rate.
 
 
To put it into perspective, here's the UI for an HA system that could handle tens of thousands of devices and hundreds of thousands of fields. Except for fans of MisterHouse (no $$$ to be found there), find me the market that wants this UI.
 
> list devices
ELK_M1
TableLamp
LivingRoomThermostat
 
> status TableLamp
Device: Dimmer
Name: TableLamp
State: ON
Brightness: 50%
 
> set TableLamp Brightness=10%
TableLamp: Brightness=10%
 
> createdevice Light=FloorLamp
error: No device of type "Light".
 
> help device type
No help for "device type".
 
> help devices
Devices can be of the following type:
Dimmer
Relay
Thermostat
SecuritySystem
...
 
 
 
 

 

[Dean Roddey]

If fail to see how displaying hundreds of fields at once is particularly good to begin with. The time that anyone would spend in such an interface, manually changing the values of fields, is fairly close to nada, so worrying about it overly much is not a good investment of time. The point of the automation system isn't manually tweaking fields by hand, it's creating logic and UI for the end user of the automation system to use it. All that field browser is for is for some occasional spelunking and debugging, nothing more. No actual end user of the product (meaning the people who actually use the created automation solution) is ever going to use it.
 
I understand the point, but you have to keep perspective on things as well. Putting in a huge amount of effort to create an interface that gets very little use is sub-optimal.

 

[123]

If fail to see how displaying hundreds of fields at once is particularly good to begin with. The time that anyone would spend in such an interface, manually changing the values of fields, is fairly close to nada, so worrying about it overly much is not a good investment of time. The point of the automation system isn't manually tweaking fields by hand, it's creating logic and UI for the end user of the automation system to use it. All that field browser is for is for some occasional spelunking and debugging, nothing more. No actual end user of the product (meaning the people who actually use the created automation solution) is ever going to use it.
 
I understand the point, but you have to keep perspective on things as well. Putting in a huge amount of effort to create an interface that gets very little use is sub-optimal.

 
If I may summarize the points you've stated:

1. Displaying many fields is not optimal.
   Depends on how they are used in the application but I take it CQC doesn't need this capability.
    
2. No one would spend much time tweaking field values.
   General tweaking no but for exploring, experimenting, testing, and understanding how the device's fields operate ... but I get your point.
    
3. Creating automation logic and the end-user UI is the objective.
   Yes and making the means of doing so as frictionless as possible.
    
4. Inefficient to create an interface that isn't used often.
   Depends on the effort needed to create the interface. I take it what I described above cannot be implemented quickly and so is not an efficient use of your time and resources.

 
 
I've focused on the Field Browser. If it is not representative of the rest of the application then pardon my mistake. However, if it is typical of what one can expect elsewhere then creating automation logic and the end-user UI may be equally "high-friction".
 
The application used to define the devices, create the logic, and construct the end-user UI is what prospective buyers see. If it doesn't seduce them within the first few hours they will move on to something that will (as it was in my case).
 
 
I am open to the possibility that exposing fields (a.k.a. properties) may not be as important in CQC as it is in other applications. I won't bore you and others with why properties are displayed so prominently in Premise Builder. Suffice to say that Premsie is fully object-oriented and uses a highly visual paradigm to represent its objects. As a result, it is important to "see" an object, its properties, and methods. FWIW, it looks vaguely like Visual Studio (well, a really old version of VS).
 
 
Dean, I wish you good luck with whatever direction you choose to take CQC. 
 
 
 
 
 
 
 

 

[Dean Roddey]

Field are accessed all the time, to reference them in action commands. But that's not done via the field browser. When you access fields in a command, you get to them via a different interface, and the fields displayed are filtered for what is valid for the operation you are attempting to do. It's not for general spelunking and changing the values isn't part of that interface.
 
It's not that the field browser couldn't be turned into some sort of super-efficient thing, giving sufficient work, but it would also require work on the back end. Again, it's a networked product, there could be hundreds of drivers out there, spread around on various machines. We just have to be sensitive to the load that can put on the system as a whole (which can be in use by other people in a production environment at the time, it's not always just one guy who is either using it for this or that at any given time.) It's not just going out and possibly grabbing the values of many hundreds of fields, but also it's keeping them up to date efficiently as well. And, given that it's networked, it's quite possible that more than one person in the network may be using that interface, so you can't assume it will only ever happen in isolation. All these things have to be taken into account in this type of system.
 
I certainly don't claim that any of the interface is going to win any design awards as is. It was challenge enough to get it done at all, in conjunction with all of the stuff behind it that it's providing access to. But, as I said, we are close to the point where, despite the fact that someone will always complain that there's something it doesn't do, that we can concentrate less on new functionality and more on how we expose what we have.
 
I would also have to mention that, not until our move to our new V2 driver model could some of what we would want to do have become possible.
 
I would also point out that, if you plopped that image above in front of someone who new nothing about Premise, and possibly little about automation, he wouldn't know what in the world it was or have a clue how to do anything useful with it.

 

[Dean Roddey]

BTW, our new self-extracting installer just went up with the latest beta version, so we'll see how much of a difference it makes to folks. Of course that also means any videos or documents that refer to the installation process will have to be updated or redone.

 

[jdk972003]

I believe 123 is stating something I could "feel" was inherently different about CQC but could not put words to as I am not a software person.  i.e. CQC just does not "work" like a windows user would expect. And software has to work as a user expects or it simply is not easily adopted.
 
I stick with my original statement,
 
Get someone (preferably who is good at interface design) to provide you UI feedback.  Then trust them and you find a way to implement their feedback.
 
And you know there is a LOT of software that has a simple and advanced mode.  So they can hit all markets.  Maybe consider that route.
 
Only thing the "simple mode" would do at first is  to get people to bite in that first 1 hr use scenario.

 

[samgreco]

Perhaps an idea might be to create a simplified scenario that a typical user might use and then the folks that represent relevant products could do a demo video of how to achieve that with their product.  This is how I would see it happening:
 
Assume that the product is installed.  I realize that installation is part of all of this, but maybe that can be separate.
 
Install the necessary drivers for the below items
Create a setup that has 2 rooms.
Use a typical multi room audio setup like Russound, Nuvo, Xantech, etc.
Each room has media (music only playback?).
Each room has 2 lights.
One room has TV with a couple of things plugged into inputs.
Create media management for music
Create a scene or 2 for lighting.
Show how to play music in each room individually and then how to combine to play the same content.
 
There could be more or less stuff.  It could be completely different stuff. Whatever everyone thinks makes sense.  But if you could see the way each product achieves the same thing, it could shed a lot of light on usability of each package.