Eye-ConTact: Design

Rockwell & Bradley, "Eye-ConTact"

2. The Eye-ConTact Design

The design philosophy of Eye-ConTact that grew out of TACT's limitations can be summarized as follows:

2.1 It is a visual programming environment.
2.2 It has a modular architecture.
2.3 Any component can be replaced.
2.4 It may be slower than simple tools.

2.1 Visual Programming

Eye-ConTact is first and foremost a prototype of a visual programming environment in which one creates text analysis applications. It is, in a sense, a thought piece meant to illustrate some of the ideas it implements, and to provoke further thought about these issues.

Eye-ConTact is a domain-specific visual programming environment in which one creates text analysis applications. Visual programming environments need to be distinguished from program visualizations and data visualizations. Brad Myers in "Taxonomies of Visual Programming and Program Visualization" nicely distinguishes the two, defining visual programming as "any system that allows the user to specify a program in a two(or more)dimensional fashion" (Myers 1990: 98). By contrast program visualization is a graphical representation of aspects of a program that may have been written in a conventional text programming language. Data visualization has nothing to do with the program, but rather has to do with the information managed by a program. A graph produced by a spreadsheet would be an example of a data visualization - it offers a view of the data manipulated by the program, rather than illustrating some aspect of the program. We will not discuss here the variety of such visual programming and visualization tools used in the sciences (see Price 1993 for a taxonomy of software visualization).

It is easy to confuse visual programming environments with data visualization because several examples of scientific visualization programs that produce data visualizations are at the same time themselves visual programming environments. For example, IRIS Explorer, which runs on Silicon Graphics workstations, is an environment in which the user creates maps that show how data should be piped, transformed and eventually graphed. (The reader familiar with this and similar programs will appreciate how Eye-ConTact is an attempt to explore the application of this model to textual visualization.) These maps are visual programs - they describe a complex process that the user wants performed on his or her data. What is confusing is that the final results of typical Explorer programs are data visualizations that graphically show some aspect of the data. Thus a map might show how data from a flight simulation would be processed in order to produce a graphic representing the air-flow over the wing of the simulation. The map is a visual program and the air-flow image is a data visualization. Eye-ConTact likewise has maps that are visual programs that can be run and could produce data visualizations.

Unlike general purpose visual programming environments like Prograph, Eye-ConTact is a domain-specific environment; it has been designed for creating programs in a specific domain, i.e. text analysis. There have been questions raised about the application of visual programming. It was assumed that visual programming would make programming accessible to everyone, but M. Petre and colleagues (Petre & Green 1993 and Petre 1995), among others, have suggested that visual programming benefits the domain expert more than the novice. Visual programming, like textual programming, is more effective when the users have acquired visual "reading" skills for the graphical conventions of the domain. A picture might be worth a thousand words, but without conventions and experienced viewers the same picture isn't worth the same thousand words. While general purpose visual programming may not be terribly efficient, domain-specific visual programming does have promise, precisely because of the restricted domain (See Raymond 1991). In a specific domain there is likely to be an informal consensus about the operations needed and the domain expertise that can be enhanced in a visual programming environment. Graphical elements, rather than being so abstract that they cannot be understood, can represent the common, conceptually simple operations of the domain. The expertise of those working in the domain can be harnessed by providing them with a programming tool aimed directly at their work. Ideally a domain-specific programming environment should hide the mysteries of programming and present the expert in the domain with operations that correspond to their research. This is the promise of a domain-specific environment such as Eye-ConTact - it should allow those interested in text-analysis to build applications that correspond to their research questions without having to master a new discipline.

What follows is a narrative of how you might use Eye-ConTact:

When you run Eye-ConTact it opens a Toolbox and a Map window.

To create an application with which to study a text, you click on icons in the Toolbox and drop them on the Map to represent the operations you want done.

To connect the operations you click on the (red) output box of an icon and then click on the (blue) input box of the icon to which you want to connect it. After laying out an application the Map might look like this (without the labels):

You then double-click on the operation icons which need to be fed information. This opens the form for that operation. Here is a form for specifying the text database to open:

Once all the relevant information has been entered, you run the application by clicking on the Run & Stop button in the toolbox. One can set the program to run continuously, even while you are editing the Map. When that is the case, any time you make a significant change, the program reruns the relevant modules.
If you find results that are interesting you can annotate the Map and save it. A saved Map keeps all the settings so that running the application again will deliver the same results.

2.2 Eye-ConTact Architecture

The underlying architecture is two-fold:

The Eye-ConTact environment is made up of modules and files. Specifically:

A Framework module which is controls the user interface. In Eye-ConTact as it stands there is only one framework module, a visual programming environment called the Eye-ConTact Framework. We anticipate two others to provide publication interfaces.
Process modules which process data. In the present version of Eye-ConTact the most important process module is BTACT, a variant of the TACTweb text engine.
Files used by Eye-ConTact or produced by Eye-ConTact. In particular there is the Map file which saves a project, the TDB files used by BTACT, and the temporary files created by the various processes.

2.3 Advantages

Some of the advantages of this design are:

You can replace any module as your project progresses, including the framework module.
For those who already have functioning code, you can adapt your programs for use in a framework like Eye-ConTact.
A distributed community of developers can expand such an environment as long as they agree on an inter-process communication protocol and data formats.

2.4 Disadvantages

Some of the disadvantages are:

Such an environment is slower than a single well-designed program.
You can end up with a mess of uncooperative modules that would be even less accessible and more frustrating.
Without communication and data standards a distributed community of developers could end up with incompatible modules.

[Return to Table of contents] -- [Continue]