CAP Talk

Hi.  Anyone have ideas for what they would like to see in future releases of IMU? 

Some examples:

ICS213 messages online to staff and printed to outside agencies.

Closer integration with google earth and mapping tools

Financial tracking that estimates spending for planned sorties and demobilization sorties.

Any other ideas?

Is having it go away an option?

Quote from: Eclipse on June 18, 2009, 03:27:55 PM
Is having it go away an option?

I like that option, can we also have CAPSTAR and WMU go away?

I would begin by making it web based. Extend WMIRS.

Quote from: jeders on June 18, 2009, 03:29:03 PM

Quote from: Eclipse on June 18, 2009, 03:27:55 PM
Is having it go away an option?

I like that option, can we also have CAPSTAR and WMU go away?

Yes, please.

These proprietary systems that require Access to use and fairly advanced tech skills to get functional are
a last-century kludge.

We need to take  fresh look at the info actually needed by onscene IC's and staff, and realize that 90% of folks in these positions have internet on their cel phones and 90% of our operations occur after most power and connectivity have been restored, so the old-school "we can only use Armageddon-grade, stone-tablet-level technology" needs to go away.  Keep some backup white boards in your kits and
use the big hammer anytime you can.

In a few hours last month, during a practice mission, myself and few other staffers through together a PC-based status board system that is light-years easier to use and more effective than the IMU - its based on Excel and Powerpoint, with all low-grade, easy tech.  We've already been told that anyone with a little VB experience could automate it better in a few hours and the whole thing would live on a
chip, completely portable.

I've literally already tested it and it runs on my old (5 years) Windows Mobile phone.

Clearly the answer is to start from a centralized solution at NHQ. Something database driven, and online, where the data isn't subject to computer or power outages. Once that is in place you can build various front-ends, like a web front-end (including mobile phone-friendly pages), an SMS front-end, or maybe even a voice front-end (press 2 for a list of available GTLs).

I heartily second the suggestions from Eclipse and Jeder.  I saw a mission for a missing airplane get so bogged down as to be ridiculous because the focus became one of feeding data into the IMU.  Went from launching aircraft at 0700 to finally getting the first one out the door t 0930, all because the IMU had to be fed(or so the experts said).

Quote from: bosshawk on June 18, 2009, 05:31:19 PM
I heartily second the suggestions from Eclipse and Jeder.  I saw a mission for a missing airplane get so bogged down as to be ridiculous because the focus became one of feeding data into the IMU.  Went from launching aircraft at 0700 to finally getting the first one out the door t 0930, all because the IMU had to be fed(or so the experts said).

And that is why I am not a big supporter of the IMU. It always seems to crash at the most inoptune time.  I have used it from home when running a small mission with no trouble, but at a large scale missions I have found that you need a full time IT guy to keep it running and to support the users.

Quote from: Robborsari on June 18, 2009, 03:26:40 PM
Hi.  Anyone have ideas for what they would like to see in future releases of IMU? 

Some examples:

ICS213 messages online to staff and printed to outside agencies.

Closer integration with google earth and mapping tools

Financial tracking that estimates spending for planned sorties and demobilization sorties.

Any other ideas?

Are you someone that can actually get these suggestions implemented, or are you just asking a general question?

One issue I have with IMU is how we sign in and out of the mission base.

In IMU you are either signed in and available, assigned to a flight or ground crew and not available or you are signed out.

For planning purposes and tracking purposes there should be a way in IMU to show people who are signed in to the mission but are not available due to being "off base" for crew rest, lunch, out running errands, etc.

I am looking at this in a fosset search situation.  Where a member deploys for a multi-day mission.   The Logistics Section Chief is in charge of those people who are not currently signed in to the mission base but there is no way for him to track them in the IMU.

This would allow planners to build crews from those where are not currently at the mission base so they can be ready to sortie as soon as they report for duty following crew rest.

Addressing everything generally:

Going away is not really an option.  Being web based at national is a big handicap because you would need internet access at every mission base.  WMIRS is a good way to submit the info for the sorties but it does not do anything else. 

IMU does need to be more stable, faster and more streamlined but it does a lot more than simply update a status board or print 104's.  The database uses the jet engine and .mdb file but you don't need access installed to use it.

The data is maintained on the server and on every client.  If a network or power failure occurs any client can become the server with no loss of data.  Any client can also be used in local mode with no server or network at all.  The latest versions use a http based server that do not have port issues with firewalls. 

I have heard a lot of complaints about crashing and the time it takes to enter data.  Stability is a very important feature for a mission critical application and so is speed.  The time it takes to use it goes down with training and practice.  The stability is being worked on as is the speed of the tool.  The goal is to automate the repetitive things and allow the staff to focus on the mission, not the paperwork. 

I ran a mission last month as a solo IC with 6 air sorties and had all the paperwork turned in 2 hours after the last sortie had landed.  Most of that 2 hours was waiting for the fuel receipt.  I really like being able to enter the data into IMU and printing out all the ICS forms that we are now required to turn in with every mission.

One recent new feature is a web based status board that allows anyone to view the status board without having IMU installed on the computer.  All you need is a browser and a network connection to the server.  It is also viewable on portable devices like a blackberry or iphone.   There are currently no plans to provide data input through the web page interface only status.


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 am working on the first things I listed as well.  If you have looked at IMU before it might be worthwhile to look again.  There have been many improvements and there are more to come as well.

Quote from: Robborsari on June 18, 2009, 10:08:08 PM
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?

