wiki:BluePrint/CAPMobileApp

Version 35 (modified by Agga Bayu, 9 years ago) ( diff )

available features

SAMBRO Mobile Application

Table of Contents

  1. Current Status
      1. Available features:
      2. Missing features:
  2. Introduction
  3. Stakeholders
  4. User Stories
      1. Publish
      2. Subscribe
  5. Requirements
    1. Functional
      1. Optional ===
    2. Non-functional
    3. Interoperability
    4. Standards
    5. System Constraints
  6. Design
    1. Data Model
    2. Workflows
    3. Site Map
    4. Wireframes
    5. Technologies
  7. Current Implementation
  8. Planned Implementation
  9. Future Extensions
  10. Outstanding Questions
  11. References

http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/CAPBroker/CAPsymbol.png
Sahana Alerting and Messaging Broker (SAMBRO) uses the the CAP Broker.

Current Status

​Fit-Gap analysis spreadsheet

Insights from testing the web app

Available features:

  1. Edit and issue alert to restricted, private, and public audience
  2. View listing of alert messages with event type specific icons
  3. Work both online and offiline
  4. View a summary of the alert message and access the full alert on the web

Missing features:

  1. Edit and issue alert to restricted, private, and public audience
  2. View listing of alert messages with event type specific icons
  3. Work both online and offiline
  4. View a summary of the alert message and access the full alert on the web
  5. Initiate an audible alarm based on user set priority, location, and event types
  6. Use multiple channels; i.e. mobile data and SMS, for communication with server
  7. Relay, Update, Cancel, Error, and All-Clear messages to be issued
  8. Approve or Disapprove alerts for dissemination
  9. Proper authentications and digital signing of messages

Introduction

The app is supposed to be a mobile app to issue alerts for several hazards to be included into SAMBRO/Sahana.

The app will complement the web based GUIs for issuing alerts to enable a mobile solution even working in areas with weak internet connectivity.

An existing similar solution is ​mobile4D, a bi-directional hazard reporting and alerting tool developed at the Capacity Lab at the University of Bremen.

Stakeholders

<Who will be the users of the solution?>
<Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?>
<How will stakeholders be affected?>
Tip: Engage these stakeholders in the development of your BluePrint.

User Stories

An authorized user finds himself in a situation where he/she is in the need to issue an alert, but does not have access to a computer or/and a sufficiently stable internet connection. The user can now use the app and fill in the data via a structured interface. After confirming the data, the app takes over and sends the data to the Sahana server as soon as internet connection is available again without the user having to take care of it. (Alternatively, the app uses SMS to send the data. This is transparent to the user.)

Publish

Scenario - heavy rains have caused a bridge, over a river, and surrounding area to be inundated with flood waters. The bridge accommodates a rail road track and motor vehicle lanes.

  1. Intent - the local police must issue an alert to inform the transportation authorities (rail road and motor vehicle) and other relevant first-responders in the area of the of the situation. The Police Superintendent in the area will use his mobile phone to issue an alert.
    1. Actions - to be carried out by the Alert Editor (Issuer)
      1. Access the designated SAMBRO server, using the MobileSAMBRO app to login and then begin creating a new alert. Question: Are there specific reasons to explicitly login (security contraints)? Otherwise the user should be automatically logged in after a one-time authorization at the inititial usage)
      2. Select the relevant flood CAP template and add/edit information including drawing a polygon on the map indicating the alert area.
      3. Alert is issued by clicking the submit button. At this point the alert message is saved to the SAMBRO server
      4. Immediately after saving the alert message, the designated person required to Authorize the message is sent a SMS and Email requesting to approve/disapprove the alert
    2. Actions - to be carried out by the Alert Authorizer (Approver)
      1. The designated person, required to authorize the message at the District Emergency Operation Centre (DEOC), will receive an SMS and Email requesting to authorize the message.
      2. The alert Authorizer will login to the SAMBRO server, using their mobile phone, and approve (or disapprove) the alert message.
      3. If approved, the SAMRBO server will issue alerts to all alert subscribers registered as first responders through SMS and Email. Question: a Push message could also be an option here, but SMS is safer - can we rely on SMS availability on the server side? Should Push be an optional feature?
  2. Intent - the DEOC decides to extend the alert to the public. The DEOC authorized Alert Editor (Issuer), happens to be at home (away from the desktop terminal), will need to use their mobile phone to relay the alert message to the public.
    1. Actions - to be carried our by the off-site NEOC Alert Editor
      1. The NEOC Alert Editor will first login to the SAMBRO server using the MobileSAMBRO app.
      2. They will search and locate the message issued by the Police Superintendent.
      3. When the NEOC Alert Editor clicks the Relay button the message is stored on the MobileSAMBRO app
      4. The message scope is first changed to Public and then rest of the message is edited, including defining a larger alerting area by drawing a polygon on a map.
      5. The Alert Editor clicks the submit button, which saves the message on the server and invokes the Authentication process (similar to above)
      6. Once approved, the alerts are issued to the public through the various channels: RSS, post on the wen, cell broadcast, radio, TV, social media (twitter, facebook)

