RIDING THE COMMUNICATIOS WAVE -- PART II 



The package can be done in segments. Many of them will serve as useful stand 
alone utilities.



Scanner Module. OS/2 scanning manager. I guess support for different scanners 
through library files. As a minimum HPScanJet II with ADF support. Easily con
figured: B&W or Color (4, 16, 256, etc.). Resolution. Contrast. Page Size, Etc. 
Standard configurations stored and selectable. Perhaps a preview mode to auto-adjust. 
Store documents in multi-page formats -- TIFF F and/or DCX. Auto-collate fronts 
and backs. Prompt for additional pages if ADF empty. Background operation.

  

Fax Module. Perhaps based on Keller Group (FaxWorks) technology. Better control 
interface: Easier scheduling. Fax forwarding. Drag and drop graphics and EPS files. 
Database management of archives. Frankly, I would like to see an In-basket object 
on the desktop and little fax objects representing new faxes. 



DataComm Module. Send data files by modem, ISDN or other means with Fax 
analogy. Pick recipient out of phonebook (or enter manually) and launch transfer. 
Automatic negotiation of upload into proper mailbox. Also act as recipient for 
incoming mail or files. Free form mailboxes. Any data type can be sent -- sound, 
graphic, data file or email type notes. They can be mixed and matched. Files 
would be encased in an envelop which would, among ather things, tell the 
receiving system how to view, listen to or display each file. Automatic 
compression/decompression and public key encryption and electronic signatures and 
authenticity verification. Built-in ability to deliver electronically signed receipt with 
verifiable time stamp and verification/validation of file contents. Ability to adapt to 
different mail protocols if the receiving or sending system uses another.



BBS Module. Business oriented file and data sharing, conferencing, email, etc, system 
built around a standard virtual Desktop. Rather like Prodigy, without the kitch. 
Object oriented. Should look and feel more like a streamlined. WPS with icons 
for processes and files, etc. Drag and Drop. Standard interface built into both 
recipient and sender's module. Customization data transferred at login. Minimum need 
to transmit graphics data. Mostly just location data for objects that move or 
change. Possible gateway to LAN and/or Internet.



Terminal Module. Relative of Data Module but for attended transfer or mail ses
sions, BBS access, Internet access or remote computing on another system.. Given the 
number of different protocols and environments, this might end up being a simple 
shell that loads in detailed configuration modules depending on whether one was 
accessing a BBS, Compuserve, Internet, Prodigy (perhaps), etc.



Editing Modules. Graphics and text editors to read, view, edit and save/send 
received data. More functionality than FaxWorks' text and bitmap editors, but the 
same ease of use. Making them separate increases their sophistication and allows them 
to deal with data outside of the Fax environment.



Voicemail Module with call transfer, forwarding, multiple mailboxes, etc. Ability to 
attach files or faxes to voice mail.



Line Attendant. monitor incoming lines for call type. Launch proper application. 
Select proper channel for outgoing calls. If normal phone lines are being 
employed for data or conferencing, coordinate the optional use of multiple lines to 
increase bandwidth. (Would mean some sort of packet protocol, I suppose.)



Conferencing modules. Perhaps one would open a window representing each of the 
locations logged onto the conference. The window would communicate with the 
remote location to see what resources were being made available. These would be 
represented by objects -- printer, monitor, fax, etc. The local system (each would 
see itself as local, of course) would show a cursor under local control and 
hand objects representing the cursors of the other parties. One could transmit docu
ments one ones own work area to others by drag and drop. One could also 
elect to view the others screen, to watch changes being made to a document. One 
could be given control of the remote system to make changes oneself. Drag and 
drop to the remote monitor would not transmit the data, it would transmit picture 
of the document or data at screen resolution. 



Video module. Video conferencing module.





These modules would be integrated under the standard GUI. So, for example, one 
could scan a document with auto-collation and have it print. Or have it transmit 
to another location via ISDN or modem.. If real time conferencing was going on, 
the receiving utility could be instructed to print it immediately as it was being 
received. (The two parties would configure their systems to allow simultaneous print
ing at the instruction of the other. Then as they talked, perhaps over an ISDN 
channel, the data could be sent, even bidirectionally, from system to system. In 
real time.) Or one could scan and fax. Or send a word processing document or 
ASCII file.



There could be an overriding phonebook which would automatically select the des
ignated mode of transmission for each recipient. So if John Doe1 has only fax, it 
would convert everything to fax. If he had an ISDN connection, it would send it 
as data. Or it might send it via a network or the Internet or Compurserve, or 
whatever.



An aside on video conferencing: This will sound like a strange idea. And it 
might be. I realize that people believe in video conferencing because of the hid
den cues and body language, etc. I agree, but am not sure that even an ISDN 
connection will allow enough of these to get through to justify the bandwidth 
employed. My theory is that we are hardwired to interact with things with faces 
that talk as human. This is why puppets and ventriloquist dummies work so well. 
Why not represent conferees with line art? The basic information would be 
exchanged at startup. The camera at each station would be used to inform the 
local computer of changes in gross posture and facial expression. Animation data 
would be sent to remote systems to modify the cartoon figures represented there. It 
might be easier to do the massive local computing with minimal data transmission 
than to stuff real time video across the connection, whatever it is. I believe that 
we would find the results more pleasing subjectively than a poor video image. It 
would also create a whole new industry. Imagine: in your software/hardware box 
you would get a coupon for a digital caricature -- and a portfolio of styles to 
choose from.



Chris Barr

CIS:   75320,2055

Internet:  cbarr@pipeline.com



 