Quote from: Robborsari on June 18, 2009, 10:08:08 PMCurrently 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'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. 

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.

Quote from: Eclipse on June 18, 2009, 03:27:55 PM
Is having it go away an option?

I'm going with this one.

Quote from: flyerthom on June 19, 2009, 05:46:36 AM
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.

Added: It would be awesome if it didn't crash when you want to do things.

I am all for a web app.  I tried developing a prototype of a web app once, but Ops wanted IMU, so that was fail.

I would love to provide a shopping list of changes, but the realiity is I would rather see it go away. 

I'm tired of trying to maintain paper logs alongside attempts at using IMU.  Instead of concentrating on our jobs we are troubleshooting computers and figuring out how to fall back to paper when online systems fail.  The bigger the mission staff, the more pronounced the problems become, in my experience.

You could argue the install and networking issues should be completed prior to a SAREX or mission, and you would be right.  If we were all full time paid employees the situation would be different.  If we had permanent facilities to run our operations from, it might be different.  If we had an adequate fleet of CAP owned laptops, my view might change.  Since we rely heavily on member owned computers, keeping up with version changes and other networking issues creates an unreasonable maintenance challenge.  It causes failures.

Any application we use to run missions needs to be simple and bulletproof.  The technical hurdles should be transparent to the end users.  We cannot justify the need for an IT staff at each mission or exercise when we sometimes struggle to fill other positions.

If the IMU application must remain, web based would be great.  If staff can fire up their laptops, login to a website and the same mission database, and start working, then you'd have something.  Have a solid backup plan for those times when network availability is nonexistent. 

I am not a technological luddite.  Computer systems is my full time job.  Something like IMU would be a good fit for many organizations.  When IMU becomes a turnkey solution for the majority of our members, it may be a good fit for us.  Since most of us don't have permanent locations to hang our hat, we usually have to improvise mightily when a mission scales too large to run out of the IC's house.  When that happens we frequently must build ad hoc systems out of duct tape and baling wire.  That is a plan for failure.  It's a marvel we succeed as well as we do.

Quote from: Robborsari on June 18, 2009, 10:08:08 PMBeing web based at national is a big handicap because you would need internet access at every mission base.

How often do mission bases not have internet access? I can't remember the last SAREX I attended where half of the staffers didn't have mobile internet. Years perhaps?

^I think having a web based application (requirement for use) might be tough. 

This year if our wing had participated in ice storm clean-up our mission base would not have had internet access.  90% of the state lost cable and telephone, cell phone towers were pretty maxed.

In the DR arena you operate where infrastructure has been destroyed and the luxury of electricity, internet and telephone decreases significantly.

SAREX environment operates under ideal circumstances.

Quote from: N Harmon on June 19, 2009, 01:51:27 PM

Quote from: Robborsari on June 18, 2009, 10:08:08 PMBeing web based at national is a big handicap because you would need internet access at every mission base.

How often do mission bases not have internet access? I can't remember the last SAREX I attended where half of the staffers didn't have mobile internet. Years perhaps?

Lack of Internet and mobile phone access should be expected for DR missions.  It'll be great if you do have it.

It's not unusual to have no Internet access.  A few people might, but it's not available to the rest of us who may be running part of ops in other buildings.  We are at the mercy of existing connections in the buildings we are borrowing for the weekend.  My last SAREX found limited connectivity using an access point pointed at another hangar a few hundred feet away, where a little signal was leaking out a window.  We cannot count on it.  Many of us don't have mobile Internet access.

People more creative than me might have some good solutions.  Having Internet access would permit a web based IMU.

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.  ;D

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.

Quote from: RiverAux on June 19, 2009, 12:33:51 AM
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

Quote from: Who_knows? on June 18, 2009, 11:43:02 PM

Quote from: Robborsari on June 18, 2009, 10:08:08 PM
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.

Quote from: flyerthom on June 19, 2009, 05:46:36 AM
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.

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.

Quote from: lordmonar on June 19, 2009, 12:21:46 AM

Quote from: Robborsari on June 18, 2009, 10:08:08 PMCurrently 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

Quote from: swamprat86 on June 19, 2009, 02:32:00 PM
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.  ;D

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.

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

Quote from: Robborsari on June 19, 2009, 03:44:22 PM
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.

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?

Quote from: N Harmon on June 19, 2009, 07:10:53 PMAnother 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:

Quote from: N Harmon on June 19, 2009, 07:10:53 PM
So this is going to continue to tie into the WMU instead of being a sanctioned part of NHQ's system?

Quote from: Robborsari on June 19, 2009, 03:44:22 PM
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. 

Quote from: wuzafuzz on June 19, 2009, 07:25:44 PM
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. 

Quote from: arajca on June 19, 2009, 02:54:22 PM
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. 

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.

Quote from: arajca on June 20, 2009, 02:09:29 PM
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.

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.

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

Quote from: w7sar on June 29, 2009, 07:02:29 PM
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.

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?

Quote from: RiverAux on July 04, 2009, 02:17:41 AM
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.

Time frame? 

Quote from: RiverAux on July 04, 2009, 06:05:39 PM
Time frame?

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

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. 

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

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...

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.

Quote from: dbaran on July 10, 2009, 03:47:01 AM
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.

Quote from: Short Field on July 11, 2009, 05:28:58 AM
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.

Quote from: Eclipse on July 11, 2009, 05:38:45 AM
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.

Quote from: lordmonar on July 11, 2009, 11:41:53 PM
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.

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.  :)

Rob,

Thank you for trying to fix the IMU!

