|Version 1 (modified by 11 years ago) ( diff ),|
Table of Contents
Design a (better) GUI for the CAP broker
Proposed by: | Nuwan
This is for Common Alerting Protocol (CAP) with capabilities for multi-language alerting and multi-media delivery. Use Agasti CAP Broker as a starting point. (This needs clarification. Eden does not have a CAP broker that I know of. And the current Agasti CAP support is in Krakatoa, not Mayon, so needs to be ported there too. So before there can be a GUI, there would need to be a port or implementation of a CAP broker, no? --Pat)
Specific : Build a | wireframe with functionality for the | Common Alerting Protocol messaging broker. It should follow a publisher subscriber model. Some specifications are in the | CAP Software Requirement Specifications
Measurable : CAP messaging broker is becoming a much sort after tool by many organizations. It is an ITU recommendation. Such tool can be easily adopted by governments and emergency coordination agencies for managing their alerting and situational awareness.
Step 1 :: Study the Sahana Agasti CAP Broker
Step 2 :: document the requirements
Step 3 :: develop the wireframe to provide the required functionality
Step 4 :: run the wireframe through a set of test scenarios, to be documented as stories
Relevant : Part of the Sahana interoperability policy.
Time-bound : Given that the Sahana Agasti CAP broker has much of the functionality it should not take too long to develop the wireframe.
Evaluate : Requirements will be discussed with the Sahana community and a prototype wireframe will be presented.
Reevaluate : Once the wireframe is built on the concluded requirements that will be put to test through the scenario based testing.
Write a blueprint for a GUI (web) tool to build and test XSL files
Proposed by: | Nuwan
Although this is classified as a documentation task, familiarity with coding, and especially with XSL transformations, will be helpful.
Specific : Given that Sahana is getting heavy on XML there should be a tool to develop text, html, etc. outputs based one's own XSL transformation file. The user should be presented with the option to select the XML file; i.e. tags and schema, then include/exclude those tags with inserts of fixed text. The user should be able to preview the output. The built XSL file can then be stored to be used for a particular function. In this case it would be producing CAP message based user specific outputs for email, web, rss, twitter, google, etc.
Measurable : This would allow super users to develop implementation specific CAP content delivery outputs.
Step 1 :: research existing available solutions to get a feel for the type of functionality needed
Step 2 :: document and discuss the set of requirements with Sahana community
Step 3 :: develop the wireframe and test it with test scenarios
Step 4 :: document the set of specifications
Relevant : The Irrigation department may want the CAP messages to be formed in one way in an email compared with that of the Health department. A rapid XSL development tool will put the burden of building and maintaining those finals in the hands of the users and implementers and not engineers.
Evaluate : design requirements and settling on them.
Reevaluate : wireframe with the test scenarios