Does the world need another incident management tool?

[Spaceman3750]

I've been brainstorming today and am kind of curious... If you could have an open-source browser-based (hosted locally or offsite using a LAMP package) incident management tool (but separate from WMIRS) would you use it or keep on with a mashup of IMU/WMIRS/paper/other tools?

[JeffDG]

I've been brainstorming today and am kind of curious... If you could have an open-source browser-based (hosted locally or offsite using a LAMP package) incident management tool (but separate from WMIRS) would you use it or keep on with a mashup of IMU/WMIRS/paper/other tools?

Depends...

I know "Separate from WMIRS", but there needs to be connectivity to WMIRS, because the information must ultimately end up there.

I would love to see a set of Web Services published for accessing WMIRS, then various people could work on tools for their specific needs, yet make sure that the data ultimately ends up where it needs to go.

In terms of a "LAMP" package, what I would propose there would be a VM type solution or a a boot from DVD/USB flavour of linux, that way you have a DVD in your kit, load it up on the nearest available PC, and voila, you have a Mission Management System in a box.

[Spaceman3750]

I know "Separate from WMIRS", but there needs to be connectivity to WMIRS, because the information must ultimately end up there.

The problem is that apart from (painstakingly) screen scraping, there's no good way to access WMIRS/eServices and I've seen neither hide nor hair of an API.

What I'm proposing is several modules that are specific to a job function, take care of any paper related to that function, provide alerting via text message, etc. For example, under the logistics section module there would be a comm area where you can see all resources currently out and their status, last position, etc. You click "Checkin" and you plug in the radio check in data, which then updates the status board for all users and generates a log entry for all applicable users. A general message form could be directed to a specific area (Operations, Finance, etc) and would generate a text message alert to whatever phone number(s) are associated with that area so that the person knows to go in and respond to the message (eliminate runners).

Operations would have an area to view taskings, request resources from logistics/RUL, assign resources (GTA, ACA, etc) to the specific tasking and provide an electronic log, etc.

Resource would have a checkin area based off of CAPWATCH and electronic resource requests which can be filled from checked in people and resources, with error checking to make sure that you're not assigning a GES person to fly an airplane, etc.

It's all kind of a hodgepodge in my mind right now, but this is a part of what I'm thinking so far.

[JeffDG]

I know "Separate from WMIRS", but there needs to be connectivity to WMIRS, because the information must ultimately end up there.

The problem is that apart from (painstakingly) screen scraping, there's no good way to access WMIRS/eServices and I've seen neither hide nor hair of an API.

OK, regardless of the tool, from paper to anything else, the final result data must go into WMIRS.

So, you need to either figure out a way to get it there as we have now with screen scraping, or we need to push to have a set of Web Service APIs published.  That is literally the most important thing that can happen.  With an API, then the nearly unlimited talent and creativity of CAP members can be unleashed to create tools that will make our jobs easier, so we can spend more time on the mission, and less on the paperwork.

[JeffDG]

I know "Separate from WMIRS", but there needs to be connectivity to WMIRS, because the information must ultimately end up there.

The problem is that apart from (painstakingly) screen scraping, there's no good way to access WMIRS/eServices and I've seen neither hide nor hair of an API.

What I'm proposing is several modules that are specific to a job function, take care of any paper related to that function, provide alerting via text message, etc. For example, under the logistics section module there would be a comm area where you can see all resources currently out and their status, last position, etc. You click "Checkin" and you plug in the radio check in data, which then updates the status board for all users and generates a log entry for all applicable users. A general message form could be directed to a specific area (Operations, Finance, etc) and would generate a text message alert to whatever phone number(s) are associated with that area so that the person knows to go in and respond to the message (eliminate runners).

Operations would have an area to view taskings, request resources from logistics/RUL, assign resources (GTA, ACA, etc) to the specific tasking and provide an electronic log, etc.

Resource would have a checkin area based off of CAPWATCH and electronic resource requests which can be filled from checked in people and resources, with error checking to make sure that you're not assigning a GES person to fly an airplane, etc.