Quote from: Robborsari on July 12, 2009, 02:43:07 PM

Quote from: Eclipse on July 11, 2009, 05:38:45 AM
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.

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. 

Quote from: wacapgh on July 13, 2009, 09:02:40 PM

Quote from: Robborsari on July 12, 2009, 02:43:07 PM

Quote from: Eclipse on July 11, 2009, 05:38:45 AM
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. 

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.

Quote from: a2capt on July 18, 2009, 01:17:37 AM
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. 

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.     

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. 

QuoteRunning 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. 

Don't forget that the major function of the IMU to handle the mission data so it can be uploaded into WMIRS.   I have had SARs that the IMU refused to load into WMIRS until I went back and corrected some blank/incorrect entries.  A pain, sure, but worth it when closing out a mission.  You just can't "fudge it" when using a computer.

And this is one of the reasons using WMIRS for tracking is winning in my area -- it is doing what I suggested and not worrying about who is doing the actual flying or driving.  You can enter in your WMIRS sortie data a whole lot faster than trying to go through the entire IMU process.  Its easy enough to look at a WMIRS screen and see blank spots where there should be data. 

Sure you can use WMIRS for tracking.  You can put in a sortie to be flown, then update it when you have a ATD, followed by adding a ATA and completing the required information.  WMIRS is also showing all the sorties flown on the mission, so on day four, the first sortie of the day could easily be sortie #67.  I think it would be a lot easier to just use some paper or a wall board to track the missions.   

I don't understand your comment about "not worrying about who is doing the actual flying or driving".    If anything bad happens, that is one area that everyone is going to be extremely worried about.

Well, obviously that info is still tracked, but on paper.  Right now it is still much easier to maintain the info about who is on a crew or team on the tradiitonal paper forms that will continue to be used even if IMU is used than jumping through all the hoops in IMU to verify that every single member is current and qualified in that job.  If for some reason the IMU thinks your mission pilot isn't qualified you could spend quite a lot of time fixing all the things you need to do to correct that in the computer even if you could verify it with your own eyes in seconds based on what the pilot can show you on paper when he checks in. 

If the IMU says the pilot is not qualified, I am not going to trust any paper the pilot gives me.  I will first verifiy his qualificatins in eServices Ops Quals and then proceed as required.   You can also have the IMU update the individual's quals via the WMU.  Once in a great while, the IMU database will be over 30 days old.  Most of the time it is less than a week old.  That means any updates to personal qualifications would have happened in the last week or so.   

Keep in mind that I'm also factoring in all the connectivity and update issues discussed in previous pages of this thread.  If it were always as simple as you describe, it would be less of an issue. 

Just assume that anytime you start to use the IMU, you are going to have a new update and need a updated database.    The updates are really fairly fast - a new database can take up to five minutes.   If I am updating all the computers at the local mission base (13 computers), then I download to a flash drive and then use it to update the computers.  Normally, I just update the ones we are using that day - since it is almost a given we will have a new update before we use the other computers again.

DON'T STOP THE UPDATES - but maybe schedule them out every two weeks.

I would like to see if someone could incorparate multiple taskings in one sortie.  This is mainly focusing on DR work.  I would like to see aircraft tasking that will allow this feature.  Many of the taskings are short lived, it is a waste of time to have the A/C land so you can show a different tasking. 

If it is the same customer (i.e. agency paying for the fuel), then you should have no problem putting all the taskings on the 104.  There is really nothing you can do on a paper 104 that you can't do on a IMU 104.   

Different customers would require multiple 104s.  I actually believe you can switch a mission between 104s while airborne - takes a bit of constructive work (i.e. pretending the acft landed and then took off again for the second sortie) but it should be doable.  The main issue is allocating the flight time (charges) between the multiple customers.

I think what he was suggesting was the capability of inputting the 50 specific targets we might get assigned each as a separate tasking and then have the ability to assign 3 or 4 of them to a particular sortie, yet keeping the tasking separate.

This would help immensely in making sure that all of these individual targets are actually assigned and flown and lessen the chances that some will be dropped.

Sure when you get that list of 50 targets you could go through right at the beginning and start lumping them together into individual sorties, but life happens and it isn't unusual for a sortie not to complete all assigned targets.  If that were the case, the target that wasn't completed could easily slip through the cracks. 

I'm not kidding about 50 targets either.  Had that happen in my state not all that long ago. 

 That could be some tough programing!   A big reason to have a fully manned Planning Section.   

Love the planning section and am happy that my wing has really started using it in the last few years.  Don't see how we ever ran a big mission without one in the past.

I agree with what you said Aux.  Those 50 taskings may have been recieved from the same agency, but what about having new tasking come in once the aircraft has departed, if there was a way that having radio contact you could add the tasking, then drop this into the mission that would be a great help also.

But 50 taskings would not be out of the realm of what would be on each 104.  Also who is to say that all the taskings were recieved at the same time.  You enter each tasking as it is recieved.

hrm. Wouldn't that more likely to be 50 targets in one tasking for a sortie?

Just looking at it from a database background, each task (target?) would need to be entered into a task field.  That task field would then have to be linked to the TASK field for the CAPF 104.  The TASK (caps used to ID the CAPF 104 task filed) would need to accept multiple task fields and display (up to fifty??).   Each small task would have to have a separate debrief field - at least a field to show "sucessful or unsucessful".    It could get very complex quickly - plus the user would need to enter, move, update, etc, each task (target?).   

Sometimes paper can be faster. 

