This page last changed on Jun 13, 2011 by admin.

We should improve the handling of connection and configuration failures when it comes to status polling. The current mechanism is intrusive to the user with a modal error dialog popping up on the screen,

When such polling failures occur, we should fall back to a less intrusive mechanism to report it to the user.

One approach is that when such errors occur, the widget which cannot retrieve it's current state, falls back to A) it's default value, when applicable or B) stays at the most recent known value.


  • If we choose approach A, we should define what a default fallback value/rendering is for each type of UI widget we render on panels.
  • Approach A would work on all failures, whether its a configuration failure which tend to manifest themselves at startup or first rendering of the screen, or a connection failure, where the status information is momentarily inaccessible.
  • Approach B works for connection failures, where some reasonable value / rendering for a widget already exists, and temporary connection failure "freezes" the state of the widget. However, B still leaves open how we handle configuration errors where no value was possible to fetch for an UI widget (for example, a read command was configured with incorrect parameters).

So one way or another, it seems some default values/renderings should be specified.

We will need that specification for each type of UI widget we want to support.


While specifying default values of each UI widget would be beneficial, this may still not be sufficient to indicate to the user that their panel is not working correctly at the moment. For example, a 'switch' may fall back to 'off' but this does not necessarily indicate to the user that it's a fall back value.

Some additional visual clues seem necessary to indicate to the user the error condition.

This could be a special rendering of the UI widget itself, where possible, or a special indicator on the screen.

An example of UI widget rendering when an error condition occurs is the "broken image" rendering in web browsers when a resource cannot be accessed. This may be useful when just one UI widget fails, leaving the other elements on the screen operating normally.

Alternative is to use the fallback value defined in (1) and indicate on the screen that not all widgets are operating normally. This could be a special icon rendered on the screen that overlays the original design (for example, an icon at top-right corner indicating an error and with a press, opens up a more detailed error information dialog / screen), or it could be a mechanism native to platform, such as the pull-down notifications on Android OS.

Having a screen-wide error indicator is particularly useful during connection errors, where most/all components could fail – this is still a slightly intrusive way of notifying the user of problems compared to all widgets rendering themselves to some error indicator state (which in case of connection issue would be likely).

Document generated by Confluence on Jun 05, 2016 09:30