I'm about to give up on SettingsPage

[rmasonjr]

I cant seem to control any of the layout of the settings pages. All the controls are just line by line with no functions for indenting or grouping.

Can I not use a FeaturePage for settings which gives me the html page to control layout?
Is there a better way to build SettingsPage with some grouping or layout functions?

[simplextech]

I cant seem to control any of the layout of the settings pages. All the controls are just line by line with no functions for indenting or grouping.

Can I not use a FeaturePage for settings which gives me the html page to control layout?
Is there a better way to build SettingsPage with some grouping or layout functions?

I'm thinking that is "by design" to follow the mobile first experience of how it looks on your phone. You have no choice in the layout other than the order of items perhaps.

[rjh]

The settings page is for simple settings. If you have more complex settings, use a feature page. If you require a user to run through some one time process when the plugin first starts, add this feature page as the only link to your pages. We will link to this page from the plugin setup. Once the user goes through this setup you can then add your other pages. This may not apply to you. If you just need a more robust settings page then just make it a feature page.

I cant seem to control any of the layout of the settings pages. All the controls are just line by line with no functions for indenting or grouping.

Can I not use a FeaturePage for settings which gives me the html page to control layout?
Is there a better way to build SettingsPage with some grouping or layout functions?

[rmasonjr]

Thanks rjh

If you have a plugin that has, say an IP address/user/pass and you want the user to click on a 'Test' button to make sure their entries are correct, I'm guessing that a a FeaturePage would be the best route?

[rjh]

The settings page is more for things that fit under text boxes or checkboxes, namely things that you swtich on and off. It sounds like your items may be more like configuration type settings that require user interaction. That type of thing should probably go on a feature page. Does that make sense?

We do want you use a settings page whenever you can as it makes it easier for that page to appear in other interfaces since its not HTML based.

Thanks rjh

If you have a plugin that has, say an IP address/user/pass and you want the user to click on a 'Test' button to make sure their entries are correct, I'm guessing that a a FeaturePage would be the best route?

[rmasonjr]

The settings page is more for things that fit under text boxes or checkboxes, namely things that you swtich on and off. It sounds like your items may be more like configuration type settings that require user interaction. That type of thing should probably go on a feature page. Does that make sense?

We do want you use a settings page whenever you can as it makes it easier for that page to appear in other interfaces since its not HTML based.

gotcha - thanks!

[stefxx]

I like the ease of creating a settings page. However, something simple as a button should be possible? To fetch some information, test a value or similar? Do we really need to create a feature page for that?

[Michael McSharry]

I had the same thinking and answered my own question on post #2 of https://forums.homeseer.com/forum/de...g-homeseer-jui

[stefxx]

Thanks. So this means for everything just a little more than basic stuff, we have to create a feature page. Oh well.

And isn't Save/Cancel a thing of the past? It seems like a step back from HS3.

[Michael McSharry]

In the Hubitat plugin I moved the Sync button that was on the HS3 settings page to an additional feature under the main device. Previously the only control on the main device was reboot and now it has in addition the Sync that was on the settings page. This approach removed the need for a feature page and provided the user the ability to programmatically exercise the button that had been on the settings page. As an example a midnight event to action this button.

[shill]

And isn't Save/Cancel a thing of the past? It seems like a step back from HS3.

I've been thinking a lot about this, too, and my conclusion is that it's better with Save/Cancel because it limits the traffic and back-and-forth waits for actions, so overall the user experience is better.

[alexbk66]

I've been thinking a lot about this, too, and my conclusion is that it's better with Save/Cancel because it limits the traffic and back-and-forth waits for actions, so overall the user experience is better.

I prefer one-click settings without Save button, but nice to have Undo or Cancel. That's current trend in all Android apps. And who cares about traffic these days?

[shill]

I prefer one-click settings without Save button, but nice to have Undo or Cancel. That's current trend in all Android apps. And who cares about traffic these days?

I'm talking more about the timing, not the volume. Sure, when you're connecting to cloud data centers with redundancy and load balancing, there's little reason for that to matter, but for that extra hop to your home it can be a little more fragile or at least unpredictable. Wasn't an issue before, but if the mobile app is the main interface for people going forward (assuming it gets updated to allow all the missing actions), I can see why a single postback would be preferable.