Need suggestions for new IMU features

[swamprat86]

We are working on a project to address internet access in limited environments.  I don't want to give too much away until we get a prototype running...That and I love doing the "Steve Jobs" rollout presentation. 

With that, I agree that a web-based version would be better.  There are situations that we are running from multiple locations where a web-based application would be useful.

[Robborsari]

I'm trying to remember if there is a clue-tracking function.  If there isn't, there should be.  Yes, they could be noted in various logs but having them immediately available would be helpful. 

List:  Name of person taking clue information.  Data on source of clue (name, phone number, email, etc.), time received.  Have some sort of assessment of the value of the clue.  Also, some sort of tracking of what has been done in response to that clue.

IMU has a 106 module that stores the information, keeps track of if it is open or closed, and prints the 106.  I have not really dug into that one but my goal is to have any information with a postition attached be displayable on the grid assist and in google earth

[Robborsari]

I am working on the first things I listed as well. 

I am confused here, are you saying that you are coding new features into the IMU?

I am working with Pete Anderson on bug fixes and coding new features.

[Robborsari]

It needs a much more intuitive feel and user friendly GUI.
It needs all the required ICS forms (add the 206).
It needs an IO log.
It needs to update at a set time on a set day weekly. Not having to up date the data base in the middle of an operations period would do much to stabilize the system. It always seems to dump in the middle of exercises on a weekend.

The 206 is already on my list.
We added the IO log and an AL log a few releases back.
The update thing is tougher.  Pete has added the ability to merge databases so other wings can be brought in.  He is also working on improving the update of individual workstations from the server.  I think there will always be a need to download a whole new database to clear out past missions and get info on new members but it should be easier to manage.
Right now if you are in the middle of an ops period and you have a member with no quals in the currrent database, IMU can go to MIMS and get the data for that member if you have an internet connection.  If not then the quals can be entered for the member by hand.  Its not perfect but there should be no need for a new DB in the middle of an ops period.

[arajca]

The 3 biggest issues I have with IMU are:
1. Stability, or rather lack thereof
2. User unfriendliness - it's a pain in the back side to use
3. Double the work load - it is far easier to run with manual forms than use IMU for many functions. The last few SAREX's I've been to, signing people into the exercise on IMU took two-three times as long as paper forms. Even longer if they had a vehicle. Becuase of 1, everytime IMU was used, paper forms were used to ensure proper documentation.

Networking is also an issue - I attended a class on IMU. It took two hours to get 15 computers working on the networked IMU.

Admittedly, I haven't tried to work with IMU in a year or so due to these problems, so some may have been fixed, but I'm not in any hurry to try it out again.

An issue I have with my home computer (which is where I would like to have it installed for practice purposes) is that IMU doesn't like it. IMU asks for a font that is installed in the proper location, but IMU can't find it. Contacting Pete Anderson resulted in a "well, I guess it won't work for" after trying to troubleshoot it.

[Robborsari]

Currently you need to sign people in at the beginning and it knows when someone is assigned to a sortie.    If they leave the mission base to go to lunch you can sign them out and clear the signout when they return.  What else would you like to see for people who are unavailable?  A reason, a contact number or location information?  I don't want to make it more complicated than it needs to be but I do want it to be useful. 

It seems to me that if people need a piece of paper to keep track of it that IMU should be able to manage it as well.  I don't want it to impose any restrictions that are not already required by regs.   The goal is to avoid forcing people to "feed the tool" when they should be concentrating on how to accomplish the mission.

I would have reason, location, estimated time of return and a contact number.

Say you put a member on crew rest....he goes into crew rest, at Hojo's room 114, ETR 0700, 123-555-1245.
Since he is still logged into IMU he would be covered by CAP insurance /USAF if injured and he would be availabe to the IMU for planning future air crews based on his ETR.

If someone depart the mission base for a food run, to pick up supplies or to run some other errand related to the mission then there is a record of when he left, where he was going and when he is expect to return.