It's all kind of a hodgepodge in my mind right now, but this is a part of what I'm thinking so far.

90% of that exists right now in the IMU package.  There is messaging capability (ICS 213s), an updating comm log available to all, logs for each section chief to maintain status, a status board for ground and air teams, etc.

[a2capt]

I would, especially open source. I'll even setup a repository for it if it would help, IMU is a one man show without regard for input from the field, the UI is six different versions of atrocious, and while it does get a job done, there has to be a better, more flexible, way.

The way IMU tries to be the nanny is crazy. It absolutely does not work optimally in a real world scenario. The way you get hung up and hosed, bottlenecked with launching sorties because the incoming one has not finished debriefing yet, because the paperwork has not caught up with the real world, is just nasty.

You can't have that aircraft, you can't have part of that crew, you have to disband all of it to swap two people around, even if they're going to go back out together later. You should just be able to pick from whoever is there for each mission and let it be. Let the people at the base be the intelligence, and let the computer be the tool. The computer trying to be the intelligent nanny is really just a big pain in the rear end.

But.. there are a couple, IMU and another that a few wings are using, and then there is the pissing match between NHQ and whoever, where it seems like they do nothing but try to break each others code instead of getting along. The way IMU has to login to WMIRS is amusing at best, it's essentially acting like a browser, and parsing the content, and posting to it. Genius, yes. Subject to the mood of the IT people, absolutely.

[JeffDG]

But.. there are a couple, IMU and another that a few wings are using, and then there is the pissing match between NHQ and whoever, where it seems like they do nothing but try to break each others code instead of getting along. The way IMU has to login to WMIRS is amusing at best, it's essentially acting like a browser, and parsing the content, and posting to it. Genius, yes. Subject to the mood of the IT people, absolutely.

It's not the IT people at NHQ that run WMIRS...and it shows.

[JeffDG]

I would, especially open source. I'll even setup a repository for it if it would help, IMU is a one man show without regard for input from the field, the UI is six different versions of atrocious, and while it does get a job done, there has to be a better, more flexible, way.

The way IMU tries to be the nanny is crazy. It absolutely does not work optimally in a real world scenario. The way you get hung up and hosed, bottlenecked with launching sorties because the incoming one has not finished debriefing yet, because the paperwork has not caught up with the real world, is just nasty.

You can't have that aircraft, you can't have part of that crew, you have to disband all of it to swap two people around, even if they're going to go back out together later. You should just be able to pick from whoever is there for each mission and let it be. Let the people at the base be the intelligence, and let the computer be the tool. The computer trying to be the intelligent nanny is really just a big pain in the rear end.

But.. there are a couple, IMU and another that a few wings are using, and then there is the pissing match between NHQ and whoever, where it seems like they do nothing but try to break each others code instead of getting along. The way IMU has to login to WMIRS is amusing at best, it's essentially acting like a browser, and parsing the content, and posting to it. Genius, yes. Subject to the mood of the IT people, absolutely.

Concur with almost everything here.

You have to learn to work around some of the IMU stuff, and a collaboratively built and maintained tool would be excellent.  We could put it up on Sourceforge or Google Code without a lot of effort.

But...again...all the stuff that has been developed in IMU to get data into WMIRS would need to be redone...unless someone can get NHQ to publish a proper API.  I honestly thing that is the biggest thing we need right now.

If all the time that the IMU guys have spent playing tit-for-tat with WMIRS interface changes had been put into improving the functionality and effectiveness of IMU, we'd probably have a kick-ass tool right now.  If you don't solve that problem, you'll end up in the same place...constantly maintaining the WMIRS interface every time someone at NHQ changes something on a whim, and flushing precious time that could be used improving things down the drain.

[Spaceman3750]

I haven't used the IMU in depth other than to do sign-ins on Evening 1 of the last eval (and that felt like a huge pain, I never knew whether someone was signed in or not and it kept bugging me about vehicles and instrument currency). What are some specific examples of IMU nags that shouldn't be there?

