| 2014-09-03 09:07:00 |
Giorgio Venturi |
description |
When performing an alarm operation like creating, editing, toggling alarm status etc, it takes a while (3-4 seconds) for the operation to complete. Obviously the ideal scenario is that it happens real-time. But while we try to get to that state, we should meanwhile display some sort of progress update to the user.
Example use cases,
1. When creating a new alarm and saving it, the user will be in the add alarm page. We should some sort of saving dialog there?
2. Toggling the alarm status (enabled/disabled)
3. Editing an alarm and then saving it the user returns to the alarm list page. |
When performing an alarm operation like creating, editing, toggling alarm status etc, it takes a while (3-4 seconds) for the operation to complete. Obviously the ideal scenario is that it happens real-time. But while we try to get to that state, we should meanwhile display some sort of progress update to the user.
Example use cases,
1. When creating a new alarm and saving it, the user will be in the add alarm page. We should some sort of saving dialog there?
2. Toggling the alarm status (enabled/disabled)
3. Editing an alarm and then saving it the user returns to the alarm list page.
*** SOLUTION ***
In principle, interruptions should be minimised or eliminated.
We should therefore queue processes in the background. If I switch an alarm on/off three times, the actions should be queued in a buffer. Some of them might even become unnecessary/ For example, if I toggle ON/OFF three times, it might be appropriate to execute only the first action only
Case by case:
1. The user will be returned to the Alarms screen. The second line of the caption will say 'Saving'
2. Buffer it, no visual feedback is necessary
3. The user will be returned to the Alarms screen. The second line of the caption will say 'Updating' |
|