Quote from: ammotrucker on July 23, 2009, 12:17:34 AM
I agree with what you said Aux.  Those 50 taskings may have been recieved from the same agency, but what about having new tasking come in once the aircraft has departed, if there was a way that having radio contact you could add the tasking, then drop this into the mission that would be a great help also.

But 50 taskings would not be out of the realm of what would be on each 104.  Also who is to say that all the taskings were recieved at the same time.  You enter each tasking as it is recieved.

IMU allows you to retask a 104 sortie that has already departed.  There is a tab for it an everything so long as the new task is still assocated with the orignial requirment/customer.

They are talking about getting a customer request for something like photos of 50 key sites.  They want each of the 50 sites to be identified as a task and then the PSC would group the tasks together into something they can fly - resulting in something like 3 or 4 sorties.  Currently that would be 3 or 4  CAPF 104s with matching tasks.   They want this so that if sortie 2 only photographed 8 of the 12 sites they were suppose to phtograph, then 8 mini-tasks would be closed and the 4 mini-tasks not photographed would remain active and could be reassigned to another sortie.

Recommended Change:  Shorten the automatic verbage on the comm log.  I.E.  instead of automatically inserting "Operations Normal at 10:35" into the remarks section, use "Ops Nrml: 10:35".   Same for the other automatic insertions.  That would at least show some of the additional remarks that may be added on a mission.  This might not be an issue if the comm log screen is adjustable. 

Quote from: Robborsari on June 20, 2009, 07:07:11 AM3) I have heard this a lot, and I don't think it is really true.

I doubt you are suggesting your end-users are lying to you, but why not believe them? If they say it takes them longer to use your system than it does to use paper, it is. You identified the problems:

QuoteI 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.

As the software developer, you can resolve many of these issues. Streamline the process. Improve the GUI. Conduct usability studies. Watch brand new end users operate the software without prompting.

I suspect (but by no means know) that you are volunteering your time to maintain this software and you should receive thanks for doing so. At the same time, you've accepted the awesome responsibility of answering to the people throughout the country who are enormously dependent upon the software working correctly during mission critical situations. So when your users share their experiences with your software, you may want to believe them.

QuoteThis 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.

Sounds like who ever originally started this project chose the wrong development tools or platform. Failures should never be accepted as a cost of doing business.

I can run a mission (with building crews, taskings, briefings, flight releases, 104s, debriefings, comm log, IC log, etc) faster with the IMU than on paper.  The only exception is if I just fudge the paperwork and hope to catch up on the paper after the mission is over.

The IMU requires good initial training training for the positions a person will be working.  Then it requires currency training.  Too much of the training I have seen invovles a two hour class - of which the first hour is spent trying to get everyone's laptop up and running with the IMU.  Then they check-in five people, build one task, build one aircrew, maybe do the briefing for one crew and go home.  It takes a lot of practice (20 plus aircrews, taskings, etc) to get a feel for the IMU.  You also need to read the Help files.   Once you get up and really running with the IMU, it takes very little to stay current.

Again - it depends on your mission base function.  As a IC, I have had to learn all the funcitons.  But I started out just knowing the positions I was qualified for at the time.   That was just the AOBD functions for a long time - then I progressed to PSC, etc. 


No one can run a mission without a computer anymore.  Someone associated with the mission is going to have to enter the data into WMIRS - that is not an option.

I don't want to argue this with you but I want to point out that this item was in response to the complaint that it causes more work, not that it takes longer.  By that I mean requires you to do more than the manual process.  It does not cause more work, it requires you to do everything that you are required to do anyway.  I agree that it will take longer to use a program you are not familiar with than a paper form you are not familiar with.  Training and practice will resolve that issue.  It is not a question of truthfulness.

We do watch new users and provide training to them while looking for areas to streamline the process and improve the gui.   I believe the feedback I get.  That does not mean I think every statement made about IMU is correct.  I am always willing to be corrected :)  There is a lot of room for improvement and we are trying.  It is a big responsibility and I am very grateful to the folks who use the software and help us find the areas where it needs fixing and improvement.

Zero defect is a great goal.  When M$ acheives it we will be golden.  At least we will only have the bugs we write ourselves to chase down.  Until then we do the best we can.  The failures we suffer teach us more about how to work around the defects in the os and .net framework.  We are doing the best we can to minimize the chance of data corruption and to provide the best uptime possible for the IMU system as well as providing the most fault tolerant architecture we can.

Quote from: Fubar on July 24, 2009, 05:26:57 AM

Quote from: Robborsari on June 20, 2009, 07:07:11 AM3) I have heard this a lot, and I don't think it is really true.

I doubt you are suggesting your end-users are lying to you, but why not believe them? If they say it takes them longer to use your system than it does to use paper, it is. You identified the problems:

QuoteI 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.

As the software developer, you can resolve many of these issues. Streamline the process. Improve the GUI. Conduct usability studies. Watch brand new end users operate the software without prompting.

I suspect (but by no means know) that you are volunteering your time to maintain this software and you should receive thanks for doing so. At the same time, you've accepted the awesome responsibility of answering to the people throughout the country who are enormously dependent upon the software working correctly during mission critical situations. So when your users share their experiences with your software, you may want to believe them.

QuoteThis 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.

Sounds like who ever originally started this project chose the wrong development tools or platform. Failures should never be accepted as a cost of doing business.

