Some observations

[happnatious1]

Setting up my development environment was pretty straight forward and my Monoprice amp plugin seams to be running fine.

The interface is very modern looking and resizes nicely even on my cell phone. It is still however using alphabetical or lexicographic sorting so numbers don't sort as one would expect. My plugin name is "Marquis Monoprice Amp" which is a little long, when going to plugins-->Marquis Monoprice amp-->config it has some trouble showing on a cell phone.

On HS3 I could change a source input with a single click, on HS4 it takes 3 and the visual clues to do it aren't obvious. Maybe an icon to go to a control page for a device? Just spitballing.

[rjh]

Right, in HS3 all the child devices and controls where all in view, but that made the device page very messy and confusing. New users are confused by that and expect a physical device to be viewed as a physical device. I am open to ideas on the child control. Note that there will be an option to select a "primary" device which will be the main device in the view. Right now it tries to pick the primary based on some information it can glean from the device. Also, the plugin author will have the ability to set a primary when the root device is created as they know best which one that should be (a motion sensor might pick the motion device, rather than battery or temp).

In your case it looks like you might have many children, all important. We thought about making the child devices clickable, this would bring you right to the control page for that device, but its hard to click on those icons on mobile. So that is why you see that extra landing page that lists all the children.

You might notice an icon on the device page that changes the view to list view. Possibly that view, or a similar one, could list the devices with all the children and controls (maybe just a checkbox to exand the view). Also note that the entire HS4 UI is done with HTML pages and "liquid" like tags. So adding a new view can be done without any changes to HS.

Setting up my development environment was pretty straight forward and my Monoprice amp plugin seams to be running fine.

The interface is very modern looking and resizes nicely even on my cell phone. It is still however using alphabetical or lexicographic sorting so numbers don't sort as one would expect. My plugin name is "Marquis Monoprice Amp" which is a little long, when going to plugins-->Marquis Monoprice amp-->config it has some trouble showing on a cell phone.

On HS3 I could change a source input with a single click, on HS4 it takes 3 and the visual clues to do it aren't obvious. Maybe an icon to go to a control page for a device? Just spitballing.

[alexbk66]

I disagree that "expect a physical device to be viewed as a physical device" - many devices have a root parent which is often a bit useless, but child devices are equally important.
One example - ZWave multi sensors - the root just shows the connection status, but then there are temperature, humidity, motion, luminance, etc.
Another example - my Google Calendar plugin. Same story - root just shows connection status, the child devices for each calendar event are equally important
Another example - RaspberryIO. List's going on....

[alexbk66]

Another example - BLCpuAdvisor - each child shows a monitored process, there's no even root device...
Actually, most plugins I can think of use same philosophy... "The physical device" rjh is talking about is more an exception. Even physical devices with, say, two or more relay outputs (quite common) - how do you switch them on/off?

[rjh]

I don't know what you are referring too. Have you looked at the new HS4 device view? We are presenting devices as a single device with all child devices viewed from within that device. The user does not see a root, children, or any of the underpinnings of the software. This is what I am referring too.

I disagree that "expect a physical device to be viewed as a physical device" - many devices have a root parent which is often a bit useless, but child devices are equally important.
One example - ZWave multi sensors - the root just shows the connection status, but then there are temperature, humidity, motion, luminance, etc.
Another example - my Google Calendar plugin. Same story - root just shows connection status, the child devices for each calendar event are equally important
Another example - RaspberryIO. List's going on....

[alexbk66]

I don't know what you are referring too. Have you looked at the new HS4 device view? We are presenting devices as a single device with all child devices viewed from within that device. The user does not see a root, children, or any of the underpinnings of the software. This is what I am referring too.

That's exactly what I'm referring to - in HS3 we can see all child devices values. In HS4 we see only one device (root/parent?) - but for child devices we see only icons?

[rjh]

I may add an option to display the status on the grid view. If you switch to the list view the status is displayed.

Or I may display the status on the desktop view but keep just the icons for the mobile view.

That's exactly what I'm referring to - in HS3 we can see all child devices values. In HS4 we see only one device (root/parent?) - but for child devices we see only icons?

[happnatious1]

That's funny, I didn't even notice there was a list view.

What about allowing the developer to change the icons for children based on what they do. You would have to provide them of course for a consistent look. Then based on which child is selected, the control underneath changes to represent it. For instance when I click the volume icon for a zone it changes to a volume slider underneath instead of the ON/Off control of the Parent. Or maybe just a link for a device expanded view that opens a parent along with all it's children in one full page view.
Again, just spitballing.

As I play with the interface a little more it kinda does some of this already.

[alexbk66]

I may add an option to display the status on the grid view. If you switch to the list view the status is displayed.
Or I may display the status on the desktop view but keep just the icons for the mobile view.

