This page last changed on Jun 06, 2011 by juha.

The current UI experience on the initial startup and connecting to controller is rather horrid.

Goal is to design something more user friendly, move out the less used options (security, cache mgmt, etc.) and make sure the user is helped as much as possible on the first experience.

Generic configuration options (those not needed for every installation) should move to their separate screens.

List of controllers should always be present (regardless if auto-discovery is on or not) but should visually indicate (icon or color) whether the chosen controller is available – panel app could attempt to ping in the background configured URLs (those not auto-discovered) just to see if there's a response and reflect that status to the user in list of controllers.

The selection of panels should only be visible after the user has chosen his controller (separate screen that switches the UI context for this one task only for the user). In the long run the available panels should be restricted to only to those relevant to the user (e.g. iPad resolution only). This however will require changes to the designer and / or XML schemas.

In many aspects, the UI interaction should be similar to how WiFi access points are discovered.


The first sketch is what should be the main screen of the panel configuration when the app starts.

It is missing some other screens that are related to the interaction of the UI elements shown here (another sketch, although still in parts incomplete, is below).

The focus is on the list of available controller URLs and their current reachability.

Whether controller URLs are auto-discovered or manually entered, they should be "remembered" once used (cf. WiFi access points)

Reachability status of remembered controller URLs should be resolved in a background thread and UI updated accordingly (using HTTP REST to retrieve existing panel definitions should serve as appropriate "ping" to controller).

If controller URL is tapped before the reachability status is resolved, immediately attempt to connect.

Panel selection has been left out to another screen which is opened once a controller has been chosen.

Security setting has been moved to its own screen. Same with additional configuration (such as clear cache, potential SIP configuration, etc.)

Long press on controller URL allows user to see the full URL string (if hidden), edit the URL or delete the URL from "remembered" status.

Auto-discovery can be re-started by tapping the icon at bottom-left. Should indicate that auto-discovery is running with a simple animation. Auto-discovery should run on the background (essentially modifying 'reachability' status or adding new URLs to the controller list).


The second sketch details a little more the app startup flow:

Shows the panel selection screen – when URL is tapped and if more than one valid panel is present.

And shows the long-press screen for user to view full controller URL and either edit or remove it from list.

Still missing screens for security config / other config and adding new manual controller URLs (or delete multiple controller URLs at once).


This sounds like a goof idea to add my $0.02: -

  • Initial startup isn't the best and your WIFI style idea sounds like a good way of managing it with the app always performing an initial discovery on start-up (don't see why you'd want to disable auto discovery provided you can manually add controller URLs with it active - not the case at the moment); upon initial discovery if previously used controller is found then auto connect (like what seems to be happening at the moment), if it's not found go straight to discovery page (currently seems to load last controller and horrid Update fail message appears).
  • With the auto discovery, a suggestion is for the controller to broadcast the security type it is using (sticking with the wifi theme) when the user then clicks a discovered controller if there is security then the SSL port could have been discovered and user prompted to enter credentials.
  • Some instruction on the discovery page for those users who have never used OR before pointing them in the right direction might be useful.
  • Some alternative to the Update Fail messages that appear if controller connection is lost while a panel is being displayed (only happens when sensors are polling); maybe sensor values go to some default value or force the user back to the discovery screen. Possible auto-reconnect when connection re-established?
  • Some standardisation of UI's between platforms (difficult when the platform vendors provide platform specific ways of implementing certain elements).

Rich

Posted by kurrazyman at Jun 08, 2011 22:14

We have some tickets in JIRA for the "Update Fail" messages when a controller connection is lost while a panel is being displayed:

  • ANDROID-89 Gracefully fail on polling errors
  • ANDROID-85 clean up client-side controller fail-over mechanism
Posted by cortextual at Jun 10, 2011 19:31

Some alternative to the Update Fail messages that appear if controller connection is lost while a panel is being displayed (only happens when sensors are polling); maybe sensor values go to some default value or force the user back to the discovery screen. Possible auto-reconnect when connection re-established?

Agreed. This is a separate topic though and we should discuss it in another thread. There was some initial thoughts in the JIRA task Andrew pointed out.

Will pull that discussion into the forums:

Gracefully Fail on Polling Errors

Posted by admin at Jun 13, 2011 15:21

I did start review of the current iOS settings page, going in that direction.
You can see the current work in this thread

Posted by ebariaux at Aug 04, 2011 11:02
Document generated by Confluence on Jun 05, 2016 09:29