UD Mobile - Customer Mode

[Adolfo]

In order to let customers use the app is necessary a "Customer Mode" where no changes are available and is password protected. To simplify the user experience I suggest just Programs and Scenes tabs - Scenes could be a group of devices (as now) but also one can create a scene with a single device in an scene. In that way the user just see 2 tabs simplifying navigation. Maybe a 3rd ( Settings with a lited menu as reboot, customer mode and any other thing that the customer could need limited to things that will not modify the functioning or cause intervention of the integrator-vendor. 

In short, a customer view limiting editing with a password.

Edited August 9, 2022 by Adolfo

[Javi]

Hi @Adolfo,

Part of your request is available at this time with Edit Locks.

Any folder, device, status, and command can be hidden.  After setting the lock, edits are disabled along with ISY Admin controls (Admin-Tab) and App Settings (Settings-Tab), with the exception of the edit lock pin entry.

For the simplest user experience add devices, commands, and folders to the Favorites Tab, hide irrelevant commands and status.  Then change the app icon to open to favorites.  Hide folders on the Home Tab if desired, then lock edits.

[Adolfo]

Yep kind of works like that. 
I’ll suggest to have in mind that user programmer and user customer needs are different things. For example, as customer you want to have a few tabs with “favorites” as will be easier that have 40 programs on one long list. That tab should have a way to identify it . Like outdoor , a/v or any other thing. 
As customer the less options the better. 
Txs -a

[Javi]

Hi @Adolfo,

Understood,  however for every user who wants a simpler interface there is one who wants more features, micro adjustments, and would prefer to not have to use the desktop Admin Console.  So we must have a balance.  We will keep your requests in mind as we continue development as we do have other UI improvements on our list.

Currently the Favorites Tab is intended as the simpler interface.  Adding folders in Favorites allows for  groups such as "outdoor" "a/v", ect. which will open to a new favorites window, thus limiting the number of items in the list. 

 

[apostolakisl]

This goes along with what I was saying regarding a simple interface. One where a switch looks  like a switch and a thermostat looks like a thermostat. 

[lilyoyo1]

5 hours ago, apostolakisl said:

This goes along with what I was saying regarding a simple interface. One where a switch looks  like a switch and a thermostat looks like a thermostat. 

I agree 100% with this.

 

[apostolakisl]

Just now, lilyoyo1 said:

I agree 100% with this.

 

To put a story to this.  I have set up my church with Insteon and have given access to the priests and staff.  Trying to teach them to use it is a bit overwhelming.  And there are a lot of me having to say "don't mess with this, and don't mess with that"  Like if you open a switch, you are presented with ramp rates and on levels and all kinds of settings which are confusing and should just not be there except when in "advanced" mode. 

[lilyoyo1]

On 8/17/2022 at 11:26 AM, Javi said:

Hi @Adolfo,

Understood,  however for every user who wants a simpler interface there is one who wants more features, micro adjustments, and would prefer to not have to use the desktop Admin Console.  So we must have a balance.  We will keep your requests in mind as we continue development as we do have other UI improvements on our list.

Currently the Favorites Tab is intended as the simpler interface.  Adding folders in Favorites allows for  groups such as "outdoor" "a/v", ect. which will open to a new favorites window, thus limiting the number of items in the list. 

 

I think the problem is that it skews so far towards a programming tool that it leaves so much to be desired from a simplicity standpoint which is a turnoff for those who desire a decent looking interface to simply control their devices. I downloaded the app when it was first in beta and was put off by the design that i deleted the app. 

It's not my intention to offend anyone but it looks like a programmer designed it for programming not for usability. It's extremely utilitarian. 

Here are screen shots comparing one designed for use and UD Mobile (from Google store):

 

 

 

[Javi]

1 hour ago, apostolakisl said:

To put a story to this.  I have set up my church with Insteon and have given access to the priests and staff.  Trying to teach them to use it is a bit overwhelming.  And there are a lot of me having to say "don't mess with this, and don't mess with that"  Like if you open a switch, you are presented with ramp rates and on levels and all kinds of settings which are confusing and should just not be there except when in "advanced" mode. 

I understand, and the person setting up the app for someone else should hide unwanted controls/status.  There are parameters that allow node server devs to hide some status values also, however every time this was tested/implemented I get a support issue for missing status or control.  So to minimize support issues all values are shown by default, hiding a value is as simple as clicking the edit button, then clicking the hide button. 

 

1 hour ago, lilyoyo1 said:

I think the problem is that it skews so far towards a programming tool that it leaves so much to be desired from a simplicity standpoint which is a turnoff for those who desire a decent looking interface to simply control their devices. I downloaded the app when it was first in beta and was put off by the design that i deleted the app. 

It's not my intention to offend anyone but it looks like a programmer designed it for programming not for usability. It's extremely utilitarian. 

Here are screen shots comparing one designed for use and UD Mobile (from Google store):

I'm not offended, and it is valid criticism, however there are issues that still need to be worked out before a similar UI can be shown.  The main issue is we would have to develop for a specific device with pre-determined parameters.  This was easy when it was Insteon only, however with Z-Wave and Node Servers it is difficult to determine what parameters to map to UI widgets.   Mobilinc has already filled the use case for development specific to Insteon and most Z-Wave devices, so users with these systems already have a mature option.

Mobilinc does not work well with most node servers and some Zwave devices as mappings are inconsistent. Part of the reason UD needed to develop their own app was to allow control of these other nodes. For example thermostats do not all map to the same controls or status ranges, so we would need complex mappings in the app for each and every device by each mfg, this is not ideal and impractical.    UD Mobile is being developed to accept and control everything. At some point we plan to have default or selectable UI widgets and allow for custom mapping when the defaults do not work. This will take time and has lower priority to some other items.

 

[apostolakisl]

6 minutes ago, Javi said:

I understand, and the person setting up the app for someone else should hide unwanted controls/status.  There are parameters that allow node server devs to hide some status values also, however every time this was tested/implemented I get a support issue for missing status or control.  So to minimize support issues all values are shown by default, hiding a value is as simple as clicking the edit button, then clicking the hide button. 

 

I'm not offended, and it is valid criticism, however there are issues that still need to be worked out before a similar UI can be shown.  The main issue is we would have to develop for a specific device with pre-determined parameters.  This was easy when it was Insteon only, however with Z-Wave and Node Servers it is difficult to determine what parameters to map to UI widgets.   Mobilinc has already filled the use case for development specific to Insteon most Z-Wave devices, so users with these systems already have a mature option.

Mobilinc does not work well with most node servers and some Zwave devices as mappings are inconsistent. Part of the reason UD needed to develop their own app was to allow control of these other nodes. For example thermostats do not all map to the same controls or status ranges, so we would need complex mappings in the app for each and every device by each mfg, this is not ideal and impractical.    UD Mobile is being developed to accept and control everything. At some point we plan to have default or selectable UI widgets and allow for custom mapping when the defaults do not work. This will take time and has lower priority to some other items.

 

I suspected this was the issue.  Custom mapping would be great.  You could have generic formats for light switches, thermostats, outlets, that sort of thing and then let the user map the fields to the graphic.  Ideally, you could save and load the mapping across devices so you don't have to redo it every time.