Need suggestions for new IMU features

[RiverAux]

Time frame? 

[Robborsari]

Time frame?

uhh.  Last weekend?  Hmm.  Still working on it.  Soon.  Really soon. 

[dbaran]

My requests:

a) Much better resiliency when running across a WAN (internet).  The connection is going to drop occasionally - restablish it automatically, and don't make us shut down the entire application, reboot the PC, and sign in again.

b) Make it very clear when a data field update doesn't complete successfully.  On our last evaluated SAREX, we used it and had multiple examples of different data being presented on different computers.   We finally tracked it down to the fact that the database updates weren't being committed on the server, but the sending computer thought they were, so it had a different view than the other systems did.

c) Give us a lot of space to put in comments that should go along with the airplane.  When we have to change target requests, I want to be able to put it into IMU so that the other mission bases see how the tasking has changed after the sortie launched.  Also give us a place to put in the sortie results / crew debrief info.

d) Forget the whole concept of building crews.  Let us do sorties where we put the actual crew in for the sortie, and when we change who is in the airplane, it is linked to the sortie.  We had cases where we built crew A, someone else started a sortie, and then the crew builder was told of a change.  They changed crew A and it wasn't picked up on the sortie. 

e) Give us a place to put in the current cell phone number for the people in the plane.  We always get that info before they launch in CAWG (so we can call one of them as a first step when they miss a checkin) - now, it goes onto post it notes on the computer until the crew is back.

f) Have a way of showing which mission base is responsible for a particular sortie.  We had a bunch that would be briefed by a base 300 miles away from the one that would debrief them.  When the plane is out in the grid, which base is watching them?  How can someone tell from looking in IMU?

I have probably another 5-10 pages worth from the last evaluated exercise - PM me and I'm happy to go through them with someone who can make them happen. 

[Short Field]

Provide the capability to either export the Availibility list (a format Excel can import would be nice) or at least print it.

[Eclipse]

Instead of multi-user access based, how about a web front end with the central machine acting as a server?

That would be much more robust connection wise and a lot easier to connect to, since all you'd need is a browser and a LAN, no special clients.

And NO ACTIVE X!  Browser independent, please...

[lordmonar]

I have another request for IMU.

ICS allows for a single individual to be assigned multiple jobs....but IMU does not allow you to do this.

[Robborsari]

My requests:

I will put my answers inline.

a) Much better resiliency when running across a WAN (internet).  The connection is going to drop occasionally - restablish it automatically, and don't make us shut down the entire application, reboot the PC, and sign in again.

The change to http transport instead of .net remoting handles this.  There is no reconnection when using the virtual internet server client mode.  In IMU3 all modes will use http.

b) Make it very clear when a data field update doesn't complete successfully.  On our last evaluated SAREX, we used it and had multiple examples of different data being presented on different computers.   We finally tracked it down to the fact that the database updates weren't being committed on the server, but the sending computer thought they were, so it had a different view than the other systems did.

This is not something we can really control without adding a lot of overhead.  We have to trust all the M$ bits like JET and .net to do their jobs.  If it had failed on the host we would have seen it.  Silent failures are something that we will always have a problem with.  I am working on background process updating of the db but it is a major change and it will be a while before it is ready to be tested.

c) Give us a lot of space to put in comments that should go along with the airplane.  When we have to change target requests, I want to be able to put it into IMU so that the other mission bases see how the tasking has changed after the sortie launched.  Also give us a place to put in the sortie results / crew debrief info.

I am not sure what you mean by "go along with the airplane" Anything that happened during the sortie such as a retasking will be described in the debrief.   I could see having a second line under the tasking name in the status board that could be updated by comm or ops to contain additional status info.

The debrief info is entered on the debrief tab.  Reports of sightings by the aircrew automatically generate 106's.

I need more info about what you are requesting here. 

d) Forget the whole concept of building crews.  Let us do sorties where we put the actual crew in for the sortie, and when we change who is in the airplane, it is linked to the sortie.  We had cases where we built crew A, someone else started a sortie, and then the crew builder was told of a change.  They changed crew A and it wasn't picked up on the sortie. 

