SAMBRO GUI Design

Common Operating Picture

Examples

Alerts

• ​Archived Alberta Emergency Alert
• ​Google Public Alerts
• ​Public Alerts - nice icons here too and also the categorical graphic filter options
• ​Pacific Disaster Center - Symbols are nicely integrated
• ​Copernicus Emergency Management Services - table is the only interesting part

Feeds

• ​Timore-Leste DRMIS Nortisia
• ​PAGASA Public Alerts
• ​List of Federation of Internet Alerts (FIA Feeds)
• ​NY-Alert List of Feeds

Alerting Sequence

The sequence of entering data and completing the process authoring an alert for approval or directly issuing require several steps. These steps can also depend on the predefined alert templates. For example, an alert template that is defined to accommodate multiple languages would require the additional steps of completing the extra info segments. Therefore, the GUI designers should use the knowledge from the CAP message template to define the sequence indicator shown in the image above. Here are the general steps

1. Click create alert button, which would present the user with the Alert block to change or enter any alert qualifier information and then save the form
2. Once the Alert block is saved the process should navigate to the Information block. The information block may contain more than one segment, i.e. one for each language. After saving the first Info block for the first language the sequence indicator will show that to be competed. And when the next Info block is saved the next green light will come on, so on and so forth

Menu structure

The menu structure is based on the following principals:

1. Each user with specific roles to quickly access the required function
2. Multiple paths to access the required function
3. Most used main menu items (functions) are on the top bar
4. Sub menu items are listed in the side bar ordered by the most used at the top

We need to further elaborate, in a table, the menu items for each user role and the order they are in.

Alert Segment

identifier

• Typical format is "prefix" + "dateTime" + "timezone" + "msg-sequence-no" + "postfix"

Example - 2.49.0.1.524.2-20150525T12:23:00+8:00-005-scdmc. The prefix = "2.49.0.1.524.2-", postfix="-scdmc", and sequence="005" (we may issue more than one alert in one day; hence would require multiple message sequence numbers).

• One recommendation for the postfix is to use the ​WMO Recommended Alert Object Identifiers that helps identifies the alerting authority. However, it is not mandatory and the implementers are free to introduce another.

msgType

This is essentially a state machine, whereby an alert message can transition from msgType to another. The possible sequences are illustrated in the diagram and then described in the table below.

State transition diagram

Code Values:

Alert - Initial information requiring attention by targeted recipients
Update - Updates and supercedes the earlier message(s) identified in <references>
Cancel - Cancels the earlier message(s) identified in <references>
Ack - Acknowledges receipt and acceptance of the message(s) identified in <references>
Error - Indicates rejection of the message(s) identified in <references>; explanation SHOULD appear in <note>

'Cancel' and 'All clear' acts like a sink. They are where every msgType would ultimately go.

Transition combinations

No:	Transition	Remarks
1)	Alert ---> Update ... Update ---> Cancel	Cancel means the event was disregarded and it was a false alarm example - heavy rains cause a rain gauge to automatically trigger flash-flood alert, then the alert is incidentally updated by mistake, until finally the authorities realize it was a malfunction and issue a cancelled
2)	Alert ---> Cancel	is the same as 1) above but excluding any intermediary update alert messages
3)	Alert ---> Update ... Update ---> All Clear	All Clear is not in the CAP 1.2 but will be in 2.0; this means the event is over; it's different from "Cancel" example - a tsunamigenic earth, off the coast of Indonesia, triggers an alert, which is updated several times every 5 minutes, then finally when their is nor threat, an All Clear message is issued to inform that the threat is over
4)	Alert ---> All Clear	Error means the previous message had false values, thus, the msg with errors should be followed by an error-less message example - similar to example in 3) above, instead the the message "priority" was mistakenly set to "urgent" during an update, then a follow up message is issued to correct the "priority" to "high", in which case the msgType is set to "Error". Thereafter, the transitions can be as any of the above terminating with an "All Clear" message
5)	Alert ---> Update ... Update ---> Error ---> Update ... Update ---> All Clear	Error means the previous message had false values, thus, the msg with errors should be followed by an error-less message example - similar to example in 3) above, instead the the message "priority" was mistakenly set to "urgent" during an update, then a follow up message is issued to correct the "priority" to "high", in which case the msgType is set to "Error". Thereafter, the transitions can be as any of the above terminating with an "All Clear" message
6)	Alert ---> Error ---> All Clear	same as 5) above but excluding any of the updates
7)	Alert ---> Update ... Update ---> Error ---> Update ... Update ---> Cancel	is similar to 5) above instead, the message was false and a mistaken. Hence, instead of ending it with an "All Clear" we "Cancel" the message.
8)	Alert ---> Error ---> Cancel	same as 7) above but excluding any of the updates

"Ack" - Acknowledgement may not apply when we are publishing. Ack is used when a system or person receives an alert message and wants to acknowledge the receipt of that message. They would typically set the to Ack and return the message to the sender. This is a feedback for the issuing system to account for that the message was actually received by the intended recipient.

example, we may issue SMS alerts to [n] people and expect them to Ack. If and Ack is not received then we may recast the message to those who did not receive the message. Don't worry about this part, it's a project of it's own.

scope

We need to build in the logic for each of the values: Public, Private, and Restricted.

Value	Implication
Public	---> text-box control "Restriction" and "Recipients" are disabled
Restricted	---> text-box control "Restriction" = enabled and text-box control "Recipients" = disabled
Private	---> text-box control "Restriction" = disabled and text-box control "Recipients" = enabled

reference