Quote from: Short Field on July 23, 2009, 06:42:22 PM
Recommended Change:  Shorten the automatic verbage on the comm log.  I.E.  instead of automatically inserting "Operations Normal at 10:35" into the remarks section, use "Ops Nrml: 10:35".   Same for the other automatic insertions.  That would at least show some of the additional remarks that may be added on a mission.  This might not be an issue if the comm log screen is adjustable.

Making resize work for everything is on the list.  If you change the message type to normal it does not insert the ops normal text, only the remarks.  I will also play around with putting the remarks in front of the inserted part.  Its a good suggestion.

Quote from: Short Field on July 23, 2009, 04:06:32 AM
They are talking about getting a customer request for something like photos of 50 key sites.  They want each of the 50 sites to be identified as a task and then the PSC would group the tasks together into something they can fly - resulting in something like 3 or 4 sorties.  Currently that would be 3 or 4  CAPF 104s with matching tasks.   They want this so that if sortie 2 only photographed 8 of the 12 sites they were suppose to phtograph, then 8 mini-tasks would be closed and the 4 mini-tasks not photographed would remain active and could be reassigned to another sortie.

This is a complicated subject and I have read everyones comments.  I will reply to this one and say that it would be nice to have a seperate target tracking module that would manage the targets like the tasks.  I think this might be one area that data input time would kill us.  It takes a long time to enter 50 sets of coordinates and descriptions for targets.  Also selecting them and adding them to the tasking would be non-trivial. 

I have had the 50 target photo sortie and it is a pain to manage.  I usually use google earth to plot the targets and generate a list using gpsbabel from the kml file.  (www.gpsbabel.org)  I use the text target and I can specify the format of the coordinates to match whatever the air or ground crew needs for their GPS. 

I put the targets in the tasking in lists like: 1-5, 10, 11 and attach the printout of all plotted targets.  That way if we ned to retask them in the air they have the whole sheet.  In the debrief we cover the targests that were imaged and the ones that were not due to wx or whatever.

If I can work out a quick way to enter the targets it might be possible.  I am already looking at creating a coordinate entry parser that would make coordinate entry in different formats and even vor/radial format possible.

Its a good feature and it is being thought about if not yet actually on the list.

A trick I use on large and/or complicated missions is to build the task in a word processor (MS Word) and then paste them into the Tasks on the IMU.  It makes it a lot quicker when building a lot of similar but different tasks.   This worked really well for me when we did a DR that had a lot of photo checks of various radio towers, bridges, and dams.  I could build a new tasking fairly fast by cut and pasting in the word processor to create the task then copying it to the IMU.

Quote from: Robborsari on July 29, 2009, 06:10:13 AM
I don't want to argue this with you but I want to point out that this item was in response to the complaint that it causes more work, not that it takes longer.  By that I mean requires you to do more than the manual process.  It does not cause more work, it requires you to do everything that you are required to do anyway.  I agree that it will take longer to use a program you are not familiar with than a paper form you are not familiar with.  Training and practice will resolve that issue.  It is not a question of truthfulness.

I stand corrected, thank you for your reply. I apologize for the confusion on my part.

Looks like this has tapered off.  Thanks to everyone for the suggestions.  Feel free to PM me if you have any more suggestions or problems.

Quote from: swamprat86 on June 19, 2009, 02:32:00 PM
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.

So any updated on your project?

Quote from: Eclipse on June 18, 2009, 04:09:33 PM

In a few hours last month, during a practice mission, myself and few other staffers through together a PC-based status board system that is light-years easier to use and more effective than the IMU - its based on Excel and Powerpoint, with all low-grade, easy tech.  We've already been told that anyone with a little VB experience could automate it better in a few hours and the whole thing would live on a
chip, completely portable.

I've literally already tested it and it runs on my old (5 years) Windows Mobile phone.

Eclipse could you tell me more about the current state of the status board? I would love to see it...

Thanks

Quote from: Capt Rivera on July 18, 2010, 07:57:09 PM

Quote from: Eclipse on June 18, 2009, 04:09:33 PM

In a few hours last month, during a practice mission, myself and few other staffers through together a PC-based status board system that is light-years easier to use and more effective than the IMU - its based on Excel and Powerpoint, with all low-grade, easy tech.  We've already been told that anyone with a little VB experience could automate it better in a few hours and the whole thing would live on a
chip, completely portable.

I've literally already tested it and it runs on my old (5 years) Windows Mobile phone.

Eclipse could you tell me more about the current state of the status board? I would love to see it...

Thanks

Its pretty much at a usable state but I haven't looked at it for a while.

The Powerpoint is a linked spreadsheet, the spreadsheet is the data - change something and it is reflected on the next refresh of the slide.  Using PPT makes it easy to add other info like weather slides, GPS tracks with hits and locations, etc.  Hourly "snapshots" are accomplished by printing the slides, .pdfs', etc.

Mentally my next update is to move it to Google Docs and so it could be updated by multiple people and viewed remotely.  Just haven't gotten around to it.

I used it to convert my white-board GBD status boards to electronic format, but there's no reason it could not be replicated to air and base ops, planning, etc.

Keeping it in Excel and PPT means it will always work locally, moving it to Google Docs means it will work globally.  Options, options.

Quote
Keeping it in Excel and PPT means it will always work locally, moving it to Google Docs means it will work globally.  Options, options.

If we're serious about any kind of security compliance then Google Docs is NOT an option.  It is not HIPAA, SOX, GLB, or any kind of real low level business security compliant.   If you read their terms of use you will also not that they keep backups of the data "into perpetuity" and make no assurances of it's use.