This is an area we are struggling with.  The crew exists seperate from the 104 so that a crew can be formed and reused for multiple taskings.  It is less effecient if you don't create crews and keep them together. If you use the sortie preplanner by setting the date ahead in the flight ops screen you can assign anyone to any position on the aircraft.  It does not limit you to people who are signed into the mission and is intended to create sorties when you know what you want to do in advance.  The crew is associated with the 104 when the ATD is entered.  (The took off so no one is getting in or out)  It does make it harder to correct typos or mistakes in crews. 
You have to remove all the dates, change the crew, then re-enter the dates.  I am thinking of a couple of changes in this area.  Maybe a checkbox that lets you enter a sortie crew that is only for this sortie or a "crew editor" that lets you change people to fix mistakes after the fact.  It is on the list but not a very high priority at the moment because it works.  It could be better and perhaps needs a thread of its own to hash out the options.

e) Give us a place to put in the current cell phone number for the people in the plane.  We always get that info before they launch in CAWG (so we can call one of them as a first step when they miss a checkin) - now, it goes onto post it notes on the computer until the crew is back.

This is a good idea and it has been incorporated into the new 104.  It has a section for crew contact info, cell numbers email or whatever.

f) Have a way of showing which mission base is responsible for a particular sortie.  We had a bunch that would be briefed by a base 300 miles away from the one that would debrief them.  When the plane is out in the grid, which base is watching them?  How can someone tell from looking in IMU?

The assignment field on the status board shows the short description of the tasking.  The tasking starts with a base and date (TYS09 for example)   If you have your bases set the taskings generated at the different bases will be indicated there.  When you change the description from the default genereated one leave the base/date code on the front. 

I have probably another 5-10 pages worth from the last evaluated exercise - PM me and I'm happy to go through them with someone who can make them happen.

I will do that.  Thanks.

[Robborsari]

Provide the capability to either export the Availibility list (a format Excel can import would be nice) or at least print it.

I think that is available through WMU.   I will look at it.

[Robborsari]

Instead of multi-user access based, how about a web front end with the central machine acting as a server?

That would be much more robust connection wise and a lot easier to connect to, since all you'd need is a browser and a LAN, no special clients.

And NO ACTIVE X!  Browser independent, please...

Doing it that way would break a major feature of IMU.  IMU works as a standalone workstation, on a local lan with no internet access or across the internet. 

Putting everything on the server would only function at bases where there is internet access.  I see that as a big step backwards in functionality.  It would be a lot easier on us to only have server code to update but I think we would loose too much flexability.

[Robborsari]

I have another request for IMU.

ICS allows for a single individual to be assigned multiple jobs....but IMU does not allow you to do this.

Yeah.  That is a problem.  Certain positions have different restrictions and freedoms than others.  It is pretty much one person one job right now.  I would recommend assigning people to their primary job in the resources module.  Any secondary positions they have can be tracked using the org chart in the 201.  This one will take some thinking on.  Do we allow multiples anywhere or try to enforce things in the software.  its on the list to be looked at.

[Robborsari]

I just wanted to say generally to everyone, thank you for the suggestions.  This is exactly the kind of discussion I want to have.  It is hard to make a single program work for everyone and we need the feedback from folks in different areas to help make the software more usable for everyone.   I don't put this in every reply but thank each of you who has contributed and keep it coming. 
p.s.  Thanks for your patience as well. 

[lordmonar]

Rob,

Thank you for trying to fix the IMU!

[wacapgh]

Instead of multi-user access based, how about a web front end with the central machine acting as a server?

That would be much more robust connection wise and a lot easier to connect to, since all you'd need is a browser and a LAN, no special clients.

And NO ACTIVE X!  Browser independent, please...

Doing it that way would break a major feature of IMU.  IMU works as a standalone workstation, on a local lan with no internet access or across the internet. 

Putting everything on the server would only function at bases where there is internet access.  I see that as a big step backwards in functionality.  It would be a lot easier on us to only have server code to update but I think we would loose too much flexability.

I think he means server=one local system holds the "master" copy of the data and all the others are clients. Not server=some big system out on the internet.

[Short Field]

When the wing server has went down in the past, we simply desigated another server as the database host.  This was on the other side of the state. 

