I will first concentrate on the hardest problem in scientific communication. The problem is simple, close, one-to-one, communication between two or more scientists in a tight research collaboration: It is easy to collaborate with somebody who can walk into your office, and work through a problem on a blackboard with you, or who can sit down at a table and circle important points on a research publication. Now put your colleague on the other end of a phone, or e-mail discussion. Any of us who have tried the latter know that things suddenly become very difficult. It is very hard to visualize the fine details of any mathematical science in your head, especially if those details are coming from somebody else's head. Even if one is lucky, and has a copy of a common research paper (maybe sent via electronic mail), it takes a long time to see exactly what point a researcher is looking at. Collaboration becomes much like discussing research with a journal referee--it can be productive, but most time is spent in trying to understand what each other is trying to get at!
We need visual input for scientific communication: mathematical sciences are, of course, communicated via mathematics, and our language for mathematics is a highly visual one. A simple equation like
takes a while to explain without vision, but is almost immediately understood when written down. It can then be easily commented on, with a simple circling of a problematic term. This is quite different from most communication outside the mathematical sciences, where points can be argued out in normal spoken language. In this sense, mathematical science communication is far more like discussing art than discussing, say, politics. We thus need our blackboards, or our pieces of paper.
Of course, there are computer systems that provide us with electronic versions of blackboards, and even allow several researchers from anywhere in the world to share those blackboards. The big problem is that the software is highly specialized, and often needs expert installation. It is also, because of that specialization, very difficult to tailor it to exactly the needs of a particular application (for instance, a specific research institute). Not many scientists are willing to take the time to install one copy of a collaborative software system, let alone multiple versions for different applications!
The primary advantage of Java is that it actually provides us with a way to make designing collaboration systems easy. Furthermore, it makes it extremely easy to use those systems, with almost no knowledge of computers. If one has any piece of software written in Java, one simply has to put a reference to it in a web page (using an extension to the HTML language). From the point of view of a scientist, by simply viewing that page via an appropriate web browser (like the new version of NetScape), the program is automatically installed onto their computer. Once automatically installed, it starts to run. The scientist does not need to understand how to install it, how to set it up, or even how to start it. That is all done for them by the Web. So, in principle, one can write the software needed for scientific collaboration, place it on a web page, and it is then immediately available for scientists to use: Give your colleague the URL of the page, and, within minutes, they can be running exactly the same software as you, as long as they know how to use a simple point-and-click browser like NetScape.
I have actually set up one of these systems, The Virtual Institute Network (VIN). VIN has been designed to meet specific needs in a multidisciplinary experimental mathematics collaboration I am involved in, and also to allow fellow general relativity researchers to communicate with me. It provides a simple window, through which users can chat, as can be seen in this image:
The user simply gets to this window by following normal links on the web (see the client itself). It is simply a region in a normal web page, much like an inlined image. Each group of users can form their own channel, thus providing for private discussion groups. It is even possible to have more than one web page containing a connection to VIN, with each page being automatically connected to a different channel. Thus one can direct fellow researchers to a discussion area on a particular field. This has already been done for the General Relativity community, through the international HyperSpace web system.
The client uses the power of executable content to make the user interface as natural as possible. Above the communication window, he finds a row of buttons that provide, on his own browser, various important functions. These buttons provide a simple interface to the more sophisticated properties of the downloaded Java program. The most important is the Blackboard button. It starts up the online blackboard, as shown in the next image.
This online blackboard can be used by everybody on the channel. A large range of images can be displayed on it, and those images can then be drawn on. The result is a collaborative annotation system. The simple act of drawing, with the need to constantly interact with the user, and update the screen, is significantly beyond the capabilities of normal server-based programs. The software then provides a mechanism to store the results of the collaboration.
The ease-of-use of VIN is common to executable content systems: a software designer can tailor the application to the users of that application, rather than being confined by the fixed constraints of second-generation, static content, internet services like the pre- Java Web. The browser itself is now something that the web programmer can program, and thus the communication between the user and the network, for even the most computer illiterate user, becomes almost unlimited. We have been able to place a piece of data on the network, the information being ``at this location is located a Virtual Institute Network server'' and then, at the same time, have provided the tools needed to connect and use that server. This is an example of a web object.
There is another significant capability of the VIN `client', as it is called: Java is a fully web-aware language, and thus is has been easy to program the client to be able to browse the web itself. Simply hitting the Browse button, and typing in a URL, allows any web document to be brought up on the computers of all the researchers collaborating on the channel. Thus the VIN client itself is a full, collaborative, web browser. Users of the system are not restricted to using just the capabilities programmed into the client by me, but any capability available on the web, including other Java applications. For instance, the next image is a picture taken of a moving animation generated, via a different program, using Java, simply displayed on the channel (with an earlier version of the software).
Notice that, here, we are displaying data in a way that does not have a corresponding protocol defined on the web: there is a well-defined protocol for images on a web page, but not for animations. Without executable content, one is forced to bring up the animation using a helper application. Once more, the animation is a web object, stored as a group of images, and a tool for displaying those images.
The browse button can also bring up other helper applications, if they are available to the specialists on the channel, for instance, Geomview, as shown in the next image:
I would again stress that `installing' this software is as easy as visiting a certain web page. The VIN client then immediately starts up, independent of whether the user is looking at the page with a fully-equipped Sun workstation, or a basic Windows 95 PC, or another computer using the latest version of NetScape. It can be seen, therefore, that third-generation web pages with executable content provides a greatly expanded capability over simple web pages containing second-generation static web information.