This will also give the IC immediat data on how many people are actually available for planning 24 hour operations.

I agree that we need to keep it simple and a this could be implemented very easilly in the sign in tab.

I have had a lot of discussions about this with various folks.  I need some information about the insurance situation.

If a member leaves the mission base is he still on the mission and covered by insurance if:
a) He is in a COV
      i) does he need a 109 on the mission?
b) He is in a POV
      i) does he need a 109 for the pov?
c) He goes away from the mission base and does his rest in a hotel away from home
d) He goes home and sleeps and comes back.

I guess I need a discussion with a wing or higher legal officer.  We need to make the check-in / check-out process match the insurance situation.  It is a good suggestion.  I have it on my list

[Robborsari]

We are working on a project to address internet access in limited environments.  I don't want to give too much away until we get a prototype running...That and I love doing the "Steve Jobs" rollout presentation. 

With that, I agree that a web-based version would be better.  There are situations that we are running from multiple locations where a web-based application would be useful.

Having the entire application be web based would significantly up the amount of bandwidth required to run the system.  Right now the server is web based.   It handles requests from the clients and passes data back using http.  The clients are all capable of becoming a server so it is very versatile depending on the network situation.

For the 3 release the modes have been simplified a little:
Local
One system only  local database with no network.

Client Server
Server can be either a workstation in server mode or a dedicated web server or web hosting service
The server can be on the internet or on a local lan.
Both use http as the transport. (no more shared disks or port issues)

Archive
Uses internet to access the wmu server which archives completed missions.  Allows review and printing of documents from past missions.

I have a mission network bag that contains a few wireless routers (dd-wrt is very helpful) and network cables.  We always use the same ssid and key so laptops are pre-setup for the mission.  The router is attached to whatever network is available and serves it to the mission laptops.  Once you get people configured it saves a lot of time at later missions. 

We have found that you need a mission IT support guy most of the time anyway.  With WMIRS and photo upload and customers using email, having access is pretty critical.  We have a satelite based system from hughes that can be deployed to a base if there is a big disruption and we also use cell aircards or whatever wireless internet we can beg from the FBO.

[N Harmon]

So this is going to continue to tie into the WMU instead of being a sanctioned part of NHQ's system?

Having the entire application be web based would significantly up the amount of bandwidth required to run the system.

Why would that be? We're talking mainly text throughput. As long as you didn't do something knuckleheaded like write the site in flash or java, I think you'd be fine with a dialup connection.

Another issue that I recall from the IMU is the lack of access for unqualified and underqualified members. I found this to be a pretty outrageous design decision, where only people holding certain CAP ES qualifications could log into and use the system. As a mission IT person, I found it impossible to get the system up and running. I had to take some time off to become CUL qualified so that I could get familiar with it.

[wuzafuzz]

Well, in a perfect world with always-on connectivity, plug 'n play LAN's, and lots of IMU Kool-Aid:

Can IMU accomplish check-in's with a barcode scanner?

Can the same database be used for planning and to print the IAPP/IAP (including ICS forms) and be updated with new member data as the exercise date rolls around?

Can included ICS forms be customized by location for those who want to roll their own forms?

I've only heard of this so far, but if it is true we are supposed to enter grid or lat long coordinates in some mysterious code for IMU tracking, can IMU do the conversion so the radio operator doesn't have to?

[wuzafuzz]

Another issue that I recall from the IMU is the lack of access for unqualified and underqualified members. I found this to be a pretty outrageous design decision, where only people holding certain CAP ES qualifications could log into and use the system. As a mission IT person, I found it impossible to get the system up and running. I had to take some time off to become CUL qualified so that I could get familiar with it.

:clap: :clap: :clap: :clap: :clap:

[Robborsari]

So this is going to continue to tie into the WMU instead of being a sanctioned part of NHQ's system?

Having the entire application be web based would significantly up the amount of bandwidth required to run the system.

Why would that be? We're talking mainly text throughput. As long as you didn't do something knuckleheaded like write the site in flash or java, I think you'd be fine with a dialup connection.

