* Updated * I've talked before about the power of hybrid applications. This one, out in the wild tonight gives the ease of use associated with native applications combined with security and flexibility of the back end Domino system. A professional quality installer and code management helps too.

This kind of development is going to be very powerful.

OK, for Bob:

The Problem: In addition to fire radios and "Minitors" (Receive only radios with pager "wake on tone" functionality), most members of a small town fire department carry traditional pagers. This is due to the range limitations on the radios. Pagers can't replace the radios entirely for notification of emergencies because they're not real time -- but their added range means they're useful for people who work further away, and they're used for non-emergency notifications like trucks out of service or training announcements. The thing is, in order to do an "all page" the pagers had to be from the same company. That means 50+ people paying $12 a month for a device they don't otherwise need. Either the department pays this or the members. Usually the members as its "noncritical". Most volunteer departments are actually "paid part-time" -- members earn a small amount of money when on actual calls, and sometimes for training time. This is used to cover the cost of things like the pagers, better boots, or additional gear. The goal is to break even. ;-) As far as this $12 goes, its a lot of money for something that could otherwise be handled by the ubiquitous cell phone. The fire department volunteers are not usually made up of doctors and lawyers. Sadly, its the people with the lowest incomes that do the most volunteer work. Its also well paid contractors and other solid blue-collar workers. White collar participation is low.

This application lets people maintain whatever text-capable device they want, from whatever company they want. It means dropping the $12 a month charge for the fifty plus guys in each department. Right now, its a first pass 'proof of concept' I did for free for my own department (well, for the savings of my own $12 a month anyway). Next month, I plan to roll out a commercial version.

There are several components to the application right now. The first is a web site which allows people to manage a directory with their pager numbers and such, along with rules to govern when and how those pagers get used -- what "type" of pages they want to receive, from who, and during what time. There are administrator roles as well who can manage everyone, and you can delegate access to manage your profile to other people. This last is useful for the less computer savvy types who would rather have a buddy handle their setup. Groups are also accommodated -- engine companies, officers, etc.

Users can send pages to each other via the website, but instead of the traditional way of doing it, this way the sender is known -- which cuts out B.S. pages, and the rules are applied by the receiver -- each member decides what "type" of pages, when, by whom, and at what priority. Members can have as many devices as they want and have as many rules as they want making the system very flexible. One example is setting up a catch-all rule that routes to an email mailbox for those times when you don't want to be disturbed by don't want to miss anything.

Then next part is an automation interface, where the server will accept an xml package containing the information for a pager notification and apply the rules before sending the notice. Initially, this is used by a program written in C++ which monitors the mic line on the pc, which is connected to a scanner. The program 'listens' for a specific tone sequence indicating a fire call or another indicating a rescue (EMS) call. If you recall the old "Emergency" show from the 1970's, you know the tones I'm talking about. When it spots one, it sends a notice to the pager. Some people work ten or fifteen miles away. When they see the page, they can go to the website and hear the streamed audio to decide if they should leave work for a big call like a structure fire, or stay if its an alarm sounding with no reports of smoke or fire.

The Visual Studio application is a desktop side client that has similar functionality to the web site for paging. It sits as a system tray icon, and when clicked brings up a dialog box which accepts the text to send, and optionally allows the sender to select the recipient, the type of page, and the priority. Pages are broken into 100 character chunks and sent as multiple chunks, so the application indicates when a message will need to be split while the user is typing, and how many splits. That allows the sender to abbreviate text to one page most of the time instead of one full page and one with a single word as used to happen. Because the username and password can be locally stored, and the application is installed at the client, its much more suited to use at the dispatch center where simplicity and speed is critical. Logging into a website is too time consuming and "out of flow" with what they're trying to do.

The vs.Net application has two current interfaces to the Domino side. The first is at startup and at intervals an http GET is sent to an agent which responds with an xml packet response list of names and groups to populate the dialog box. The second is the http POST which sends the page. Domino agents do the logic of applying the rules and sending the pages. The applications is much more comfortable to use than a web site.

The other important part of the studio app, is that it has a professional look and feel, an install cd, a professional quality installer and uninstaller -- in short, it looks like a serious tool. This adds credibility when working with other organizations.

For the commercial product, a few changes and additions are in the works.

First, the client side application will include the ability to manage your profile. Also, it will be COM enabled. That will allow the notifications to be automated and tied into the dispatch software itself easily enough. A server side web services interface will also serve this function. Rules will be simplified and wizards created for managing devices. Also, a set of optional services like zip code based automatic weather alerts will be built into the offering. Customization of look and feel at the web side, and to some limited extent the client side is also planned. User, device, and rules management options will also be configurable so that departments can decide how much flexibility is allowed at the user level.

I'd like to keep the streaming audio distinct from it -- it really is unrelated. I will offer a "trigger" functionality in the client side app that can act as a pager itself. That is to say, each client can be "woken up" by a page and shell out to some other action. An example would be a fire tone page triggers the clients currently connected. One of then is at the desk of a guy several towns over. He can set his to launch his browser to the streaming audio site to turn on the radio. That will give him functionality like his Motorola Minitor radio at longer distance.

Each user and group will also have an email address, and WAP is a possibility as well.

The goal is to charge $50/mo for a department of up to 100 users, and incrementally up from there on a sliding scale. Once three or four departments are on the system, it will get moved to a pair of servers at a professional grade collocation site. So far, interest in the application at other departments I've talked to is 100%. That is to say, market demand is 100%. There are other tools out there, but I'm told they are not even close to this in terms of capability. I've not seen them as my approach to competition is to let it worry about itself.

I'm not sure if Domino will be used for the final back end, as it lends itself well to a simple set of servlets and can then run on a Tomcat/Jboss environment which may better match the scale needs and will remove the per-user license costs on the Domino side-- which right now are higher than I plan to charge per user per month for the system. I won't consider an IIS back end because I don't like the security issues on the back end for that..