[Eclipse]

Whatever we use it needs to be fully integrated with eServices and endorsed by NHQ, not a separate, stand-alone application.

We have too many of those already.

Closed or open source is irrelevant other than to whomever does it.

It a perfect world we'd have a mission management module of eServices where you log in as an IC or FASC, enter CAP ID's, assign roles and then that participation generates proficiency time or mission credit back to eServices.

Easy to say, not necessarily easy to accomplish with existing framework.

[Phil Hirons, Jr.]

Ideally it would be able to function without internet access and upload to e-services / WMIRS later. As we move from ELT hunting to DR, lack of internet connection becomes more likely in an actual mission. An ICP with power and a router should be able to set up a multi station application

[davidsinn]

Ideally it would be able to function without internet access and upload to e-services / WMIRS later. As we move from ELT hunting to DR, lack of internet connection becomes more likely in an actual mission. An ICP with power and a router should be able to set up a multi station application

Why are you setting up the ICP in the disaster area? ICPs are supposed to be in the rear where the infrastructure still exists.

[Eclipse]

Ideally it would be able to function without internet access and upload to e-services / WMIRS later. As we move from ELT hunting to DR, lack of internet connection becomes more likely in an actual mission. An ICP with power and a router should be able to set up a multi station application

Why are you setting up the ICP in the disaster area? ICPs are supposed to be in the rear where the infrastructure still exists.

Agree, and frankly lack of internet is no longer acceptable.  There might be an FOB working without connectivity, but the ICP needs to be where there
is robust infrastructure.  That's ICS 101.

[JeffDG]

Whatever we use it needs to be fully integrated with eServices and endorsed by NHQ, not a separate, stand-alone application.

We have too many of those already.

Closed or open source is irrelevant other than to whomever does it.

It a perfect world we'd have a mission management module of eServices where you log in as an IC or FASC, enter CAP ID's, assign roles and then that participation generates proficiency time or mission credit back to eServices.

Easy to say, not necessarily easy to accomplish with existing framework.

I have to disagree with you there.

I'm not a huge fan of centrally-planned solutions.  I would prefer that NHQ provide the interfaces to integrate with eServices, then let people build their own tools.  Some will be good, others will suck something fierce.  The good ones will survive and spread, the poor ones will wither and die.

The problem is, there isn't one set of functionality that everyone needs.  And trying to build a one-tool-for-everyone leads you to a lot of stuff that people only need 5% of the time, but gets in the way of the stuff that everyone needs 80% of the time.

[Eclipse]

People are free not to build whatever they like using CAPWatch data, however if you want to inject data back into the system you have
to play nice with NHQ.  Unless you have a centralized infrastructure, there is no way to standardize process, and you wind up with another
WMU/IMU/SIMS, etc., where members feel free to say "we don't do that here".  That's not how it works when you purport to be
a national organization that can respond as one team.

Frankly I'm surprised this is something NESA has been pressed to implement in some way.

We ave a very narrow set of requirements for mission work, training sign offs, and tracking proficiency.  We need to get there first, on a national, standardized level.

[sardak]

Just some food for thought.

Presentations from the summer boards are posted on the national website:
http://members.gocivilairpatrol.com/events/cap_annual_conference/2011_learning_labs__louisville_kentucky.cfm

These are from two of the slides in the WMIRS presentation:

What is coming?
- Mission resource sign-in (personnel, aircraft, vehicles)
- Mission Log
- New ground sortie page (CAPF 109)

Mission Logging
- Still in development
- Will hold IC, Comm, Air and Ground Ops, etc.
- Will auto-populate from other events.
- Searchable
***************
Here's a free mission management system which might provide some ideas.

http://www.radishworks.com/SearchAndRescue.php