There are real advantages to not needing a internet connection to run the IMU.  I have ran missions in Local mode, then once the internet connection was available again, I uploaded the data to WMIRS and the WMU.   A new wing database was created (about five minutes?) and I downloaded a new wing database and went right back to work on the same mission but using the Virtual Internet Server Client mode instead of Local. 

[Robborsari]

Instead of multi-user access based, how about a web front end with the central machine acting as a server?

That would be much more robust connection wise and a lot easier to connect to, since all you'd need is a browser and a LAN, no special clients.

And NO ACTIVE X!  Browser independent, please...

Doing it that way would break a major feature of IMU.  IMU works as a standalone workstation, on a local lan with no internet access or across the internet. 

Putting everything on the server would only function at bases where there is internet access.  I see that as a big step backwards in functionality.  It would be a lot easier on us to only have server code to update but I think we would loose too much flexability.

I think he means server=one local system holds the "master" copy of the data and all the others are clients. Not server=some big system out on the internet.

Right now the database exists on both the server and the clients.  The server is the transaction broker for everyone but the client databases are complete copies.  If something happens to the server then any other system will have a complete copy of the data and can become the server. 

What has been requested here is to have a single machine run the software and serve the interface to all the users as html (or whatever) pages.  This requires a network connection and introduces a single point of failure in the server.  On the plus side there would be zero configuration for the clients and simplified administration due to the single location for the software. 

I think the current approach provides redundancy of data that is key to surviving a hardware failure such as a harddrive dying or a network failure that would be lacking in the server - browser solution. 

[a2capt]

Before you get too carried away with feature creep..

How about concentrating on the UI a bit. It's basically AWFUL.

How I get people to understand it is this:

Take the paper forms, think about their intended function, do it EXACTLY that way, you can't launch a mission .. until the folks have signed in, the resource has signed in, etc. You can't relaunch an asset until the prior sortie is closed. In "real life" that happens, the aircraft comes back, keys get forked over, it's gone again, the crew is still waiting at the debriefing table, working their way through the system.

This thing needs to "let go" and stop being so [darn] anal. It can literally turns a one IC simple mission into something that takes longer than needs to be. It's a great example in it's current form, of why people hate technology.

[Short Field]

You can't relaunch an asset until the prior sortie is closed.

All that has to happen is for a sortie to have a ATA entered before you can relaunch it. 

[RiverAux]

I think it would be nice if there were a "basic" version of this program that didn't require that every single bit of information on every CAP form be entered in order for it to work correctly.   

What I would envision would focus more on information management rather than resource management.  For example, being able to just track stuff like whether or not tasks have been done without having to keep track of every individual and plane/van involved in doing it. 

I can't really say what I would like beyond that, but I think a2capt was on to something about needing a system that is a little more flexible about leaving blank spots.  Yes, this means the system won't be as helpful in making sure some detail isn't overlooked, but if the choice continues to be to dot every i and cross every t or not use IMU at all, many will choose the latter.     

[Short Field]

The "flaw" in a lot of the IMU processes is that it was written to function as a checklist.  Running a mission on paper is easy - if you leave blanks, put down wrong numbers, and just ignore things, it lets you go ahead as if you really knew what you were doing.   The IMU requires you to do it correctly or it does not play well.   The IMU is hard to use if you just had a two hour training sessions consisting of powerpoints, then didn't touch it for six months. 

[RiverAux]

Running a mission on paper is easy - if you leave blanks, put down wrong numbers, and just ignore things, it lets you go ahead as if you really knew what you were doing.   The IMU requires you to do it correctly or it does not play well.   

Exactly why a basic version is needed for those who choose NOT to take the time to enter everything in a computer.  Since I don't know many mission staff who are willing to run entirely on computer, some essential stuff will continue to be done on paper and if the only way to run IMU is to put EVERYTHING in the computer including the stuff they're still going to be tracking on paper, they're going to be very resistant to using it at all because of the extra time it will take to maintain it. 

For example, if there was an option to track the assignment and status of aircraft and ground teams without having to also track the individuals and all their qualifications it would make life a whole lot simpler.   You spend so much time getting all the personnel stuff straight (especially if you have internet or capwatch download issues) that it can defeat the purpose.