Another issue that I recall from the IMU is the lack of access for unqualified and underqualified members. I found this to be a pretty outrageous design decision, where only people holding certain CAP ES qualifications could log into and use the system. As a mission IT person, I found it impossible to get the system up and running. I had to take some time off to become CUL qualified so that I could get familiar with it.

IMU ties into both WMU and NHQ.  The WMU system is sanctioned by NHQ in that WMU and IMU can both exchange data with WMIRS for updating sorties and form 18 data on the assets.  WMU holds the archive of past missions, generates the IMU database for a wing from the national database and manages the phone list and vehicle information in the generated database.  IMU is integrated with WMIRS to upload vehicle and aircraft sorties either before or after they are complete.  It works for both 104 and 84 sorties as well as 1st AF sorties. 

Another disadvantage of a web based system is that all the data would be stored at the server end.  If you suddenly lost your internet connection you might not be able to access your 211s, comm logs and incident logs or your 106s.  Unless you have been printing them out as you update them which would negate much of the usefullness of the system.  With a client that runs on the workstation we can do a lot of work locally without hitting the server which reduces bandwidth, speeds up processing, and provides every workstation with a syncronized copy of the database in the event that network connection is lost.

The minimum ES qual for using IMU is MSA.  That is a pretty low bar but anyone without MSA should not be manipulating data in the system.  I don't really see it as outrageous.  It is perhaps true that someone without MSA qual could benefit from access to the system for training but I think having that as a minimum requirement for manipulating data is in keeping with the intent of having an MSA qualification in the first place.

I took a look at 60-3 and all I can find on the subject is on page 11:
e. Only personnel holding a valid CAPF 101 (or authorized on equivalent computer rosters noted below) containing the
applicable specialty rating(s) may be assigned to perform duties on CAP operational missions. Properly documented individuals in
training for a specialty rating may only perform mission duties under the supervision of fully qualified personnel.

Seems to say that since there is an MSA qual you need it to A the MS. 

[Robborsari]

Well, in a perfect world with always-on connectivity, plug 'n play LAN's, and lots of IMU Kool-Aid:

Can IMU accomplish check-in's with a barcode scanner?

Can the same database be used for planning and to print the IAPP/IAP (including ICS forms) and be updated with new member data as the exercise date rolls around?

Can included ICS forms be customized by location for those who want to roll their own forms?

I've only heard of this so far, but if it is true we are supposed to enter grid or lat long coordinates in some mysterious code for IMU tracking, can IMU do the conversion so the radio operator doesn't have to?

Checkin is by capid or by name.  If you type in an ID or start typing in a name it autofills until you get the person you want.  For example My name hits after bors  in my wing.  It is a pretty quick process to find people.  It is possible to use a barcode scanner with a keyboard wedge to fill in the number.  I am not sure if it is faster than typing or not.  I would guess about the same. 

The database can be used for planning and locating qualified personnel in the wing.  Quals can be updated from the web at checkin time if they have changed since the database was generated from national.  If there is no internet access the quals can be entered by hand off the 101 card.

Right now I would have to say no to customizing the forms.  In reality you could edit the raw files that we convert into the PDFs.  That mechanism will change for release 3 and we have not finished it yet so I am not sure what it will look like exactly.  This is all behind the scenes stuff for users.  It will still print when you hit print but I don't know exactly the file formats and conversion tools.  What do you want to do to the forms?  If it is something that everyone customizes we can probably make it customizable.  I am just not sure what it would be.  More info please.

Some wings, and I have never run into this, use a hash of the coordinates with the pilots capid.  The IMU does have a tool to decode these coordinates in the comm module.  It is an option that can be turned on and off.  100-3 would seem to prevent using this.  On page 9 it says:

a. Codes and Ciphers. Locally designed codes or adaptation of official codes, however well intentioned, will not deceive a cryptanalyst; only officially authorized codes are to be used. It has become a practice within CAP to assign "code words" to various mission events, in the belief that doing so will conceal these events from an undesired listener. This practice is seldom effective, violates the principles of the Incident Command System and is therefore not authorized.