Does it take care of the WIMRS flight releases and mission recording requirements or do you have to do that in addition to keeping up the spreadsheets?

Quote from: KyCAP on July 19, 2010, 03:25:23 AM

Quote
Keeping it in Excel and PPT means it will always work locally, moving it to Google Docs means it will work globally.  Options, options.

It is not HIPAA, SOX, GLB, or any kind of real low level business security compliant.   

We're not subject to those laws.

Quote from: davidsinn on July 19, 2010, 10:25:02 AM

Quote from: KyCAP on July 19, 2010, 03:25:23 AM

Quote
Keeping it in Excel and PPT means it will always work locally, moving it to Google Docs means it will work globally.  Options, options.

It is not HIPAA, SOX, GLB, or any kind of real low level business security compliant.   

We're not subject to those laws.

We're subject to HIPPA if we have any information that could be remotely tied to someone's healthcare (as it was explained to me by a trusted friend). As for the rest, since OPSEC and by extension INFOSEC is such a hot button issue it stands to reason that compliance with security laws and guidelines should be important.

Quote from: Spaceman3750 on July 19, 2010, 10:44:53 AM

Quote from: davidsinn on July 19, 2010, 10:25:02 AM

Quote from: KyCAP on July 19, 2010, 03:25:23 AM

Quote
Keeping it in Excel and PPT means it will always work locally, moving it to Google Docs means it will work globally.  Options, options.

It is not HIPAA, SOX, GLB, or any kind of real low level business security compliant.   

We're not subject to those laws.

We're subject to HIPPA if we have any information that could be remotely tied to someone's healthcare (as it was explained to me by a trusted friend). As for the rest, since OPSEC and by extension INFOSEC is such a hot button issue it stands to reason that compliance with security laws and guidelines should be important.

No, we are not subject to HIPAA (not HIPPA).  HIPAA covers the handling of certain information in the hands of certain regulated entities.  Examples include, but are not limited to, medical service providers (physicians, medical technicians, labs, etc) and health insurers.  CAP is simply not one of those entities.

Your health data is not protected in all cases.  For instance, I work for an insurance company that offers a variety of health insurance products, along with auto and fire coverage.  If we have certain protected information on a health claim for regulated policy types it is protected by law.  If we have the same information on an auto or fire claim it is NOT covered by HIPAA because those insurance products are not regulated by HIPAA.  In fact, that information isn't even protected if it is attached to certain policies offered by our health insurance division, because those policy types are not listed in the law. 

Further, there are a variety of ways for you to legally release your protected data to third parties who are under no requirement to keep it private (READ your contracts and applications for products that may review your health data!).  Our company chooses to treat such data very carefully, even when the law doesn't cover it, because that is in the best interest of our customers. 

Similarly, CAP should be cautious with confidential data entrusted to us, however we need not be caught in the same pant soiling terror as those responsible for protected health information.  So, use what works for you within constraints that DO apply to us.

Quote from: Eclipse on July 18, 2010, 11:34:45 PM
Its pretty much at a usable state but I haven't looked at it for a while.

The Powerpoint is a linked spreadsheet, the spreadsheet is the data - change something and it is reflected on the next refresh of the slide.  Using PPT makes it easy to add other info like weather slides, GPS tracks with hits and locations, etc.  Hourly "snapshots" are accomplished by printing the slides, .pdfs', etc.

Mentally my next update is to move it to Google Docs and so it could be updated by multiple people and viewed remotely.  Just haven't gotten around to it.

I used it to convert my white-board GBD status boards to electronic format, but there's no reason it could not be replicated to air and base ops, planning, etc.

Keeping it in Excel and PPT means it will always work locally, moving it to Google Docs means it will work globally.  Options, options.

Sounds useful and your thoughts for future versions also sound good to me. Some people fear to use Google Docs/Apps/Email, and then often they have a Yahoo/MSN/AOL e-mail address they are using for CAP communications.... (the word often does not imply every person does... lets debate Google products in another thread.)

Eclipse, mind sharing your current version? E-mail or in the thread is fine with me if your willing, you know the address.)

To not sidetrack this old thread further... I have not used any version of IMU... but will be looking at it soon. With that said...

- Any useful/helpful reviews of IMU3 from people actually using it?
- Any guides / training slides/PDFs/etc?
- Any info on the next IMU update? (Changes, new features, when will it come, BETA testing, ETC?)
- Suggestions for that next or future update past current state IMU3?
* And please keep the "get rid of it stuff away"... its not useful what so ever... Until NHQ presents us with something... we should appreciate what we have and help make it better. The better IMU is, the better product NHQ will have to create to compete with it.

Quote from: Spaceman3750 on July 19, 2010, 10:44:53 AM
We're subject to HIPPA if we have any information that could be remotely tied to someone's healthcare (as it was explained to me by a trusted friend).

HIPPA only applies to employers and healthcare providers (like Blue Cross).  It does not apply to us.

Quote from: KyCAP on July 19, 2010, 03:25:23 AM
If we're serious about any kind of security compliance then Google Docs is NOT an option.  It is not HIPAA, SOX, GLB, or any kind of real low level business security compliant. 

None of those apply to us, either, and it is as secure or moreso than anything else you will do on the web, including your company's email.
We're not talking about some random webpage, we're talking about documents secured with a password and only shared with people who need the information.

We're also not necessarily talking about the freeware version of Google services, these would be and are through the Apps for Education
services.

Somehow thousands of companies and schools, etc., are able to find a way to be legally compliant using Google, yet we can't use it for finding an ELT?