Even list view is not too helpful in case of my GoogleCast plugin:
1. Controls for main (root/parent) device are not shown, even if I click "CONTROLS" button.
2. Controls for child devices are not shown, only status. So for example volume controls are not available.
3. Long status string (i.e. URL in my case) moves all other child devices out of view. Also the URL isn't clickable.

[rjh]

What you propose is possible, and most can be done with changes to the HTML file, so HS would not need a change. We will take a look at the options here. I understand that having to click more than HS3 to get something done is not a plus.

What you want to do is click on a child then have that child be the primary so its controls are no visible by default. You will have an option in the device properties to set the primary device, but what you propose is a nice shortcut. Mobile is the issue here as those icons are not an easy target on most phones. But we can make them bigger.

That's funny, I didn't even notice there was a list view.

What about allowing the developer to change the icons for children based on what they do. You would have to provide them of course for a consistent look. Then based on which child is selected, the control underneath changes to represent it. For instance when I click the volume icon for a zone it changes to a volume slider underneath instead of the ON/Off control of the Parent. Or maybe just a link for a device expanded view that opens a parent along with all it's children in one full page view.
Again, just spitballing.

As I play with the interface a little more it kinda does some of this already.

[rjh]

We have done some messing with the status. Ideally, the status should just be a short string. But I know some plugins put a lot of info in the status like weather maps, news, and so forth. So in your case, that URL should probably be clickable and open a dialog with the content.

The "Controls" button does not do anything yet, so that is expected.

Clicking on the top row of child devices will bring up a list where you can get at the controls. Try this on the grid view, the list view may not have this added yet.

Even list view is not too helpful in case of my GoogleCast plugin:
1. Controls for main (root/parent) device are not shown, even if I click "CONTROLS" button.
2. Controls for child devices are not shown, only status. So for example volume controls are not available.
3. Long status string (i.e. URL in my case) moves all other child devices out of view. Also the URL isn't clickable.

[sirmeili]

So I'm still looking into it, but this new interface hides all the values of child devices. For my harmony plugins, that's no big deal. There is really only 1 primary control/status in the device group. However, in the screenshot above, there are multiple "informational" devices I would want to see on an interface. I guess you could destroy the grouping and maybe that makes sense in an "HS4" world. Is this what the intention was (if so, I'm good with it, just asking for clarification)?

A good example is a thermostat. You have multiple devices with separate status/control values, but they should make 1 unified device interface?

Is it too early to create a way to have plugin developers "map out" their grid device with the status/values and how they show? That would be optimal for the best user experience (UX).

[rjh]

You are correct in that we want to present devices as a unified group as that is what the user would expect. As mentioned you can see that with the thermostat devices. We can build that in a special way because each child device has a device type associated with it. So we know when a device is a setpoint, etc.

In your case we do honor the row/col specification for the status pairs. So you can specify how the primary device displays on the device page. We limit the max controls here to 6 formatted at 2 rows with 3 controls each. If there are more, then the controls are displayed on a separate dialog (not coded yet). Do you need to display more than 6 controls? Does a row/col layout not work? If not, we can discuss a better way to display. We are still in discussion with other media control plugin authors about how to layout and control media devices. Using device types might be a way to note common controls like play, pause, artists, etc. But in your case, you can probably have a dozen different controls so it may not work there.

So I'm still looking into it, but this new interface hides all the values of child devices. For my harmony plugins, that's no big deal. There is really only 1 primary control/status in the device group. However, in the screenshot above, there are multiple "informational" devices I would want to see on an interface. I guess you could destroy the grouping and maybe that makes sense in an "HS4" world. Is this what the intention was (if so, I'm good with it, just asking for clarification)?

A good example is a thermostat. You have multiple devices with separate status/control values, but they should make 1 unified device interface?

Is it too early to create a way to have plugin developers "map out" their grid device with the status/values and how they show? That would be optimal for the best user experience (UX).

[sirmeili]

rjh Since a single device is limited to 1 value and presumably 1 control of that value, then I am limited in what I can "show" to he user. Think of the weather apps out there. So 1 tile per device now to show temp, wind dir, etc? I'm not saying I can hand you the code to do what I'm asking for, but what you need is a way for a developer to template out a tile. If you need to be able to support "device types" that are user defined, then allow it.

For plugins like the chromecast plug-ins, plex plugin, etc, it should be possible to show values/controls of more than 1 device on a tile. Otherwise you are falling into the trap of form over function. The functionality should come first, then make it look pretty.

having more than 1 control of 1 device on the tile isn't the issue (though there are times I can see where it is like "remote functionality" for media device/TV), it's belng limited to the root devices control/status on the main are of the tile. Once again, think Thermostat and don't limit your design by the preconception that only thermostats can benefit from that design.

[alexbk66]

Talking about thermostat device - my HeatmiserNeo plugin in HS3:



And in HS4, how do I use it???