I have not found any other reference to authorized codes.  If this is an authorized code could someone send me a reference?

IMU uses regular coordinates with DD MM.MM format. 

[Robborsari]

The 3 biggest issues I have with IMU are:
1. Stability, or rather lack thereof
2. User unfriendliness - it's a pain in the back side to use
3. Double the work load - it is far easier to run with manual forms than use IMU for many functions. The last few SAREX's I've been to, signing people into the exercise on IMU took two-three times as long as paper forms. Even longer if they had a vehicle. Becuase of 1, everytime IMU was used, paper forms were used to ensure proper documentation.

Networking is also an issue - I attended a class on IMU. It took two hours to get 15 computers working on the networked IMU.

Admittedly, I haven't tried to work with IMU in a year or so due to these problems, so some may have been fixed, but I'm not in any hurry to try it out again.

An issue I have with my home computer (which is where I would like to have it installed for practice purposes) is that IMU doesn't like it. IMU asks for a font that is installed in the proper location, but IMU can't find it. Contacting Pete Anderson resulted in a "well, I guess it won't work for" after trying to troubleshoot it.

1) Stability has been a problem.  It is a complicated system and does require networking to fully function in a multi computer shared database environment.  We are working on that.  The intention is to make it as simple and stable as possible.  That does not mean that you can set up a 10 computer lan with your eyes closed.  It means that the IMU will not be the major problem you are struggling with.  Ad-hoc network setups are always a problem for many reasons.   One thing that has helped me is setting up standards for a mission network.  We use the same ssid and key for every mission.  That way once you set up a computer it is ready for the next one.  (mostly ) This is windows.

2) yeah it kinda is.  Sorry.  Working on it.  There is a lot of stuff to cram into those windows.  We are working on making everything resize that can use resizing, like data grids and stuff and also adding busy cursors where approprate.  I want to make the workflow more wizard like as well but it is hard to do with a lot of the tasks.  For example, creating a 104.  You need a crew, a task, and an airplane.  Sometimes it makes sense to arrange your crews then the tasks.  Sometimes you have tasks but no crews or airplanes yet.  It is a multipart problem.  Right now the only answer is to try and tag the required items on each tab and train operators in what is necessary to complete a sortie.  The goal is to codify the process we already go through when we dispatch a crew to perform a sortie.  What are they going to do?  Who do they tell about it and when?  What is the weather there?  What airplane is it, who is flying, who is the observer.  Are they qualified, current and everything.   It is a lot of data that makes up a 104 or 84.  With the database we can automatically pull in the items like the comm briefing that are the same for each sortie and allow the aobd to focus on making sure the crew has the best information that will allow them to complete the mission.

3) I have heard this a lot, and I don't think it is really true.  IMU does not require you to do more than what is required in the regs to perform the functions of the position.  That is a design goal.  It allows you to do more and do it better than trying to do it all by hand but the only required items are the minimum that are needed.  I believe the issue is one of training.  When you first start with IMU it is bewildering, there are fields everywhere, a lot of data and a lot of buttons.  Particularly in the flight area where there is a lot of information that makes up a 104.  It does take longer to type everything in and figure out that you have to create taskings in the tasking tab and crews in the resources unit and then put them together in the 104.  Once you are comfortable with the process it will get much faster for you and you will see how to take advantage of the tool to automate the repeatitive parts. 