Quote from: Capt Rivera on July 19, 2010, 02:06:42 PM
Sounds useful and your thoughts for future versions also sound good to me. Some people fear to use Google Docs/Apps/Email, and then often they have a Yahoo/MSN/AOL e-mail address they are using for CAP communications.... (the word often does not imply every person does... lets debate Google products in another thread.)

Isn't that hilarious?

Quote from: Capt Rivera on July 19, 2010, 02:06:42 PM
Eclipse, mind sharing your current version? E-mail or in the thread is fine with me if your willing, you know the address.)

I don't mind, but I need to poke it with a stick a bit before posting it - not sure when I'll get to it.

Quote from: Eclipse on July 19, 2010, 02:29:28 PM

Quote from: Capt Rivera on July 19, 2010, 02:06:42 PM
Eclipse, mind sharing your current version? E-mail or in the thread is fine with me if your willing, you know the address.)

I don't mind, but I need to poke it with a stick a bit before posting it - not sure when I'll get to it.

Would you mind sending to me? I'm a good sitck poker - I've crashed my company's inventory management system four times now. The last time, it took IT two days to fix. >:D Fortunately, it was late on Fri when I worked my magic.

Quote from: davidsinn on July 19, 2010, 10:25:02 AMWe're not subject to those laws.

You all ran off in a different direction than the point that I was trying to make.  I was making the point that Google isn't compliant with the "least" stringent security policies and procedures that are WIDELY held out for information sharing.   

If CAP were deemed to be "subject" to any kind of guidance it would be FISMA which is defined by as series of regulations from the Feds, specifically the NIST 800 series and others as required.   I am CERTAIN that anything in the cloud would not be compliant for all of the ones that I used as generic examples PLUS anything in the NIST/FISMA guidance.

I am also guessing that NHQ and the IT staff probably are glad to be PCI compliant for the e-commerce business and have not considered GIAC audits, OWASP compliance or other "day to day" IT security best practices, but I could be wrong.

Quote from: Eclipse on July 19, 2010, 02:20:56 PMSomehow thousands of companies and schools, etc., are able to find a way to be legally compliant using Google, yet we can't use it for finding an ELT?

I have DOZENS of clients that are LEAVING Google for these very legal issues because they were not aware of the issues until their attorneys review the agreements.

I have DOZENS of school systems where the IT administrators are flipping out because the schools are using these "free" services as a cost cutting measure.   Content in the systems belong to the student but can be accessed from the schools computers.   The students have a "private" location not monitorable by the school system on school premises and the administrations are creating new policies and procedures to start to control this because the schools can't afford to replace their now aging storage systems and have "gotten it for free" from Google and Microsoft.  Kentucky is shutting down 800 Exchange servers and moving to Microsoft's EDU live platform for example.  But the verdict is out on whether the administrators and staff email will migrate for COMPLIANCE / legal issues that they are subject to.

Quote from: KyCAP on July 24, 2010, 01:22:23 AM

Quote from: davidsinn on July 19, 2010, 10:25:02 AMWe're not subject to those laws.

You all ran off in a different direction than the point that I was trying to make.  I was making the point that Google isn't compliant with the "least" stringent security policies and procedures that are WIDELY held out for information sharing.

You need to be specific about which services you are discussing - the apps cloud or Gmail.  I don't know or care about the security on a free Gmail account - you get what you pay for.  We are discussing the Apps Cloud and the services there, which carry very specific SLA's and QLA's, especially when you are paying for it. 

Quote from: KyCAP on July 24, 2010, 01:22:23 AM
If CAP were deemed to be "subject" to any kind of guidance it would be FISMA which is defined by as series of regulations from the Feds, specifically the NIST 800 series and others as required.   I am CERTAIN that anything in the cloud would not be compliant for all of the ones that I used as generic examples PLUS anything in the NIST/FISMA guidance.

OK, first, I'd have to see some specific point where you believe the Apps Cloud would be non-compliant, and second, why bother since we aren't subject to those rules.

Quote from: KyCAP on July 24, 2010, 01:22:23 AM
I am also guessing that NHQ and the IT staff probably are glad to be PCI compliant for the e-commerce business and have not considered GIAC audits, OWASP compliance or other "day to day" IT security best practices, but I could be wrong.

How is NHQ subject to PCI on anything but as a Level 4 User?  That's a self-assessment, period.  And even at the highest level, it would have nothing to do with this conversation, because the only place PCI touches email is "don't send credit card numbers in emails".  The only systems that would be in-scope for compliance would be the ones transiting or storing credit card data, which would have nothing to do with Apps.

CAP is not bound by HIPPA, Sarbanes Oxley, ISO, or any of a dozen other acronyms.

If you have an organization which is bound by compliance regulations, then you do your research in advance before you switch over, not after, and you don't blame the provide if their service doesn't match your needs.

With that said, Google has a suite of services for secure email, just like everybody else.

I will grant you that this is a complex discussion that can't be brought to a conclusion in a forum like this, but the average CAP unit/group/wing is much better off with a Google-hosted solution that it controls than a free email account at Hotmail or Juno.

Quote from: Eclipse on July 24, 2010, 01:52:24 AMOK, first, I'd have to see some specific point where you believe the Apps Cloud would be non-compliant,

OK - Start with Google itself in just a quick search.
http://groups.google.com/group/google-appengine/browse_thread/thread/aef13f580f46bd13