Run your missions and keep track of your personnel more efficiently. The Mission Manager on-line Software was written by practiced mission managers who has years of experience running real missions. Start by broadcasting text, email and phone messages to all your team members. Log all your subject information on-line and make it available for all your command staff. Automatically generate Missing Person Flyers, Team Briefing forms, and many other standard ICS forms. Track all your team members as they check into the mission and easily make team assignments for them with integrated Maps. Track where your teams have been and where they currently are in real-time. During and after your mission print standard ICS forms and detailed information about your mission efforts.

# Runs in the Cloud on the Web or offline without a Web Connection
# Real-time access to all mission and member data
# All of your command staff can access mission information from different computers and locations
# Maintain a list of member status as the mission progresses
# Automated Member Call Out Notification - via Email, Text Message and Phone calls
# Create team accessible Links to other Web sites
# Upload your team's documents and control who can see and edit them

Mike

[JeffDG]

People are free not to build whatever they like using CAPWatch data, however if you want to inject data back into the system you have
to play nice with NHQ.  Unless you have a centralized infrastructure, there is no way to standardize process, and you wind up with another
WMU/IMU/SIMS, etc., where members feel free to say "we don't do that here".  That's not how it works when you purport to be
a national organization that can respond as one team.

Frankly I'm surprised this is something NESA has been pressed to implement in some way.

We ave a very narrow set of requirements for mission work, training sign offs, and tracking proficiency.  We need to get there first, on a national, standardized level.

That's the whole purpose of an API, to provide a standardized set of things you can do, authenticated and controlled.  You don't need to control the whole system, just the touch-point.

It's all academic.  NHQ is currently hostile to the point of doing things for the sole purpose of breaking external apps, so I don't see them ever publishing an API absent an Act of Congress.

[Eclipse]

^ OK, I don't know why, but I thought you were suggesting "not API".  I agree that's what we need, and then anyone could
gen an app for a device or the PC.

Allowing updates should require some sort of certification process, but once that's worked out, it should just be "data".

[JeffDG]

^ OK, I don't know why, but I thought you were suggesting "not API".  I agree that's what we need, and then anyone could
gen an app for a device or the PC.

Allowing updates should require some sort of certification process, but once that's worked out, it should just be "data".

Ahhh...

Yes, all the transactions need to be authenticated, but that's a relatively routine matter in the systems integration world. 

[Robborsari]

I would, especially open source. I'll even setup a repository for it if it would help, IMU is a one man show without regard for input from the field, the UI is six different versions of atrocious, and while it does get a job done, there has to be a better, more flexible, way.

The way IMU tries to be the nanny is crazy. It absolutely does not work optimally in a real world scenario. The way you get hung up and hosed, bottlenecked with launching sorties because the incoming one has not finished debriefing yet, because the paperwork has not caught up with the real world, is just nasty.

You can't have that aircraft, you can't have part of that crew, you have to disband all of it to swap two people around, even if they're going to go back out together later. You should just be able to pick from whoever is there for each mission and let it be. Let the people at the base be the intelligence, and let the computer be the tool. The computer trying to be the intelligent nanny is really just a big pain in the rear end.

But.. there are a couple, IMU and another that a few wings are using, and then there is the pissing match between NHQ and whoever, where it seems like they do nothing but try to break each others code instead of getting along. The way IMU has to login to WMIRS is amusing at best, it's essentially acting like a browser, and parsing the content, and posting to it. Genius, yes. Subject to the mood of the IT people, absolutely.

Just a couple of things.  There are more than one person involved in IMU and we always welcome suggestions and comments from the field. I only count 4 versions of atrocious in the UI .  We have made it hugely easier to install and update and manage the database.   It is absolutely a work in progress and if you have any specific suggestions to improve the UI please let me know.   

The aircraft is available for a new sortie a configurable number of minutes (default 30) after the departure of the current sortie, there is also a checkbox that allows you to select the aircraft anyway.  Having it not appear on the list is simply to avoid having 2 different people assign the aircraft to 2 different tasks.  Once the sortie has an ATD entered the crew is available to be changed and assigned to the next sortie.  With a comm section entering the status updates in real time you should not get bottlenecked like that.   Feel free to PM me if you want to explain what you are struggling with and I will do what I can.