The checkin example is a good one.  I find that the checkin process goes much faster with IMU.  Instead of having every person fill out a form by hand and write down their qualifications all you need to enter is Who they are, where they came from and how they got there.  The qualifications are pulled from the database.  They step up to the table, hand in a 60, show the id and 101 and they are done.  We often set up 2 or 3 laptops in the check-in area to process the inflow at the begining of a mission.  Later 1 will do for checkin and out.  You are right that the system has to be up and running for this to work.  No way around that.  If you try to do everything on paper at the same time then it will add more workload.  But I am betting that the IMU checkin goes faster than the paper one.  And once you are comfortable with the process and drop the paper you will fly through it.  I also think that the 211 generated is "better" than the hand filled out one.  You can read it for one thing, all the qualifications are listed instead of just the one thing they plan on doing as I so often see on the 211 and everyone in the mission can pull it up and see who is signed in or even search for qualifications in the signed in personnel.  The transition period while you get your people trained and get to the point that you can use the IMU without  filling out forms by hand in parallel is alot more work.  I think in the end it is worth the advantages.

I will PM you my cellphone number and email.  If you want to try again I will get it working on your system. 

[arajca]

It needs a practice/training/play mission set up to allow members to work on it without fear of messing anything up. Particularly if they have actual missions saved on their computer.

[Robborsari]

It needs a practice/training/play mission set up to allow members to work on it without fear of messing anything up. Particularly if they have actual missions saved on their computer.

Good point.  I should mention how I handle that.  Usually I leave a mission on the server with a number like 09T9901 or something.  It can be anything that does not match a real mission.  If you try to upload anything to wmirs it will discard it because it does not have a mission to save it too.  The only thing you need to avoid is uploading to WMU via the database management tab.  It will work because missions are created in IMU first.  Even that will not interfere with anything, just create a dummy mission in the archives.  Beyond that creating a new dummy mission is very quick and easy.  There is a built in test mission but it is not really suitable for practice use.  It is easier to just create a dummy mission and avoid uploading it to the archive.

[arajca]

Aother crazy idea:
Add an Activity mission that does not require a qualified IC. That would allow a unit to use IMU for unit activites which will improve comfort and abilities with it. A unit running a local ES weekend may not be able to get a mission number and may not have an IC on hand, but will have a Activity Director/Commander/etc instead.

Again, getting people to use IMU regularly will improve its familiarity and reduce many of the headaches when using it at incidents - typically when you need to spend an hour or more (that you usually don't have) training the users so they don't crash the system and can be effective. At most SAREXs where it's been used, it is used in a second string role. Fill out paper then, when time permits, figure out how to enter the information into IMU.

[w7sar]

Not a huge issue...but since you asked....

In the Incident Phone Book, it would be nice if I could change column widths.  And could change the order of the columns.  i.e. The Notes field is often more important than the email (which is blank for most of our entries).  The window doesn't scale so I can see the whole field -- so the notes field only shows 20 or so characters when there are lots more.  For example, I may have a name of "Daggett County Sheriff" and the notes field has the sheriff's name or the lead SAR officer's name, etc.  I'd love to be able to change how the display looks so I don't have to spend time scrolling left/right or clicking on an entry and then scrolling right in the display/entry windows.

Thanks!
Jerry Wellman
Utah Wing

[Robborsari]

Not a huge issue...but since you asked....

In the Incident Phone Book, it would be nice if I could change column widths.  And could change the order of the columns.  i.e. The Notes field is often more important than the email (which is blank for most of our entries).  The window doesn't scale so I can see the whole field -- so the notes field only shows 20 or so characters when there are lots more.  For example, I may have a name of "Daggett County Sheriff" and the notes field has the sheriff's name or the lead SAR officer's name, etc.  I'd love to be able to change how the display looks so I don't have to spend time scrolling left/right or clicking on an entry and then scrolling right in the display/entry windows.

Thanks!
Jerry Wellman
Utah Wing

The resize issue is on the list already.  I will look at being able to change the order of the columns and resizing the individual columns.  It should not be too hard.

[RiverAux]

Is it still requiring the ancient version of .NET to run?  Can we get it updated to run with the stuff that is actually being used on modern computers?

[Robborsari]

Is it still requiring the ancient version of .NET to run?  Can we get it updated to run with the stuff that is actually being used on modern computers?

I am glad you asked that...  We are currently working on the beta release of IMU3 which will use the .net 3.5 framework.  There is an announcement about it that appears during the install of or upgrade to .29.