Alarm Management wireframes for Horizon

Registered by Liz Blanchard

Horizon developers are working on a new feature to add management of Alarms to Horizon. This will include both managing (CRUD) for Alarms as well as viewing Alarms when they are triggered. Users also need to be able to view Alarm history.

Blueprint information

Status:
Complete
Approver:
Liz Blanchard
Priority:
Not
Drafter:
Liz Blanchard
Direction:
Approved
Assignee:
Liz Blanchard
Definition:
Obsolete
Series goal:
None
Implementation:
Started
Milestone target:
None
Started by
Liz Blanchard
Completed by
Pieter

Related branches

Sprints

Whiteboard

[lblanchard 06-03-2014] First revision of designs can be seen here:
http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf

[lblanchard 06-10-2014] Feedback has been given on first revision of designs in e-mail and via etherpad:
http://lists.openstack.org/pipermail/openstack-dev/2014-June/036627.html
https://etherpad.openstack.org/p/alarm-management-page-design-discussion

Second round of design has been put together and posted here:
http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-06-05.pdf

[raghuram-gundimeda 07-04-2014] Hi Liz, the designs around this concept look really good, and seem to address quite a good number of use cases too!

Just trying to add, I was thinking we also incorporate ‘toast notifications’. We will probably confine to just ‘alarm toasts’ for now, but can plan for other toast types at a later point in time. Eager to hear opinions on this... Thanks!

[lblanchard 07-08-2014] Thanks for the review Raghu! Could you ellaborate a bit on what you would like to see with respect to Alarm toasts in the current designs? Would the way we give users error messages today be sufficient for alarm pop ups? Are you thinking this would be a solution for the web UI or would this be targeted to mobile only? Thanks for any additional thoughts or designs you might be able to provide.

[raghuram-gundimeda 07-10-2014] Yes Liz. So, (correct me if I am wrong, but) the concept of Alarm Management as I understand here is to setup / monitor / manage such states in the environment as CPU / memory / disk / network utilization / etc - which the existing popups do not functionally address.

Existing popups are just an error / success feedback to the user that show up post a user's action, and are not live feeds of occurrence of events in the environment for which the alarms are set for. Moreover, the error (unlike success) popups do not automatically disappear, but force the user to manually get rid of them. Though this is a good intended usable behavior, a toast ideally should just surface an event occurrence to the user without interfering with his current task on hand, and then auto-disappear after a short while.

(If we agree we need toasts) I think one way to achieve this is extend the existing popups to address the missing 'toast characteristics'; the other may be draft a new concept for toast notifications.

Alarm toasts are not truly part of the Alarm Management framework, but may be treated as a feature that supplements fulfillment of the same user need. They are still stored in / managed from the Alarm Management UI - only that they surface-and-disappear on occurrence of a preset alarm / event.

I think toasts can be supported in both web and mobile UI.

These are all just initial abstract thoughts that (I am sure) need more concrete elaboration, feedback, suggestions and amendments. We may finally end up not to go with toasts at all...

Thanks!

[lblanchard 07-14-2014] Ah, yes. The current design does not work in using the pop-ups that users see today around SUCCESS/INFO/WARNING messages as they are using the system. The notifications design I've been using is a bit more passive where the user would see an alert icon with a number in the upper right hand area of the screen. I think the toast works well when a user is actively working on the system and performing actions, but for alerting a user in a monitoring sense, it is too quick of a notification (especially if it always disappears). I agree that we could improve the way we use toast notifications today, but it should be a separate blueprint/task.

(?)

Work Items

Work items:
Talk with developers to understand feature request better: DONE
First round of designs: DONE
Review designs: DONE
Update designs: DONE
Send out updated designs: DONE
Support implementation of designs and make any further updates needed: INPROGRESS

This blueprint contains Public information 
Everyone can see this information.