Subscribe

Scenario - A Community Emergency Response Team (CERT) member subscribes to receive alerts from the SAMBRO that are issued for the area of residence because he/she is responsible for responding to various events that effects the village

  1. Intent - manage a copy of the full alert message on the mobile phone to be able to refer to the message with instructions.
    1. Actions - to be carried out by the CERT member
      1. Once the CERT member receives the alert via SMS, he/she will turn on their mobile data services or connect to a WiFi hotspot to update the alerts on the MobileSAMBRO app
      2. The CERT member will open the new alert to read the complete message, then mark it as important (or favourite)
      3. Once the event is clear the message can be deleted from the phone (but not on the server) or marked as hide or is archived.

Requirements

<Group requirements in subsections, e.g. etc.> <​http://en.wikipedia.org/wiki/Requirements_analysis requirements> <Identify different types of requirements:>

Functional

  • Simple interface. Must adhere to the web application interface. At best, it is auto-generated (or semi-auto-generated) from the web templates.
  • step by step input
  • must work without internet connectivity
  • drawing a polygon on the map must be easy, seamless and exact. Map should be centered around the current position. Adequate initital zoom level.
  • summary at the end to show all the information again, must be explicitly confirmed by the user.
  • Login only necessary at initial use. (to be discussed)

Optional ===

  • alerts are a buffered and automatically sent as soon as the internet connection comes up again (Currently I do not think this is mandatory for the usecase. If the issuer can not create the alert due to lacking internet connectivity, he/she should take steps to make the alert go out other than waiting for internet connectivity. Fallback to SMS would be an option (either automatically parsed by the server or just to somebody else).

Non-functional

​http://en.wikipedia.org/wiki/Non-functional_requirements

Interoperability

Standards

  • Native communication with the Sahana data types. Compliance to CAP

System Constraints

The system has to be operational by late March.

Design

<Where relevant include alternative design options>

Data Model

(e.g. EER or class diagrams)

Workflows

<Diagrams or Pseudocode>

Site Map

<for User Interface solutions>

Wireframes

<for User Interface solutions>

Technologies

Current Implementation

Currently, there is no implementation within Sahana Eden.

  • Step 1. Test the current SAMBRO GUIs for its responsiveness to mobile handhelds. If necessary suggest some GUI tweaks to harmonize the desktop version with the mobile screens.
  • Step 2. Design hazard specific alert authoring and issuing GUIs. For example, Alerting Authorities, in a local area (Barangay, Gramaniladari, Thaluk, etc) do not need the full CAP message but a few attributes like the area and water level. We will target on delivering 3-5 mobile GUIs for Landslide, Flood, Accident,
  • Step 3. Develop the requirements/design for using the concept of Pictographs in Alerting and other features such as a wake up function to sound an Audible Alarm etc. I think we should do the same with the web GUI such that we can set a siren audio to sound for a specific warning_priority threshold.

We may have to look for funding outside of the ESCAP project for step 3. I would propose to have a standalone solution for Step 3 and concentrate on the alert-issuing part first.

Planned Implementation

To meet the time constraints given above, the plan is as follows:

  • Use a stripped-down version of the mobile4D mobile client (for Android)
  • enhance the functionality by the needed report types not supported yet
  • have the client deliver valid CAP directly from the device (the current implementation uses the mobile4D protocol and converts this to CAP server-sided)

The current functionality includes:

  • Send hazard reports:
    • filling in needed fields (numbers, contact details, urgency, etc.)
    • detect the current location
    • alternatively give a location and specifying a polygon on a map
  • Buffer issued reports and re-send them upon network connectivity.
  • Retrieve alerts and display them as list and map. This will most probably not be included.
  • Many more communication features that might not be included either.

Future Extensions

  • Send SMS when no TCP/IP network is available.

Outstanding Questions

  • Photos: does CAP support photos? Should photos be sent from within the app?

References

Note: See TracWiki for help on using the wiki.