"App Engine is currently not HIPAA- nor SAS 70-compliant, so highly
sensitive data (HIPAA/PHI data, SSNs, CC numbers, etc.) should not be
stored on App Engine. it is not a good match for that type of data at
this point in time unless, as the previous poster pointed out, that
you've done some bulletproof encryption of that data. unfortunately, i
cannot currently comment on any timeline to get any sort of data
privacy certification.

If you have an organization which is bound by compliance regulations, then you do your research in advance before you switch over, not after, and you don't blame the provide if their service doesn't match your needs."

Here's an earlier review: http://it.toolbox.com/blogs/managing-infosec/google-apps-is-a-risk-management-decision-14666

Quote from: Eclipse on July 24, 2010, 01:52:24 AMand second, why bother since we aren't subject to those rules.

In order to know that we are NOT subject to FISMA there would have to be language in the contract between the US Air Force (AETC) that would EXCLUDE CAP, Inc from the flow down provisions that would govern any FISMA policies.  I haven't seen that doc, have you?

Quote from: Eclipse on July 24, 2010, 01:52:24 AM
How is NHQ subject to PCI on anything but as a Level 4 User?  That's a self-assessment, period.  And even at the highest level, it would have nothing to do with this conversation, because the only place PCI touches email is "don't send credit card numbers in emails".  The only systems that would be in-scope for compliance would be the ones transiting or storing credit card data, which would have nothing to do with Apps.

My anecdote was not to infer that an IMU like app would be subject to the scope of PCI compliance, but that NHQ probably is just swallowing PCI and probably hasn't given thought to other issues.  Nothing more.

Quote from: KyCAP on July 24, 2010, 03:22:29 AM
In order to know that we are NOT subject to FISMA there would have to be language in the contract between the US Air Force (AETC) that would EXCLUDE CAP, Inc from the flow down provisions that would govern any FISMA policies.  I haven't seen that doc, have you?

How do you figure that CAP needs to be excluded from Air Force regulations?  We aren't a part of the Air Force, and we're only bound by a handful of their AFI's.  This is likely one of those places not being part of the military helps.

Besides, for the most part FISMA only requires agencies and related organizations to "have a plan" - we don't have much of anything
that would fall into classified, and if we do, then those communications should be done with secure machines provided by the USAF with
CAC card login, etc.  Not likely for the notice you failed your ECI-13. So the "plan" isn't going to involve retna scans and real-time DNA testing to get your SPAM.

Google's POSTINI services are secure and encrypted (and yes not free), whether they will get a company to compliance depends on the company, the industry, which agency is asking the questions, and how the services are used.  There any number of banks and financial institutions using Apps right now.

I just spent about two years on a data security project around PCI for a major hospitality company - I'm not a CISSP by a long shot, but I have a pretty good handle on the compliance environment around HIPPA, SOX, and PCI.  The short answer is "it depends", and requires more reading than just the FAQ, but spreading FUD about Google and security isn't cricket.

Maybe this needs a new thread unless there is a suggestion for security in this.

http://googleenterprise.blogspot.com/2010/07/google-apps-for-government.html

http://googleenterprise.blogspot.com/2010/07/supporting-us-navys-humanitarian.html

Monday, July 26, 2010 at 11:35 AM
Last September, we announced our intent to create a Google Apps environment dedicated to our government customers, and to complete United States government security certification for Google Apps. Today, we're delivering on both.

Today, we're pleased to introduce a new edition of Google Apps designed specifically for the needs of U.S. government entities. It's called – appropriately enough – Google Apps for Government. This new edition is available now to federal, state and local governments in the United States.

Google Apps is also the first suite of cloud computing applications to receive Federal Information Security Management Act (FISMA) certification from the U.S. government. With this federal government certification of our security controls, government agencies can use our cloud services with confidence.

A wide range of U.S. government customers are already taking advantage of Google Apps, from the U.S. Department of Energy's Berkeley Lab to the U.S. Navy's InRelief program, to the City of Los Angeles, to smaller governments across the country like Panama City, Florida and the City of Wooster, Ohio.


I'll just be over here with my coffee...Sumatra this week!

Capt Borsari,

Can you give us updates related to the next release or BETA?

Quote from: Eclipse on July 26, 2010, 08:03:24 PM
I'll just be over here with my coffee...Sumatra this week!

1) You need to buy a lottery ticket that is like some of the best timing on the planet.
2) NHQ now just needs to increase the annual budget between $1 mill to $2.75 mill to cover all of the members an account each year



:)

I like Sumatra.

We don't need the Government-level accounts to get FISMA, as indicated by the article, Apps as a whole is FISMA, but the Government systems add additional levels of encryption, security, and commitments for CONUS-based systems only.

Apps for education would be plenty, and that is free, however providing every member with a secure government-level CAP email address and access to a collaborative environment would be the best money CAP has spent in a decade.  Google Apps, of course, does not equal GMail.

I agree on the timing, however their work towards this compliance has been on their todo list since last Fall.

Quote from: Eclipse on July 27, 2010, 02:31:26 AM
Apps as a whole is FISMA

That is not correct as I have read through this.  For FISMA compliance it appears they have had to retain the data in US data centers.  Other APP service levels do not do that.

It's re-interated in the other reviews of the application that other APP service products are not FISMA compliant.
Like here: http://digitaldaily.allthingsd.com/20100726/certification-came-quickly-after-one-click-access-to-wikileaks-was-removed/

I am reviewing this for the security audits that we are performing now.

That's not how I read the initial press release, but you may be right - it makes sense based on the additional cost.

I may switch-over just "because" if individual users can change their Premium account.