Last evening and again this morning, I attempted to pull up the restricted "members reports" on eServices. I have the permissions to do so, but every time i select the "duty assignment" report, it pulls up the main report page inside the same page on the internet browser. I have tried on two different web browsers and the same thing occurs.
Anyone else having an issue?
Yes, same behavior, has been there now for near a week, meant to post something.
Duty assignments, selected a unit and then specified all duties.
It comes up for me.
I get the "save, open, cancel" options in IE as always.
The PDF looks normal.
What browser are you using?
Have you tried compatability mode?
Turn off popup blocker or other filters?
EDIT:
Seems to work for me in Chrome as well.
Chrome and IE for me, same behavior on both.
Interesting.
I cant seem to duplicate the error.... unless there is a step I'm missing or my permissions are different.
I'm still on IE 9, have popup blocker and smartscreen filter turned OFF as well as the ActiveX filter.
This is what mine looks like when I try on Safari, Firefox and Chrome.
Yep - that's what mine looks like.
Yup! That's what it does every time...
Soooo frustrating, as today is my only day to get cap work done...oh well...game of thrones it is!
I can confirm precisely the same behaviour...
I guess I've been spoiled in that I have good CAPWATCH database and my own reports that I never go in there!
Is this the same thing?
Quote from: a2capt on July 01, 2013, 06:26:31 PM
Is this the same thing?
Looks like yours is working correctly.
Quote from: a2capt on July 01, 2013, 06:26:31 PM
Is this the same thing?
Cool. it works fine for someone else.
With all these errors and mine working fine I was starting to worry someone was going to call me out on it! :)
I do have wing level permissions but I suspect several of you seeing the 'error' do too.
As do I have Wing level permissions, and it is working. Still, even.
It's fixed for me!
Works fine for me in Firefox. I have squadron level privileges.
It is now fixed for me as well.
Ditto, and the actual behavior of the module seems different (the darkened screen while processing).
Big brother must be watching! Cool by me.
Quote from: Eclipse on July 01, 2013, 10:06:06 PM
Ditto, and the actual behavior of the module seems different (the darkened screen while processing).
Big brother must be watching! Cool by me.
The folks at National have been known to "monitor" this board...
If CAP pilots flew like National writes software, the fleet would be elminated in a week. eServices is to software what spam is to fine dining.
You should forward your improved program to National so we can use IT instead of Eservices... ::)
Uhhh...not too many IT professionals would build a custom system on spec, then offer it up, unsolicited, for free. Tough to ambush a customer that way - most of them would like to actually be involved in the process.
My criticism is for eservices, which has definitley improved some in the last few years. But it remains a clumsy, obscure, disjointed, and buggy application. Doesn't mean the IT folks at National aren't good professionals. More likely they don't have the staff and/or money to do more than limited scope, incremental enhancements and bug patching. It's a bad system. Really. Bad. Surprisingly so, for a paid membership organization of this size. The system navigation is an excellent "how not to" example. I spent an hour with it today, entering some Ops Quals, which likely should have taken 10 minutes. Not good to annoy your user base, waste limited volunteer time, or to be surprised if they start hurrying through tasks (or putting them off ).
Someone is going to comment that "it's not so bad once you learn it". That translates into "I spent long, frustrating hours struggling with this pig, but now I know the work-arounds. Until I need to use it for a new task".
Quote from: SunDog on July 03, 2013, 05:51:02 AM
Uhhh...not too many IT professionals would build a custom system on spec, then offer it up, unsolicited, for free. Tough to ambush a customer that way - most of them would like to actually be involved in the process.
My criticism is for eservices, which has definitley improved some in the last few years. But it remains a clumsy, obscure, disjointed, and buggy application. Doesn't mean the IT folks at National aren't good professionals. More likely they don't have the staff and/or money to do more than limited scope, incremental enhancements and bug patching. It's a bad system. Really. Bad. Surprisingly so, for a paid membership organization of this size. The system navigation is an excellent "how not to" example. I spent an hour with it today, entering some Ops Quals, which likely should have taken 10 minutes. Not good to annoy your user base, waste limited volunteer time, or to be surprised if they start hurrying through tasks (or putting them off ).
Someone is going to comment that "it's not so bad once you learn it". That translates into "I spent long, frustrating hours struggling with this pig, but now I know the work-arounds. Until I need to use it for a new task".
I had the opportunity to see e-services mapped out in a wire diagram. It was on the wall of the IT guys' office. Oy vey, is all I could say. But, there are few of them and they get tasked with a bunch of stuff. There is only so much they can do.
One >major< issue right now is that Ops Quals function does not match the regulations, which means that
even when you power through the poor UI and other technical issues, things still don't act the way they are supposed to,
which cause further confusion.
I kinda figured the resources were limited for IT at CAP. A system like eServices gets very "brittle" with age; constant patching, kludges, "good enough" work arounds, and after a few years you get a nightmare of convoluted code, with forgotten or hidden dependencies, that is very tough to enhance, or even maintain very well. Like an old pair of jeans with more patches than denim.
Gotta be tough for them to even test properly. Hence the mess with the SETS roll-out, and the gacked error messages that say one thing, but are caused by another. One of our guys went round and round, trying to figure out why the system was telling him he wasn't SETS qualified to update a qual for a trainee. Only the real issue was his safety currency had lapsed the day before. Not what the message said, of course, and the date of the qual was before his currency lapsed. Just not a good implementation of new business rules. But, again, tough to do on a system in such rough shape.
Makes it hard on the membership, and turns off new folks, big time. Hard to fathom why it doesn't get more attention and resources, since it's probably the only contact most members have with National - it is the mission critical, enterprise system for the organization. I have seen worse, but not often, not for a customer-facing system.
Quote from: SunDog on July 06, 2013, 06:36:29 AM
I kinda figured the resources were limited for IT at CAP. A system like eServices gets very "brittle" with age; constant patching, kludges, "good enough" work arounds, and after a few years you get a nightmare of convoluted code, with forgotten or hidden dependencies, that is very tough to enhance, or even maintain very well. Like an old pair of jeans with more patches than denim.
<snip>
Makes it hard on the membership, and turns off new folks, big time. Hard to fathom why it doesn't get more attention and resources, since it's probably the only contact most members have with National - it is the mission critical, enterprise system for the organization. I have seen worse, but not often, not for a customer-facing system.
You pretty much nailed it.
15+ years ago, NHQ was looking for a junior programmer. Coincidentally, I was a pretty junior programmer. Unfortunately, the salary was laughable
(I was, at the time, making about $35,000 a year in Detroit. Even accounting for cost of living adjustments between Detroit and Montgomery, it was probably a 30% pay cut). This was at the very beginning of eServices, too.
Over the years, there has been a pretty serious brain drain as people are hired, work on a system, gain experience and then go someplace else that will actually pay them for their skills. This leads to a lot of that patchworking. That led to my joke about "Alabama .NET programmers." (Helps if you say it with a Jeff Foxworthy voice)
I once worked on a system that managed about $20M in annual revenue for a software company. It had started out as a home-grown system, never intended to be used by people outside of the sales & marketing teams of a fairly small outfit. Web-based, MS SQL server back end, etc. That company got acquired by a much larger software company (the one I worked for). The system had grown, had functionality added to it and morphed into a multi-use system (sales, sales operations, marketing, license administration) that was also touched by 2-3 other systems or departments (tech support, for example), and then had to interface with the software ordering system (Oracle) at the Mothership in Detroit.
The system had been worked on (before me) by 4 different IT managers, it had been built using 5 different coding styles and a multitude of dependencies
(the user provisioning, for example, was tied to an object-based Sales CRM the company had. I can't even remember the name of it. But setting someone up for an ID required major hoop-jumping), and eventually it was being used by sales people in other offices around the world via the WAN. You know something is amiss when you're getting a phone call at home at midnight from a guy at the sales office in Sidney, Australia apologizing for bothering you...
My programming partner and I had made the case for re-writing the system from the ground up using .NET, eliminating a lot of the goofball dependencies, building a legitimate connector to Oracle , hosting the system in a more centralized location so the field offices could get to it, etc. All of that was shot down due to "resources," so we spent the next 12-18 months continuing to patch kludgy code before I finally left the company and the rest of my group got laid off. My old boss called me about 4 weeks after I'd left asking if I could shed any light on the system, as they were moving the whole thing to Detroit and had no idea why it wouldn't work.... LOL!
So eServices has behind it a 15+ year legacy of old code, an originally very dodgy data model, not well-understood and ever-changing business rules (that often don't make a lot of sense when compared to one another), and only probably the barest of institutional memory as to "why things were done the way they were in the code." That the folks at NHQ can keep eServices running at all amazes me sometimes, and my hat is certainly off to them, because I know what it is like to have to inherit someone else's system and maintain, extend and improve it.
The Air Cadets Organisation in the UK many years ago implemented a nationwide system called "Project Bader". https://news.bader.mod.uk/default.aspx
It is now substantially based on Sharepoint (shudder!), but the idea was that it would be a hierarchical document management system for paperwork and communications. So when Cadet Blaggs needs his glider wings, Pilot Officer Smythe initiates a form (electronically) and it goes to Wing Commander Butler for (electronic) signature. And Plt Ofcr Smythe gets an email or other electronic notification that Butler has received it. And Wing Cdr Butler gets an email saying he's got something for approval in his in-box. And they get tickled when it *doesn't* get acted on. And I'm betting that Wing Cdr Butler's boss somehow finds out when Butler is living up to his nickname "Bottomless Briefcase Butler" and has 50 items more than a month old still waiting approval..
There was more to Project Bader than that, but at the time it was described to me (2002? 2003?) it made e-Services look like AOL.
It is a toss up as to what is more appropriate and effective: a commercially-based system like Sharepoint that can be modifed and extended with APIs and such to mostly meet the needs, or a custom-developed system. The problem with custom developing a system is that you need more people (programmers, business analysts, report developers, interface designers, documentation & training specialists, infrastructure management people, etc), whereas with an off-the-shelf setup you can (maybe) more easily find developers, the interface is more homogenized, reporting is standardized, interfaces between systems are based on very well developed APIs, etc.
+1 to NIN. Lots of people like to beat up on the IT/programming people because it's easy, with no real idea of the man hours, costs, and 100 other issues associated with the system.
While the current state of eServices can be frustrating, keep in mind that there are way worse methods of doing things. One of my clients has an off-shore development company that has been deploying changes directly into production for months.
Hope I didn't insult the IT folks, not my intent. . .I think the failing is in management, of course. sServices is the brand, the storefront, the place members interact with National, and locally, for almost everything. I wonder how long National would tolerate a broken front window at HQ, or a backed up toilet, or a long term power outage? Or a receptionist that was rude to visitors.
For sure, they could "work around" all those things. But they wouldn't, not for long. They'd get 'em fixed, and rightly so. The "as is" with eServices shows a disturbing lack of vision, and consideration for members. I appreciate the example (shoving changes straight into prod), but, respectfully, it's like telling me having the flu ain't so bad, because someone else has pneumonia.
Rant complete. And pointless, like as not.
Quote from: SunDog on July 08, 2013, 03:52:03 AM
Hope I didn't insult the IT folks, not my intent. . .
I'm sure they took the "spam" comment as a compliment. ;)
QuoteI think the failing is in management, of course. sServices is the brand, the storefront, the place members interact with National, and locally, for almost everything. I wonder how long National would tolerate a broken front window at HQ, or a backed up toilet, or a long term power outage? Or a receptionist that was rude to visitors.
If eServices could be improved with the effort it takes to unclog a toilet or retrain a receptionist in customer care procedures, I am confident that it would have happened long ago.
As you pointed out earlier, eServices has greatly improved over the years, but as Nin so graphically described, the current system is a legacy system with issues.
And NHQ is severly resource-constrained. There have been multiple rounds of staff reductions in recent years. Mr. Rowland and his team have done terrific work trying to balance the missions and needs of the HQ. I don't envy the resource allocation choices he has had to make.
But the bottom line is that to achieve the kind of modern eServices that you and other members would like will almost certainly take hundreds of thousands of dollars to develop and code a new system. (Even in Sharepoint.)
Which obviously we don't have. It would take a substantial dues increase to raise that kind of funds, which I suspect the membership would find unappealing. Alternatively, perhaps you can identify which major programs should be eliminated to provide additional support to IT.
(It probably goes without saying that the Appropriations Fairy is very unlikely to contribute any money for IT upgrades.)
Before saying management has "failed," perhaps we should carefully consider the constraints under which they are operating.
QuoteThe "as is" with eServices shows a disturbing lack of vision, and consideration for members. I appreciate the example (shoving changes straight into prod), but, respectfully, it's like telling me having the flu ain't so bad, because someone else has pneumonia.
Rant complete. And pointless, like as not.
How strange. Anonymous ranting on the internet is usually so productive. Maybe you're not doing it right.
The problem is that NHQ isn't using the most abundant resource they have access to: Volunteers.
I would venture to say that there are thousands of highly-skilled IT personnel in CAP, a large number of whom would be quite willing and able to contribute to a project to fix things, all without appropriations.
Yet, we have folks at NHQ who insist on spending time to not facilitate, but to actively discourage, member developed systems that could be of huge benefit to CAP, then plead poverty of resources when asked to provide that functionality themselves.
NHQ could produce a lot more results if they focused on building secure interfaces to the data, defining standards, and coordinating member-developed projects, rather than fighting them.
Quote from: JeffDG on July 08, 2013, 05:53:42 PM
The problem is that NHQ isn't using the most abundant resource they have access to: Volunteers.
I can't really disagree with that. The question then becomes "why?"
Indeed, as a long-time CP guy I always wondered why NHQ didn't make more use of volunteers in their shop at NHQ. (Like IT, CP is severely understaffed and under resourced to accomplish what the membership expects.)
So, what sort of issues might it present to have volunteers working on IT issues?
Are there examples of other organizations that used volunteers to code some sort of "eServices - equivalent" product to serve over 60,000 members, a couple hundred employees, and track and maintain the qualifications for the folks who operate a couple of hundred million dollars worth of Federally-provided assets?
For example, does the Red Cross or the Air Force Association use some of their many volunteers / members in their IT functions at the national level?
How about the BSA?
NASA is certainly budget-constrained lately and has had some severe IT blunders that resulted in a satellite or two being lost. Do they use volunteers for any of their coding?
Does the Wikipedia organization have any lessons for us here?
Do you really think that the IT folks at NHQ are biting the helping hands being offered them out of spite or closed-mindedness? What reason could they have for doing that?
So let's talk about how to constructively engage volunteers in a cost-effective manner. But let's start with some historical examples where it has been successful in a comparable project.
The technology is certainly available to allow for volunteers to work remotely and in collaboration with others across the country. The open source community is proof that this is feasible. As a software test engineer, I wouldn't mind helping out. I'm sure there are many more software professionals that would jump at the opportunity to help improve eServices.
Quote from: Ned on July 08, 2013, 06:40:19 PM
But let's start with some historical examples where it has been successful in a comparable project.
If everyone waited for someone else to succeed, nothing would ever get done. I understand your desire for empirical evidence to show that this won't be a massive waste of time and resources, eventually creating a bigger mess. But I would point to the relative success of several member generated projects. Granted, WMU was very annoying at times, but when it came out it did what eServices, or MIMS at that time, couldn't. Given a reasonable amount of time and coordination, I believe that some of our own members could build a better eServices.
Quote from: Storm Chaser on July 08, 2013, 06:56:54 PM
The technology is certainly available to allow for volunteers to work remotely and in collaboration with others across the country. The open source community is proof that this is feasible. As a software test engineer, I wouldn't mind helping out. I'm sure there are many more software professionals that would jump at the opportunity to help improve eServices.
Yep...Linux was my first thought when asked for an example, far, far more complex than eServices, and collaboratively built by a combination of professional, amateur and volunteer developers.
There needs to be a paridigm shift. We don't necessarily need "eServices 2.0". What is more needed is documentation of what information is available, what information is needed, and standards of how to access and modify that data securely.
This stuff doesn't necessarily need to be one big application, but rather a series of modules that accomplish different parts of the process.
Then you get into niche situations. You have someone, now that he has a defined process for it, developing an app for NESA to record SQTR task completion, and builds it on the iPad. So the instructor/evaluator has the task guide, SQTR, and student list on one screen, along with the evaluation criteria, and as the criteria are met for each student, he puts a check next to it, and it automatically uploads completion into OpsQuals. We will never have sufficient staff at NHQ to do something like that, and the staff we have will spend more time trying to figure out what's needed than actually developing it. An instructor who is an iOS developer in the real world however can build something that makes his job immeasurably easier, gives NHQ more up-to-date, more accurate, and just plain better, information, all for near zero cost to CAP.
Hell, look at the capability of something like IMU. It's been developed by members. NHQ personnel have actively sought to shut it down through various methods. Yet, members have managed to keep it working and improving. Take the time spent trying to block the thing, and instead build a secure API for it, and suddenly you have a tool that can be used across the organization.
Quote from: JeffDG on July 08, 2013, 05:53:42 PM
The problem is that NHQ isn't using the most abundant resource they have access to: Volunteers.
I would venture to say that there are thousands of highly-skilled IT personnel in CAP, a large number of whom would be quite willing and able to contribute to a project to fix things, all without appropriations.
Yet, we have folks at NHQ who insist on spending time to not facilitate, but to actively discourage, member developed systems that could be of huge benefit to CAP, then plead poverty of resources when asked to provide that functionality themselves.
NHQ could produce a lot more results if they focused on building secure interfaces to the data, defining standards, and coordinating member-developed projects, rather than fighting them.
Truly, there is (well, _was_) a fair amount of "not invented here" at NHQ for a lot of stuff that prevents them from letting the "volunteers" behind the magic curtain..
I had discussed with them many years ago the possibility of establishing some some directory services for remote authentication. (plus, as part of that, I had the idea, if you search for it on here, of a HQ-based hierarchical CMS & email system for unit pages/domain names/domain administration/email administration that was substantially database back-end/directory authentication based) Since the idea didn't originate from HQ, it was immediately shot down and pish-toshed. I said "OK, cool, whatever.." and went back to doing things the brute force way. :)
Part of the issue is that we need to understand (very clearly) what the "business needs" are that we're satisfying/solving with our IT systems. Those needs are certainly substantially NHQ's needs (first), but need to trickle down to the subordinate HQ's needs as well. But if you think about it, much of the field's "business needs" are different from the HQ's needs, so how well does HQ understand how things get used in the field? (to be fair, probably they probably have a much, much better understanding in the last few years than it was, say, 10 years ago)
Another thing is the highly customized nature of eServices makes "external help" very difficult. You can employ volunteer subject-matter-experts to help you understand your use cases, business rules, etc, but how many *more* .NET wonks do you want putting their butterfingers in your already fairly fragile custom codebase? (hint: you don't want me doing it. eServices would order you a pizza every time you went to print a 101 card...)
So if you want to rely on your volunteer base of expertise, then you should probably wind up on a highly standardized and well known/documented platform/framework instead of a heavily customized system.
But getting off the heavily customized system and onto a standards-based, well-known system is going to be a hell of an undertaking, too. (and just about the time you do, the vendor decides to drop all support for that product and go in another direction!)
The answers are not easy nor are they very good.
I'd like to know who reviews the "business rules" before they are implemented, and who knows those rules better? A contractor or an experienced member.
If you need to hire coders to maintain things, fine, but volunteer staff and commanders should be at the head of all committees and teams.
The number things that I routinely dig out that "no one ever thought of" are, quite frankly, both amazing and disappointing on so many levels,
especially glaring conflicts between regulations and the way systems function as is currently the case with OPS Quals.
I am, and never was, a fan of the WMU, but certainly it was demonstrated that one, or a small group of people can create a system
that would serve our needs.
60,000 records? That's one spreadsheet.
Most of what eServices needs are a bunch of "if this then that" type checks.
Somewhere between that spreadsheet and eServices is where we should actually be, and in this day and age, if
we're paying much, if anything, for the software we're using, someone isn't paying attention.
Quote from: NIN on July 08, 2013, 07:28:41 PM
But getting off the heavily customized system and onto a standards-based, well-known system is going to be a hell of an undertaking, too. (and just about the time you do, the vendor decides to drop all support for that product and go in another direction!)
The answers are not easy nor are they very good.
You don't need to discard the whole customized system.
a) You don't want outsiders mucking about in the internals of the system. Period, full stop.
b) You define interfaces to the system to perform functions that outsiders need
So, take IMU as an example. One thing it needs to do is create Air/Ground Sorties in WMIRS. OK, so you create an authenticated API that permits the user to do a "CreateSortie(<MissionNumber>,<Type>,<sortieSettingsXML>,<authToken>)" and define all of your fields in the XML spec. So, now, if an external app needs to create a sortie, they can do so via that method. How WMIRS stores that data is of no consequence to the person creating the sortie, nor is how to pull reports. You don't need to rebuild WMIRS, just add an API front-end thereto.
Now, once that's built, someone else comes along and decides to do an Android app that lets the director of an ORide day create sorties for the day on the fly from his Galaxy Tab. No work needs to be done by NHQ at all now, as the interface already exists and can be used for an additional purpose.
NHQ is also now free to modify the look-and-feel of WMIRS as necessary to take care of the "manual entry" folks, without breaking apps that have had to build elaborate "screen scraping" processes to work around blocks. They can even completely restructure the underlying database, provided that they update the API interface to keep putting new sorties in the right place.
Quote from: Eclipse on July 08, 2013, 07:41:51 PM
I'd like to know who reviews the "business rules" before they are implemented, and who knows those rules better? A contractor or an experienced member.
You're absolutely right. In every software project I've worked on, we've always had subject matter expects (SMEs) working closely with developers to ensure we had good requirements, business rules, performance, workflows and usability.
To answer your question about ARC we have paid IT and a disaster support technology function that is nearly all volunteers. Our IT and DST play different roles. IT is concerned with systems where DST is concerned with service delivery in the face of disaster. IT handles day to day, DST brings cell phones, laptops, satellite connectivity, IP printers/faxes/gateways/etc. to support disaster relief operations. We use a system called Group/Activity/Position. These are functional. Groups are overarching concepts i.e. Ops Mgmt, Individual Client Services, Mass Care, Info and Planning, External Relations, Logistics, Staff Srvs, and DST. DST is then divided into a few different activities: networking, computer operations, communications, and customer service. DST has all of their procedures on every single computer on a DR so everything is written out on what needs done, how to do it, and is mostly OJT. Each activity then has a hierarchy of positions starting: service associate, supervisor, manager, and chief. Each has specific activity, DR requirements, life experience, and Red Cross training associated with each.
We are working harder to integrate IT and DST together and bridge a chasm like the one you are discussing. At the local level, in some areas DST volunteers are the IT group. In others DST does not exist. At national it is hit and miss. One of the ways this bridge is supported is through our disaster reengineering cycle. There is a new concept we are applying called Blue Sky/Gray Sky. This concept holds that everyone has a daily job and during disaster, that job might/will change and have some disaster element to every job. During blue sky IT is focused on maintaining our daily operational systems, intranet, physical assets, etc. During gray sky, IT will be working much more closely with DST (who consequently is made up mostly of numerous IT professionals) and hopefully DST will be working to backfill IT.
Quote from: Ned on July 08, 2013, 06:40:19 PM
Quote from: JeffDG on July 08, 2013, 05:53:42 PM
The problem is that NHQ isn't using the most abundant resource they have access to: Volunteers.
I can't really disagree with that. The question then becomes "why?"
Indeed, as a long-time CP guy I always wondered why NHQ didn't make more use of volunteers in their shop at NHQ. (Like IT, CP is severely understaffed and under resourced to accomplish what the membership expects.)
So, what sort of issues might it present to have volunteers working on IT issues?
Are there examples of other organizations that used volunteers to code some sort of "eServices - equivalent" product to serve over 60,000 members, a couple hundred employees, and track and maintain the qualifications for the folks who operate a couple of hundred million dollars worth of Federally-provided assets?
For example, does the Red Cross or the Air Force Association use some of their many volunteers / members in their IT functions at the national level?
How about the BSA?
NASA is certainly budget-constrained lately and has had some severe IT blunders that resulted in a satellite or two being lost. Do they use volunteers for any of their coding?
Does the Wikipedia organization have any lessons for us here?
Do you really think that the IT folks at NHQ are biting the helping hands being offered them out of spite or closed-mindedness? What reason could they have for doing that?
So let's talk about how to constructively engage volunteers in a cost-effective manner. But let's start with some historical examples where it has been successful in a comparable project.
I don't really have a dog in this fight as I am not an IT guy...
But the Encampment Management Program was done by New York volunteers and its used today in many encampments and saves a lot of time and energy for those staffs...
Quote from: NCRblues on July 08, 2013, 08:53:08 PM
I don't really have a dog in this fight as I am not an IT guy...
But the Encampment Management Program was done by New York volunteers and its used today in many encampments and saves a lot of time and energy for those staffs...
Agree. It rocks the darn casbah.
But how much of it is based on NHQ's data model? Almost none. Does it actually interface with NHQ? No.
It is a standalone app that uses the old CAPWatch system to do its participant authentication. (Now that CAPWatch is no longer, you have to jump thru hoops to put your wing's data in there)
Quote from: Ned on July 08, 2013, 05:43:24 PM
Quote from: SunDog on July 08, 2013, 03:52:03 AM
The "as is" with eServices shows a disturbing lack of vision, and consideration for members. I appreciate the example (shoving changes straight into prod), but, respectfully, it's like telling me having the flu ain't so bad, because someone else has pneumonia.
Rant complete. And pointless, like as not.
How strange. Anonymous ranting on the internet is usually so productive. Maybe you're not doing it right.
Perhaps he needs more sarcastic replies to get it working better. At the very least, it would keep him motivated in his desire to improve the organization...
Quote from: Ned on July 08, 2013, 05:43:24 PMAnd NHQ is severly resource-constrained. There have been multiple rounds of staff reductions in recent years. Mr. Rowland and his team have done terrific work trying to balance the missions and needs of the HQ. I don't envy the resource allocation choices he has had to make.
An interesting thing to say, since the needs of the mission are supposed to >be< the needs of HQ, and the mission is supposed to come first.
Quote from: Ned on July 08, 2013, 05:43:24 PM
But the bottom line is that to achieve the kind of modern eServices that you and other members would like will almost certainly take hundreds of thousands of dollars to develop and code a new system. (Even in Sharepoint.)
Which obviously we don't have. It would take a substantial dues increase to raise that kind of funds, which I suspect the membership would find unappealing. Alternatively, perhaps you can identify which major programs should be eliminated to provide additional support to IT.
I don't buy that, not even a little. Would a typical, government-eque, big-iron RFP, etc., etc., system require hundreds of thousands? Probably.
Would what
we need? No. In fact, I'd go so far as to say that if this project actually "interested" any hardware or software vendor, then it's not headed in the right direction.
This isn't the '90's and there are plenty of ways to get robust services inexpensively or even free, and I would hazard a guess that a competent single programmer
working in an open source, robust and free application could bolt the basic thing together in a weekend, maybe a couple if a new season of "Game of Thrones" has been released. The system itself
is pretty "simple", has pretty basic rules, and is not really dynamic in the ways most internet ecommerce systems are today. My wing has guys that do this stuff for "fun" (I know they need help),
tossing together systems like it was nothing, and usually the only roadblocks they encounter are NHQ's closed systems, lack of an API or documentation, and constant
changes with no thought to what's been done in the field.
We have literally hundreds, if not thousands of IT folks dying to take a crack at eServices, on their own time, for free. No one has ever asked.
I'll add another week for a UI team, and $30 for a whiteboard, since it does not appear that much time has ever been spent on UX design.
After that, it's just a matter of scale and bandwidth.
And it should >not< be hosted under anyone's desk at Maxwell, or inside any other CAP building or facility.
I'd add a Venti to the bet that a couple of phone calls could get us free hosting somewhere for the "cost" of
an endorsement and a little free press.
Like any disruptive change, it's not "easy", but that doesn't mean it isn't "simple". The biggest part is getting past "not invented here".
It's great to hear so many good ideas, so I'm kinda glad I stirred it up a bit. Someone contacted me offline, said there are only two (2) people in NHQ IT. Wow, bless 'em both! Do they even get days off?
Ned, I haven't seen CAP's budget, and I'm not qualified to suggest a place to cut, in order to generate bucks to fix eServices; maybe buy one less glass 182 next year? If that money comes out of a "diffrent bucket", I'd say rearrange the buckets - Senior Leadership go to bat for membership, get the money moved, right? Delay some capital expenditures, accelerate some asset sales, and get changed whatever needs to be changed to use the money for what's broken. If that won't cover it, look at some of the ideas already posted here?
I am qualified to evaluate software. And remediation, and there are sound ideas posted here, worthy of consideration by Senior Leadership. It 's kinda cheered me up a bit, to see smart folks with good ideas take a swing at this. Geez, it doesn't have to be a huge, monolthic, all-or-nothing, 1990's ERP type monstrosity project. Like someone said, break it down, map it out, use the membership.
Look, here's something that EVERYONE in CAP can do to help out the online system.
Test it.
When you find something "wrong", write up a detailed report for the IT people to look at.
They really can't use "hey this thing sucks" or "this this is broken"
However, they CAN use:
1. a detailed description of what you were trying to do (i'm trying to add promotion data for a prior achievement to capid 123456)
2. a detailed description of the steps you took leading up to the error
3. the specific error, copied and pasted, or screenshot from your screen (so they can replicate it)
4. it never hurts to throw in a suggestion for a fix, if you have that up your sleeve
5. your operating system, browser+version
I did some pretty extensive (mostly unsolicited) software testing, and reporting for the current rendition of ops quals, most of the cadet programs modules, and online testing. I found that thorough reports were well received, and especially with regards to the cadet programs modules /quickly/ implemented. A few times I interacted with the IT shop at nhq (usually replying to a report with further questions) they were prompt and polite. --I will say that is an improvement from the experience several years before, so it does seem to be getting better. If there was a ribbon for every bug or suggestion reported and implemented, i'd have a ribbon full of silver clasps.
I tend to find the airplane stuff pretty silly as well. And I am also no big fan of WMIRS for mission paperwork, although I haven't actually used it in a while (is it still the current application of choice?). I remember it striking me as something I may have written myself, in my free time (in other words, not very good).
Programming is tricky business. There is no one "right" way to solve a problem. No matter which way you choose, someone else will make (probably valid) arguments that the other way would have been better. No matter which features you implement, someone will make (probably valid) arguments for the features that you didn't. No matter how many things you fix, someone will always be quick to point out the things that are still broken. That's just life. --In CAP, additionally, the "rules" change about every 6 months, so what you produce that works correctly today is invalid and "broken" tomorrow. One thing that CAP doesn't do very well is 'splain "hey I (the undersigned) am the program manager in charge of this, here is what I have chosen and why, and that lines up with our (published) policies in the following ways."
Personally, if we were going to burn nhq's IT to the ground and re-build it,
My preference would be to focus our staff on data management. Make sure that we are capturing the data in the way that we need to capture it, and make sure it is highly available, highly accessible, backed up, snapshots going back into history, and properly secured (per field, per user). Then provide API to the membership to read and write that data. That would allow the field to write their own apps, and ideally share them amongst units. Yes, there would instantly be 1,000 apps to pull up a squadron roster. But the best ones would sort of float to the top quickly. When the 'business rules' become open source (within the org), anyone in the community can review them all, and point out dependency failures or conflicts, and propose a resolution.
The biggest obstacle, I think, is almost certainly paradigm shift about data ownership and protection.
And i'm not really sure as I don't have a current "feel" for the situation, but in the past I have recalled a sort of 'palpable' sense of "us vs them" between the nhq staff, and CAP membership. Particularly when it comes to ownership and control of things, in particular, as IT. To that end, I think there should be a national IT 'committee' made up of volunteers. And CAP's "CIO" should be a member at large. This group would be responsible for clarifying a member-based, unit-based vision, mission, purpose, and methodology for CAP's IT structure. The paid staff (full time and contractors) would then execute that on a M-F 8-5 basis.
I am nearly a master rated IT in CAP (and it's my civilian job, at which i'm reasonably successful), and I can't tell you off the top of my head who CAP's chief information officer is, or name one thing I have seen that person (or their office) publicly do, ever. If you want to know why the situation is what it is in CAP, start there. And whoever that is, might just have their hands tied from upstairs, for all I know... It's not an enviable position in the current climate.
Darin can tell you stories of olde about proposed (and shot down) content management structure, to put every squadron (group, wing, and region) in CAP under a common web service, with a standard "look and feel", with details for each unit to manage. I _STILL_ think that's a GREAT idea. If a unit wants to go "above and beyond" they can make another site and link to it from their 'official' cap one. But those units who can't spell internet, are still going to have something presentable, and as accurate as possible. // This idea should be implemented in conjunction with the above. You could use CAP-API modules in your "official" squadron website.
The full time guys at NHQ, I imagine, in addition to their e-services duties, probably also have to jockey toner and copy repair, troubleshoot computer breakage, add and delete accounts to the nhq network, audit and inventory hardware and software, probably run the office firewall, and who knows what else. And they SHOULD do that stuff; somebody has to. Supposing for my little proposal, two more fulltime people, and we're talking about specialized database, sysadmin, and API programmers, here... There's probably $200k right there, annually (at pretty much bargain basement range).
I don't think you WANT free hosting... I think you want to pay for it, and I think you want to get what you paid for (including, frankly, SLA). But I do think you want offsite hosting, probably in a HA cloud center. That's probably not going to be cheaper than a box or 2 in the closet at NHQ. HA data is also going to take a non-trivial amount of disk space, which is actually fairly cheap... but not free.
60,000 members (records) across whatever, like 25 tables, that's like 1.5Mil records.
Which is enough to blow up a database server, if it's configured poorly (and from what i've seen of capwatch, ours is configured quite poorly)
--which is where the specialized db admin comes in
It is not an insurmountable amount of disk space we are talking about, though. The expense comes in making it highly available, backing it up offsite regularly, and in adding snapshots for historical statistical analysis (this will balloon as when a member quits they were on yesterday's capwatch but they are not on today's).
The final piece of the picture is processing capability. The 'report server' (probably going to wind up being crystal, right?) is going to have to be able to handle at least hundreds of 'interested' members, developing reports. That many again, running reports. That server is going to get locked up and brain dead, and require zombies to be killed, and so forth and so on. "dumb" users are going to create reports that sap the system down. The job queue is going to get kludged. This is all just standard stuff for report engines, and it takes someone to restart the service; or the whole machine. Maybe even multiple machines, load balanced... That's just for apps that read the data. Writing to the database would need to be much more closely controlled, and apps that did it would probably need to be thoroughly tested, if not professionally developed.
**The current system definitely needs to continue running as well, whilst something 'new' is stood up as a replacement.
Anyway, it's doable.
But I think ned has it about right at 'hundreds of thousands'. Probably about $250k or so. That's about $4 per year annual dues org wide.
The changes to the organizational structure and attitude, however, would cost nothing at all (well not in dollars anyway), and are quite frankly pre-requisite to any technical solution that may be attempted. There is no point whatsoever in spending one penny on "improved capability" until those things are "fixed".
"The changes to the organizational structure and attitude, however, would cost nothing at all (well not in dollars anyway), and are quite frankly pre-requisite to any technical solution that may be attempted. There is no point whatsoever in spending one penny on "improved capability" until those things are "fixed".
Nicely said, clearly articulated. . .Real world, likely we'll need to wait on normal attrition/changes in management. I think, reading between the lines, that eServices is perceived as "good enough to get by" by Senior Leadership. Not intending to be cynical, but the impact of eServices' poor implementation on NHQ staff is a lot lighter than on the membership. The pain isn't shared all that much. I am pretty certain eServices (and WMIRS) hurts retention and mission readiness - I don't think anyone walks away just because these apps are awful, but they do figure into the sum of frustrations. I think Senior Leadership can truthfully say both apps work - because they do; they just miss the bigger picture that they are a major frustration point for members. There are a LOT of volunteer member hours being sucked up by these apps. Those hours come out of availability for other tasks. TANSTAAFL, right?
But, speaking to the fix! Someone would have to manage the project, regardless of the mix of resources used. The API route, with data hosted centrally, sounds good, and doable. I imagine there is a retired, solid, experienced PM out in CAP Membership land, who might spare a year to shepard this. IF IF IF NHQ would allow it to proceed. As you say, pointless to try without NHQ buying in. And if they sustain a "NIH" attitude, might as well stay home. Maybe someone on this thread who HASN'T made 'em mad could make the pitch? It would be low impact ($$$ and time) on NHQ IT to get started - hand over the schema and rules, and answer some questions. . .if the design is a success, the hosting and provisioning for "production" could get worked out late in the game. Heck I'd chip in $10 a year for a couple of years. . .
Quote from: SunDog on July 09, 2013, 06:55:12 PMI think, reading between the lines, that eServices is perceived as "good enough to get by" by Senior Leadership. Not intending to be cynical, but the impact of eServices' poor implementation on NHQ staff is a lot lighter than on the membership. The pain isn't shared all that much.
This is certainly my perception, and shared by others.
Quote from: SunDog on July 09, 2013, 06:55:12 PM
I am pretty certain eServices (and WMIRS) hurts retention and mission readiness - I don't think anyone walks away just because these apps are awful, but they do figure into the sum of frustrations. I think Senior Leadership can truthfully say both apps work - because they do; they just miss the bigger picture that they are a major frustration point for members. There are a LOT of volunteer member hours being sucked up by these apps. Those hours come out of availability for other tasks. TANSTAAFL, right?
Please put that on a T-Shirt, and require this be discussed at every committee meeting!
Volunteer hours maybe "free", but they aren't unlimited by a long shot. More important, member
initiative and good feeling is even more limited. Whether it's eServices, a uniform argument,
or some other more trivial nonsense that could be ended with a sentence but has been left open for a decade, every minute wasted wrestling a system or decision that should be a baseline
"given" is a minute (or hours) not spent building real plans, recruiting, or training, or anything else which is actual mission-focused.
I know that after I've spent time either wrangling the system or arguing with frustrated members about the way things "should" work, vs. the way they actually do,
I'm not particularly interested in digging down into an ops plan or other stuff that's actually my job - so that stuff falls to the side, and we never make any progress.
Rinse and repeat that times 1400 some charters and staff at each level.
As you may have guessed, I have definite thoughts on this matter, but it's likely that I don't meet the criteria of "someone who hasn't...", nor am I retired.
Participating in such an effort: Count me in! Love to pitch in and help.
PM'ing such an effort: Even though it's what I do (have the PMP cert and everything!), I can't see giving it enough time/effort/attention.
Quote from: Eclipse on July 09, 2013, 07:16:47 PM
Quote from: SunDog on July 09, 2013, 06:55:12 PMI think, reading between the lines, that eServices is perceived as "good enough to get by" by Senior Leadership. Not intending to be cynical, but the impact of eServices' poor implementation on NHQ staff is a lot lighter than on the membership. The pain isn't shared all that much.
This is certainly my perception, and shared by others.
Quote from: SunDog on July 09, 2013, 06:55:12 PM
I am pretty certain eServices (and WMIRS) hurts retention and mission readiness - I don't think anyone walks away just because these apps are awful, but they do figure into the sum of frustrations. I think Senior Leadership can truthfully say both apps work - because they do; they just miss the bigger picture that they are a major frustration point for members. There are a LOT of volunteer member hours being sucked up by these apps. Those hours come out of availability for other tasks. TANSTAAFL, right?
Please put that on a T-Shirt, and require this be discussed at every committee meeting!
Volunteer hours maybe "free", but they aren't unlimited by a long shot. More important, member initiative and good feeling is even more limited. Whether it's eServices, a uniform argument,
or some other more trivial nonsense that could be ended with a sentence but has been left open for a decade, every minute wasted wrestling a system or decision that should be a baseline
"given" is a minute (or hours) not spent building real plans, recruiting, or training, or anything else which is actual mission-focused.
I know that after I've spent time either wrangling the system or arguing with frustrated members about the way things "should" work, vs. the way they actually do,
I'm not particularly interested in digging down into an ops plan or other stuff that's actually my job - so that stuff falls to the side, and we never make any progress.
Rinse and repeat that times 1400 some charters and staff at each level.
Wait, are you proposing an ICL to authorize this Committee to have a custom uniform with T-shirts? >:D
And in typical fashion, *bam* its a uniform discussion.
Quote from: NIN on July 09, 2013, 09:07:55 PM
And in typical fashion, *bam* its a uniform discussion.
>:D
Quote from: coudano on July 09, 2013, 09:08:43 AM
Look, here's something that EVERYONE in CAP can do to help out the online system.
Test it.
When you find something "wrong", write up a detailed report for the IT people to look at.
They really can't use "hey this thing sucks" or "this this is broken"
However, they CAN use:
1. a detailed description of what you were trying to do (i'm trying to add promotion data for a prior achievement to capid 123456)
2. a detailed description of the steps you took leading up to the error
3. the specific error, copied and pasted, or screenshot from your screen (so they can replicate it)
4. it never hurts to throw in a suggestion for a fix, if you have that up your sleeve
5. your operating system, browser+version
This is key for
any support request, it makes ITs job a heck of a lot easier.
Quote<snip>To that end, I think there should be a national IT 'committee' made up of volunteers. And CAP's "CIO" should be a member at large. This group would be responsible for clarifying a member-based, unit-based vision, mission, purpose, and methodology for CAP's IT structure. The paid staff (full time and contractors) would then execute that on a M-F 8-5 basis.
There is an IT committee, however in my honest opinion, they are too far removed from the field at this point in time.
Quote
I am nearly a master rated IT in CAP (and it's my civilian job, at which i'm reasonably successful), and I can't tell you off the top of my head who CAP's chief information officer is, or name one thing I have seen that person (or their office) publicly do, ever. If you want to know why the situation is what it is in CAP, start there. And whoever that is, might just have their hands tied from upstairs, for all I know... It's not an enviable position in the current climate.
The CAP ITO is Lt Col Bill Hughes of NYWG, he's been in the position as long as I can remember it being there. Feel free to guess my opinion on that (note: he heads up the IT committee I commented on earlier). NHQ/IT is headed up by Mr Joe Hall, I had the opportunity to meet him at a National Board meeting before he got the position (he was a dev at the time) he's a good guy. The rest of the IT team from whom I've chatted with here and there, mostly online or at conferences, are good hard working people, they just have too much to do and too little time. Not only are they working on member facing items, but also employee only, just remember that.
Also, coudano, great post, seems few actually try to 1) understand what is going on beyond their playpen, 2) realize just what it might take to go with the whole "scrap and rebuild better" plan. I'd just add one thing, with eServices being on a .gov domain, there are an inordinate amount of rules and regulations that must be abided by on that front, which would add complexity, time and money, among other resources.
Quote from: Tim Medeiros on July 10, 2013, 07:27:58 PM
I'd just add one thing, with eServices being on a .gov domain, there are an inordinate amount of rules and regulations that must be abided by on that front, which would add complexity, time and money, among other resources.
Yet at the last CSAG meeting there was a proposal, referred to committee, to ban anyone other than NHQ from using anything but .GOV for their internet operations, showing yet another "disconnect" between the national leadership and the boots-on-the-ground.
So, if this goes forward, you'll have 6 months to shut down SERCAP.US. An excellent use of volunteer time that would be.
Quote from: JeffDG on July 10, 2013, 07:45:19 PMSo, if this goes forward, you'll have 6 months to shut down SERCAP.US. An excellent use of volunteer time that would be.
Actually, this needs to happen and sooner then later, having 52 wings with separate infrastructure and domains, etc., is unprofessional, and borderline FWA for those
that are paying for it, not to mention that nothing says "professional" like an an email from "pilotcutie76@juno.com" with a pharma ad in the sig line.
Every member should get a wing.cap.gov email address when they join, and be required to use it for access to all CAP systems. NHQ is already using GApps for cap.gov, so
it's just a matter of the number of licenses.
Create wing-level user admins, publish a set of templates for unit and activity use, and prohibit the use of other services for email and websites (which would also go a long way in the
fight against spam and shore up OPSEC). Manage the exceptions as necessary, and there won't be many.
And then move on.
Quote from: Eclipse on July 10, 2013, 08:08:30 PM
Quote from: JeffDG on July 10, 2013, 07:45:19 PMSo, if this goes forward, you'll have 6 months to shut down SERCAP.US. An excellent use of volunteer time that would be.
Actually, this needs to happen and sooner then later, having 52 wings with separate infrastructure and domains, etc., is unprofessional, and borderline FWA for those
that are paying for it, not to mention that nothing says "professional" like an an email from "pilotcutie76@juno.com" with a pharma ad in the sig line.
Every member should get a wing.cap.gov email address when they join, and be required to use it for access to all CAP systems. NHQ is already using GApps for cap.gov, so
it's just a matter of the number of licenses.
Create wing-level user admins, publish a set of templates for unit and activity use, and prohibit the use of other services for email and websites (which would also go a long way in the
fight against spam and shore up OPSEC). Manage the exceptions as necessary, and there won't be many.
And then move on.
Actually, Google will now permit unlimited free licenses to non-profits (up from their old limit of 3,000). Now the issue is, they might treat a ".GOV" as a Google Apps for Government account, and then say "$50/user/year, no volume discounts", while a .org or other domain name can skate under 501(c)(3) rules.
Hell, if NHQ needs a provisioning script, I have one for TNCAP.US already that automatically provisions accounts and "Drive" rights based upon duty positions, give me a few days and I'm approximately 99% sure I could scale it (there are no limitations in the code at all).
And that's precisely what we have for TNWG...unit-level templates and events. We are building a ton of capability.
Heck, if NHQ would just give us a SAML gateway to eServices, I could get rid of users having to remember multiple passwords.
Quote from: JeffDG on July 10, 2013, 08:16:53 PMActually, Google will now permit unlimited free licenses to non-profits (up from their old limit of 3,000). Now the issue is, they might treat a ".GOV" as a Google Apps for Government account, and then say "$50/user/year, no volume discounts", while a .org or other domain name can skate under 501(c)(3) rules.
National is already using Google Apps for the cap.gov domain. I don't know what flavor it is, hopefully it's the education flavor. The .gov restriction indicated for the free accounts
is actually a non-issue once you substantiate your .gov email is tied to a legit 501(c)3, which is unusual but obviously not unheard of. The indicated subdomain restrictions are also, obviously, a non issue.
My wing just (finally) converted our wing.cap.gov account to Apps for Ed this year. No cost.
I first noticed NHQ couple years ago when I added someone to my contact list with a custom picture and it asked me if I wanted to share the pic with the contact - that only works
on Gmail-Gmail hosted systems. After that I noticed a number of NHQ websites, and a few sign-up forms were "Sites" or "Apps" hosted services.
So the main infrastructure is already there.
Quote from: Eclipse on July 10, 2013, 08:52:03 PM
Quote from: JeffDG on July 10, 2013, 08:16:53 PMActually, Google will now permit unlimited free licenses to non-profits (up from their old limit of 3,000). Now the issue is, they might treat a ".GOV" as a Google Apps for Government account, and then say "$50/user/year, no volume discounts", while a .org or other domain name can skate under 501(c)(3) rules.
National is already using Google Apps for the cap.gov domain. I don't know what flavor it is, hopefully it's the education flavor. The .gov restriction indicated for the free accounts
is actually a non-issue once you substantiate your .gov email is tied to a legit 501(c)3, which is unusual but obviously not unheard of. The indicated subdomain restrictions are also, obviously, a non issue.
My wing just (finally) converted our wing.cap.gov account to Apps for Ed this year. No cost.
I first noticed NHQ couple years ago when I added someone to my contact list with a custom picture and it asked me if I wanted to share the pic with the contact - that only works
on Gmail-Gmail hosted systems. After that I noticed a number of NHQ websites, and a few sign-up forms were "Sites" or "Apps" hosted services.
So the main infrastructure is already there.
Well then, hell yes, that's a great solution!
I would caution against the "only cap.gov" addresses thing...even with the stuff we're doing we only get about 10% of folks sign in in a given month, and ~15% have signed on to their @tncap.us account, ever.
We do, however, have mailing lists that include member's primary e-mail address (drawn from eServices) that work fantastically well...also auto-provisioned.
For OPSEC reasons, we only permit "Drive" rights to internal accounts, but e-mail going out is less bad.
A better approach would be a "carrot" vs. a "stick" however.
Quote from: JeffDG on July 10, 2013, 08:55:53 PM
A better approach would be a "carrot" vs. a "stick" however.
I would tend to agree, however the sad reality is that in CAP a lot of people won't do anything unless you force the issue.
One of my old units walked this path - requiring people to only use their CAP email for CAP business. It was an uphill climb,
but after the initial gnashing of teeth, people got over it. Not 100%, but the ones you really care about.
These days there are plenty of easy ways to consolidate email (hint: if you have to use more then one email client for >all< of your messages,
you're doing it "hard", if not wrong. The occasional stick-in-the-mud IT shop notwithstanding). I Have something like
8 email addresses from different companies and organizations all consolidated seamlessly in my primary gmail domain.
And no spam, either - now there's a useful wing conference breakout - "Consolidating your email accounts".
Anyway - the amount of time that could be freed up, not to mention money and other resources with this large but relatively simple project
is pretty significant.
Quote from: JeffDG on July 10, 2013, 08:16:53 PM
Actually, Google will now permit unlimited free licenses to non-profits (up from their old limit of 3,000).
"I was not aware of that!"
Thats encouraging. Now build an LDAP provisioning setup from eServices.. :)
Quote from: NIN on July 10, 2013, 09:10:14 PM
Quote from: JeffDG on July 10, 2013, 08:16:53 PM
Actually, Google will now permit unlimited free licenses to non-profits (up from their old limit of 3,000).
"I was not aware of that!"
Thats encouraging. Now build an LDAP provisioning setup from eServices.. :)
Like I said, I've cracked that nut already...at least as far as provisioning.
Not LDAP, I'd actually prefer SAML
Quote from: JeffDG on July 10, 2013, 07:45:19 PM
Quote from: Tim Medeiros on July 10, 2013, 07:27:58 PM
I'd just add one thing, with eServices being on a .gov domain, there are an inordinate amount of rules and regulations that must be abided by on that front, which would add complexity, time and money, among other resources.
Yet at the last CSAG meeting there was a proposal, referred to committee, to ban anyone other than NHQ from using anything but .GOV for their internet operations, showing yet another "disconnect" between the national leadership and the boots-on-the-ground.
So, if this goes forward, you'll have 6 months to shut down SERCAP.US. An excellent use of volunteer time that would be.
Just to point out, that proposal was actually authored by Col Webb, the cap.gov domain administrator. He is another that I have an issue with. When trying to setup a system to work with Google, his response to a clearly DNS issue was to use a "standard email provider".
...and good luck getting a .gov DNS assignment from anyone to point anywhere. Talk about tightly controlled garbage and politics. If the provider agrees to the conventions, then so be it.
When your wing's provided web space won't support anything other than static HTML, and they've been promising PHP and MySQL for over seven years, with inquiries met with zero response over the years, no wonder many of us say screw it and do something else. NHQ has our official site as the wing provided .gov address, but it's a redirect to something else, that costs us -zero- except time maintaining the site, which you have to do anyway. So the net is zero.
As for the "use a standard email provider", that's kind of interesting. CAP.gov uses gmail itself.
So, if I'm to understand this, there's movement afoot to "ban us" from using "anything" other than *.cap.gov, and yet with so many other Wings having bailed to other domains, why?
Nevermind the "it needs to be be changed, it's unprofessional", why have they bailed?
Is it because the hosting provided is nearly useless and someone at the top refuses to budge? Case in point, the recent thread about RIWG and it's new site, vs. the existing available, and wrong content, that no one could seem to get changed. Really? Couldn't' get a password from a provider, once you figure out who that is, which certainly has to be trackable from the DNS record, that is controlled by NHQ.
My reasoning is I'm working on a wing level on doing just that, and want to use php/mysql and enter the 21st century, while at the same time avoiding the debacle that seemed to carry out with RIWG. Though I do have access to the wing level web account, at least. Can't do much with just ftp and no idea what capabilities the server has. Uploading a php info file results in it being handed back to me by the browser.
Static pages are it. Is it possible to run with something else, or do I use a combination of both, and do everything I want on a .org, using commercial (gratis for non-profits) hosting?
Hello a2capt, I hear your frustration in every word. Your Wing is lucky you stay engaged. I dunno if this is good or bad, but I'm not sure if folks in my wing even use our web site on a regular basis. I'm an active MP, but I may go several months without hitting the site - might jump in to look at the calendar; but mostly, if something is coming up, we get an email blast. We tend to run events and keep up to date via email. We use AircraftClubs.com (pilots, anyway) to track each other down, find phone numbers, emails addresses, and warn each other about maintenance issues.
Static sites likely won't cut it anymore, and I think will probably drift into disuse. While ours has some value, it's large, has a lot of outdated info, and is kinda hodge-podge in organization. Not a real bad site, just in need of TLC, and there are quicker, more nimble ways to get info and communicate. Good on ya for trying, but unless/until a critical mass of discontent is built in the membership, things will remain as they are, most likely. Look back at this thread, see the great ideas, and also the resistance expressed.
Quote from: a2capt on August 12, 2013, 05:57:29 PM
So, if I'm to understand this, there's movement afoot to "ban us" from using "anything" other than *.cap.gov, and yet with so many other Wings having bailed to other domains, why?
Nevermind the "it needs to be be changed, it's unprofessional", why have they bailed?
Is it because the hosting provided is nearly useless and someone at the top refuses to budge? Case in point, the recent thread about RIWG and it's new site, vs. the existing available, and wrong content, that no one could seem to get changed. Really? Couldn't' get a password from a provider, once you figure out who that is, which certainly has to be trackable from the DNS record, that is controlled by NHQ.
My reasoning is I'm working on a wing level on doing just that, and want to use php/mysql and enter the 21st century, while at the same time avoiding the debacle that seemed to carry out with RIWG. Though I do have access to the wing level web account, at least. Can't do much with just ftp and no idea what capabilities the server has. Uploading a php info file results in it being handed back to me by the browser.
Static pages are it. Is it possible to run with something else, or do I use a combination of both, and do everything I want on a .org, using commercial (gratis for non-profits) hosting?
No, we all host in the same way, with a robust service, and stop wasting our time on home-brewed solutions, per wing or unit.
There is absolutely nothing unique in any wing that requires a home-grown CSS. Nothing, NADA, No. Thing.
Sure, some things NHQ puts out might not be as uber-kewl as something a person can cobble under their desk,
but I'll take the risk / reward on losing another "sweet" (typicall flakey) Sharepoint, wing-hosted server, or
social media debacle over just having basic services that don't make use look like the PTA.
Quote from: Eclipse on August 13, 2013, 03:59:07 AM
Quote from: a2capt on August 12, 2013, 05:57:29 PM
So, if I'm to understand this, there's movement afoot to "ban us" from using "anything" other than *.cap.gov, and yet with so many other Wings having bailed to other domains, why?
Nevermind the "it needs to be be changed, it's unprofessional", why have they bailed?
Is it because the hosting provided is nearly useless and someone at the top refuses to budge? Case in point, the recent thread about RIWG and it's new site, vs. the existing available, and wrong content, that no one could seem to get changed. Really? Couldn't' get a password from a provider, once you figure out who that is, which certainly has to be trackable from the DNS record, that is controlled by NHQ.
My reasoning is I'm working on a wing level on doing just that, and want to use php/mysql and enter the 21st century, while at the same time avoiding the debacle that seemed to carry out with RIWG. Though I do have access to the wing level web account, at least. Can't do much with just ftp and no idea what capabilities the server has. Uploading a php info file results in it being handed back to me by the browser.
Static pages are it. Is it possible to run with something else, or do I use a combination of both, and do everything I want on a .org, using commercial (gratis for non-profits) hosting?
No, we all host in the same way, with a robust service, and stop wasting our time on home-brewed solutions, per wing or unit.
There is absolutely nothing unique in any wing that requires a home-grown CSS. Nothing, NADA, No. Thing.
Sure, some things NHQ puts out might not be as uber-kewl as something a person can cobble under their desk,
but I'll take the risk / reward on losing another "sweet" (typicall flakey) Sharepoint, wing-hosted server, or
social media debacle over just having basic services that don't make use look like the PTA.
Php and/or SQL is not too much to ask from any respectable ISP. I still can't understand why is it so hard for cap.gov to provide that functionality. It has nothing to do with making the the site flashy or über kewl.
NIH, maybe. Tension between National's need for rigid central control and membership's frustration with bad IT/ bureaucracy?
National answers to USAF, & congress, and has to protect their fiefdom. Members want a rewarding experience and respect for the time invested. Big diffrence between CAP and AOPA - AOPA answers to thier membership. CAP National doesn't. Not ragging on them particularly; most similiar groups behave this way, except for the stellar performers.
HQ 's always feel like they manage everything (and should also control everything). Earlier in this thread someone said something about CAP National "managing aircraft". Of course, they don't - he confused accounting with managing. The line gets a little blurry, true, if a Wing gets low on hours or sloppy on reporting. But mostly, day to day, the aircraft are managed by the volunteers.
As is the content on Wing web sites. National likely doesn't want you going too far afield, or innovating, not outside thier span of control. You might do something embarrasing. You might also do something very useful and with great positive impact. But that won't necessarily do NHQ any good. It's not worth the risk for them. You start aggregating data, building business rules, innovating with apps that catch on, they hsve to "manage" the fall-out from that. Best of luck, and we are lucky you perservere.
When you compared CAP to AOPA, you lost any credibilty.
Quote from: Eclipse on August 14, 2013, 03:48:51 AM
When you compared CAP to AOPA, you lost any credibilty.
Actually when he said "AOPA answers to its membership" he lost credibility.
Quote from: JeffDG on August 14, 2013, 12:41:52 PM
Quote from: Eclipse on August 14, 2013, 03:48:51 AM
When you compared CAP to AOPA, you lost any credibilty.
Actually when he said "AOPA answers to its membership" he lost credibility.
Heh - fair enough.
I dunno; when I compare the web sites, the service delivery via the sites, the navigation, info accuracy and organization, it looks to me like AOPA has a tiny edge, perhaps? My presumption is AOPA may feel a greater need to deliver a quailty on-line product, since they have a direct connection between their member's wallets and AOPA's continued existence as a business.
My point is that CAP's fortunes aren't as directly dependent on delivering well implemented systems for member use. NHQ can throw something over the wall that works just well enough, a 60% solution, say, and most of us will just live with it. Which we do.
Two somewhat diffrent business models, regardless of how you feel about AOPA's conduct of their business or politics. AOPA might be long gone, had they set the web-app bar at the same level as CAP. AOPA can (and does) annoy members, for sure; but you can find what you need, when you need it, on a web site that's built for member support, instead of management's convenience. They pretty much HAVE to have a modern web site to stay in business. NHQ doesn't. If it makes more sense to you, substitute another membership org wherever I typed "AOPA". Try EAA, or American Diabetes Association, or whoever. . .
Look, I recognize that almost any organization in the same boat as NHQ would probably behave the same way. Our senior leadership would be exceptional if they adopted some of the great ideas posted earlier, had that vision and ambition. That's not in the cards right now, and I think mostly for the reasons I posted.
Wait, you're comparing AOPA and CAP's websites?
Um, for most members that's all AOPA is (and a window sticker for their car), they better have a decent website, because without it, they ain't nothin'.
Not to mention that AOPA's web services aren't stafed by volunteers in a governmental paradigm. It's all highly-expensive professional service companies.
Kinda my point, really;
Try to track here -
1. NHQ doesn't have an incentive to deliver solid web services. So they don't.
2. Member sites that do have an incentive, deliver. Or business suffers.
Summary - NHQ isn't gonna adopt any of the ideas in this thread, because there is no incentive for NHQ to do so. I don't know you, but I imagine you won't drop out of CAP because eServices and WMIRS are bad tools. You might get less done, or participate less, but those aren't easy metrics to capture, and not ones NHQ has to answer to anyone for.
A solid web site, with solid apps, doesn't have to be expensive; again, see previous posts. It'd take some vision to get there. You seeing any of that?
Talking to the frustrations expressed here, IMHO, I'm saying this is about as good as it's gonna get, until senior leadership has some turover, or an upper-middle manager takes it on, owns it, and has the skill to champion it successfully. Remember North Dallas Forty? "We ain't part of team, we're part of the equipment".
Haven't had extensive use of eServices, duty and track stuff, but this feedback should be channeled to NHQ. If no volunteer development, maybe some help with documentation and tutoring of programs. :clap:
Good thoughts, positive approach. There is a user guide, of sorts, and word of mouth on how to navigate the pitfalls. Could be an interesting project to blog on - walk through the mine field, report back on where to step, or not step, maybe starting with the highest use, and most broken features, or least intuitive tasks.
NHQ has heard it all before. An earlier, annoyed post likely came from there. They don't have the money to do it in the tradtional way, and doing it in an innovative manner would be real stressful for the corporate culture. Hey, things always change. Maybe next year, or the year after.
Tough for the Wing level folks, too - running static sites with limited tools. It is what it is. . .