-- Mankoff (email)

In software development we do something much like this with Netmeeting and a telephone bridge.

The net meeting software transmits a real-time desktop to all participants of the meeting, to consider a common work area. The owner of the desktop may relinquish control (rarely) to others, or keep it (almost always) to serialize changes. Limited only by availability of the Netmeeting software, time zones, and the cost of the phone link (commercial bridges cost about 10 cents per minute per user), this conveys inflection and tone but not body language, very quickly communicates the result of changes, and allows each participant to consider different parts of the display.

If conversational tone is not important or not desired, if accent gets in the way, or if the budget is low, then the meeting may use an internet chat link instead. The information resolution of a computer display limits what is shared among all users at once. If activities take place on a server to which everyone may log in, then each user (better with two screens) may see what the meeting presents, and also separately examine underlying code, configuration files, or a running system, to inform the meeting.

-- Jason Catena (email)

"Full information" is perhaps stretching it a bit, and I would argue, almost exactly what we have learned is *not* wanted. What Philip discusses in his article is transmitting life-or-death flight telemetry data, literally the transmission of measurements to a qualified colleague who can act in an advisory capacity. Air speed as measured by the Pitot tube, pitch and yaw as measured by the gyros, etc. And, in the case of flight, the issue is monitoring a potentially overwhelming amount of live, critical information. In the F/A-18 Hornet series of jets, telemetry is analyzed in software and the voice of "Bitching Betty" alerts the pilot to abnormal patterns.

There is also live, monitored telemetry, in hospitals, for patients with cardiac conditions. Just walk to one of the medicine wards of any US hospital and ask for the telemetry room. In the ICUs the telemetry will include ventilation information as well and is often displayed in the room, at the nurses's station, and it is accessible to the docs from various other computers or networks at all times. In hospital telemetry, technicians are assigned to monitor that data full time while the doctors and nurses attend to all issues, only spending some of their consciousness on "telly". And even the technicians are backed up by alarms that sound when software detects well understood wave form abnormalities.

Then there's military telemetry like GCCS and cooperative engagement capability which provide enough resolution that a "silent shooter" can engage a target based on fire-control data from a third source. As an officer of the deck, ship's weapons coordinator, combat direction center watch officer or tactical action officer on ships, I was often overwhelmed by the amount of real-time collaboration with various colleagues (fifteen screens and six audio circuits would not be unexpected). Like Bitching Betty and the alarms in hospital telemetry rooms, the navigation and fire control software has been designed to monitor for threat profiles and can even be programmed for 'full auto' or 'semi-auto' engagement with fire control radar, missiles and guns. I'm not aware of any system being set to 'full auto' outside of controlled test range scenarios. Just thinking about that gives me the hebbie-jebbies.

On aircraft carriers, flight telemetry is passed between aircraft and aircraft carriers via a system commonly called "needles". A qualified pilot, nick named "Paddles" is on deck and in constant radio contact with the pilot during final approach. Before I left the fleet the aircraft carriers and jets had advanced to a fully automated collaborative system that allowed the ship to land the plane while the pilot literally kept her hands off the controls.

These most-obvious/well-funded applications were some of the first collaborative communications, which funded the development of many of the protocols we now use regularly. Now that we have protocols, we use them more. For example, it's almost certainly not necessary to have operating robots, remotely controlled by surgeons over the internet, but they're here. One thing I haven't heard of yet is an operative robot that monitors telemetry and is programmed to sound alarms or respond automatically to a developing threat to patient safety.

Where standing radio circuits aren't required, there are plenty of available synchronous and asynchronous tools for communication. So many that few people bother to learn more than a few. I admin a server which currently has 11 different ports open; each port allows access to a different application-layer communication protocol, eg, port 80 for web traffic. In addition to irc chat, regular chat, wikis, email, command line tools like write, SMS "text" messaging, and phones, there are VNC and RDP, which are well understood protocols for distribution and remote control of a graphical desktop over networks, similar to what Jason Catena describes above (VNC is the basis of Apple's Desktop Sharing feature). Software developers have potentially-but-not-necessarily-live version control systems like subversion and git that allow loose collaboration by providing a wiki-like ability to fork any number of separate versions. Adobe Creative Suite offers a similar graphical version control tool they call Version Cue.

On the much lower-end, I recently phoned a friend from the store while shopping for luggage. He started pricing items on ebay while I examined the physical specimens. I suppose that could be automated too, but the potential variety of these low-end collaborations, which mix real-time, near real-time, and static collaborative protocols rapidly becomes endless. I think the challenge is to choose which information sources you want and manage the opportunity costs.

As an aside, wouldn't it be nice if we could get some of the radio spectrum back? Compare the tiny "throw-away" 2.4 GHz band we use for garage door openers and WiFi, to the ridiculous amounts of spectrum dedicated to dead protocols like television and LORAN.

-- Niels Olson (email)