Everyone,
I know there are people out here who can do this!
Me, I'm an IT Project Manager, so I think in terms of requirements and resources...and I'd like to kick off a volunteer effort to make this happen. I need some help with the coding however!
So...I'd like to gather our code-minded members, along with our operators to build this...I need the coders to make this a reality, and the operators to tell us what they need.
Come to: http://groups.google.com/group/mobile-wmirs and sign up to the discussion!
To be clear, I'm not looking to redevelop WMIRS, only create a full-featured mobile-friendly front-end. I know we'll need some assistance from NHQ with the interfacing with WMIRS, but we need to determine what we need before we can ask!
I'd like to see a full-featured, rich interface, application that would let us do all the WMIRS stuff on a mobile platform...here's my list:
-Be able to Add, Edit and Close sorties (both ground and air)
-Be able to perform Flight Release (eFlightRelease)
-Be able to use the camera and directly upload receipts to sorties
-Be able to tap a button in the plane to record (and transfer to
WMIRS) actual time of departure
-Be able to view release status of a sortie (so I can confirm if my
flight is released)
-Search
-Find all sorties on a mission
-Find all sorties for a CAPID (so find all "my" sorties)
-Find all "open" sorties (with the by CAPID) for a mission
And of course:
-A hidden screen where you get to fling birds at Triangle Thingies >:D
Doesn't it work on the browser already?
A rather crippled version.
I'm talking about a native application taking advantage of what the phones can do.
Well, wouldn't WMIRS need to have a public API then?
My impression is that WMIRS is some cobbled-together home-grown system by a private developer.
That's something that I would expect to flesh out during the requirements definition phase of the project.
Quote from: Eclipse on June 07, 2011, 06:26:51 PM
Well, wouldn't WMIRS need to have a public API then?
It would and it does not.
I recently leaned that IMU communicates with WMIRS by getting the same HTML response your browser does and extracting the data. (aka screen scraping) Anything sent to WMIRS is by HTML form.
For the non-programmers out there, that means simple style / naming changes to WMIRS can break IMU. Or any effort described in the OP
If an API is a requirement, then we ask for one, and provide whatever assistance we can with developing it.
We don't know it's impossible if we don't ask...but my way of thinking is that you need to fully develop the question before asking...so for an API, I'd want to scope out what services I required the API to provide and be able to work intelligently with the developers of WMIRS to develop an appropriate API for our purposes.
One thing that would be helpful would be the ability to scan someone's membership ID and have their ES and emergency contact info come up. I know IMU does this, but a small web based client would be very useful for spot checks.
FYI, WIMRS was created using Cold Fusion, and I believe version 8.x is the version they are currently using.
Quote from: Tubacap on June 15, 2011, 04:49:13 PM
One thing that would be helpful would be the ability to scan someone's membership ID and have their ES and emergency contact info come up. I know IMU does this, but a small web based client would be very useful for spot checks.
Great idea!
You know what would be really great...punch in or scan in a CAPID and get their 101 card, both sides, from the current data in eServices, including picture...especially if we could use that as an alternative to a paper 101!
That would be a fantastic use for those two dimensional bar codes that are popping up everywhere these days.
Quote from: SarDragon on June 15, 2011, 09:27:09 PM
That would be a fantastic use for those two dimensional bar codes that are popping up everywhere these days.
But which one would we use and what color would it be printed in!
(http://i146.photobucket.com/albums/r259/fidolatry/barcodes.png)
The top left QR code seems to be the most popular.
Quote from: USAFaux2004 on June 15, 2011, 10:29:40 PM
The top left QR code seems to be the most popular.
Yup. And color doesn't seem to make as much difference as contrast. B/W is obviously the easiest, though.
Free app on my Droid read the top 2.
Quote from: jimmydeanno on June 15, 2011, 10:00:24 PM
Quote from: SarDragon on June 15, 2011, 09:27:09 PM
That would be a fantastic use for those two dimensional bar codes that are popping up everywhere these days.
But which one would we use and what color would it be printed in!
There are many 1D barcode standards - at some point they worked it out because we don't have those issues anymore.
Quote from: jimmydeanno on June 15, 2011, 10:00:24 PM
Quote from: SarDragon on June 15, 2011, 09:27:09 PM
That would be a fantastic use for those two dimensional bar codes that are popping up everywhere these days.
But which one would we use and what color would it be printed in!
(http://i146.photobucket.com/albums/r259/fidolatry/barcodes.png)
Here are my current quals:
(http://chart.apis.google.com/chart?cht=qr&chs=350x350&chl=ACUT%2CAOBD%2CFASC%2CGES%2CICS300%2CICS400%2CIS100%2CIS200%2CIS700%2CIS800%2CMO%2CMRO%2CMS%2CMSA%2CSET%2CUDF)
JeffDG's QualsQuoteACUT,AOBD,FASC,GES,ICS300,ICS400,IS100,IS200,IS700,IS800,MO,MRO,MS,MSA,SET,UDF
Droid Does. Except when you install 2.3.3 and it keeps removing Pandora, Titanium update, and the QR reader from being visible. <_<
Quote from: USAFaux2004 on June 16, 2011, 12:33:25 PM
JeffDG's QualsQuoteACUT,AOBD,FASC,GES,ICS300,ICS400,IS100,IS200,IS700,IS800,MO,MRO,MS,MSA,SET,UDF
Droid Does. Except when you install 2.3.3 and it keeps removing Pandora, Titanium update, and the QR reader from being visible. <_<
Readback is correct.
I just use the normal barcode scanner app for myself.
To generate I use: http://zxing.appspot.com/generator/