if "Reference" is empty (NULL), then "Reference" = "Identifier" values (which is mandatory) if "Reference" is NOT empty (NOT NULL), then leave as it, possibly populated from the template

incident

• We should relate to the same incidents list in the IRS module. Example: a mass movement that causes an accident, then incidents would be ="rock slide", "train derailment".
• "rock slide" and "train derailment" may be archetypes of "mass movement" and "accident" respectively.

Info Segment

The basic needs for multiple info segments

Language

1) Multiple languages - an info segment for each language defined in the profile

Priority

Headline

Parameter

It is a system-specific additional parameter associated with the alert message.A single alert message info block can carry multiple parameters Example of the structure

<parameter>
     <valueName>earthquake-magnitude</valueName>
     <value>7.8</value>
</parameter>

To differentiate the SAMRBO system generated or specific paramters; we will use a prefix sahana: in the parameter name. Such parameters with the sahana: prefix might be used in various system logic. At present parameters are used for holding data on

• the text strings to be used in various renderinglayers such as for TV scroll, Twitter, SMS

example:

<parameter>
     <valueName>sahana:layer-SMS</valueName>
     <value>Heavy rains in Southern Indonesia to continue over next 3 days</value>
</parameter>

There are two methods for entering parameter values.

1. User enter values
2. System automatically enters values (e.g. layers, warning-priority)

• warning priority value specific to the implementation (not the severity, certainty, or urgency).
  

NOTE - that such parameters such as the waring-priority-color are not defined in the template, instead are automatically added at the time of saving the alert message. Therefore, such parameters are not expected to be completed by the Alert Editor at the time of issuing the message.
example:

<parameter>
     <valueName>sahana:warning-priority-color</valueName>
     <value>Orange</value>
</parameter>
<parameter>
     <valueName>sahana:warning-priority-name</valueName>
     <value>Signal 1</value>
</parameter>

• event specific information such as telemetries.
  

NOTE - these parameters are predefined in the CAP message template and are expected to filled (or completed) by the Alert Editor. If these values are not set then user should be warned.
example:

<parameter>
     <valueName>sahana:rainfall-daily-mm</valueName>
     <value>120</value>
</parameter>
<parameter>
     <valueName>sahana:rainfall-days</valueName>
     <value>3</value>
</parameter>

Other

2) Multiple msgType - when the msgType is changed to send an Update, Cancel, Error, or All Clear, the an additional info segment for each language must be added to that particular event specific message

Example: The Met depart may detect a cyclone developing in the Bay of Bengal. The Tamil Nadu DMC would issue an alert in English, French, Hindi, and Tamil, that's 4 segments. Then every six hours they would issue an update of the same alert but with the new position, wind-speed, trajectory, etc. These updates would need to be issued in the 4 languages. Assuming there are 5 updates before it hits land, then that particular message would have 20 segments

Home Pages

Public Home Page

This page is essentially the HOME visible to the public; it will display public alerts only; where cap:alert:scope = "public". All other alerts are only available to those authorized with a login

Public Alert Page

Public alert page is descriptive page that is accessed by selecting an alert listed in the home page of the navigation controls

example: ​https://google.org/publicalerts/alert?aid=34355056e33cf59b&source=pa-iw&hl=zh&gl=TW

CUG Home Page

Closed User Group (CUG) home page is for authorized users who are either publishers or subscribers

Closed User Group (CUG) home page is for authorized users who are either publishers or subscribers

Descriptive Full Message

When a user clicks on a alert summary, listed in the home page or common operating picture, they would navigate to a page to view the complete description as shown in the image below.

Social Media

Facebook

Twitter

SOP Check Lists

The event type specific SOP check list are presented through the <cap:resource>.

Aggregator

The SAMBRO aggregator serves as a alert hub that pulls in feeds from various sources and then presents them through a single RSS Feed. Initially it will serve as an aggregator for the:

• ​IFRC Mobile Apps
• ​GeoThings Mobile Apps

Example list of incoming feeds

Validating and applying knowledge to attributes

Important to apply the proper knowledge and logic in validating and suggesting values. Here's a list to start with.

1. Message Status (Draft) - need to check if message status has been changed from draft to alert or something else; see the transition diagram for the knowledge: http://eden.sahanafoundation.org/wiki/BluePrint/CAPBroker/GUIDesign#msgType.
2. Template/Event_Type - once an Alert has been created for the first time, there is no need to show the template and Event_Type controls. User will not use them anymore; can be hidden. If the user used the wrong event type, then they should "Cancel" that alert and start a new one.
3. Message Type - after the first issuing of the message with setting the msgType=Alert, the same message can never be reissued as an Alert. It can be an Update, Cancel, Error, or All Clear. If during an update, error, cancel, or all-clear the user should never be allowed to set it to "Alert" again.
4. Onset - if onset is not set then it should default to effective date.
5. Parameter - if the parameter name is not null and the value is null then user should be prompted to add the value
6. Sender / SenderName - If either Sender or SenderName is NULL then it should default to the email address and user Name, respectively.
7. All attributes - if the value is NULL then it can be hidden from being displayed in the Profile (FULL ALERT) page.
8. Sent - the sent date and time should be set to the current time when the message is saved for Alert, Update, Error, Cancel, and All Clear.
9. CAP Mandatory values - All CAP specification set mandatory (or REQUIRED) values should never be NULL. For example, If user forgets to set the Scope, they need to be prompted. For CAP REQUIRED values see the attributes highlighted in bold: ​http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
10. Recipients - the recipients drop down shows even when the scope is not set. It should only appear and allow user to set a value, if and only if, scope is Public or Private

Example list of incoming feeds