|
CHWP A.4
|
|
Rockwell & Bradley, "Eye-ConTact"
|
3. How Eye-ConTact Deals with the Identified Limitations
How does Eye-ConTact deal with the limitations identified in the first
part of this paper?
3.1 Extending: Any module can be replaced,
as can the framework.
3.2 Recording: Visual maps record and show the logic
of one's exploration.
3.3 Sharing: Alternative frameworks allow
one to share results.
3.1 Extending with Modularity
Eye-ConTact deals with the issue of extension by encouraging modularity.
Not only does Eye-ConTact consist of a collection of modules, including
the framework module, but it also presents the user with a modular interface
paradigm. The user is encouraged to think of a text analysis project
as a flow of data from one module to another. Eye-ConTact is, in effect,
a tool for managing smaller modules and passing data from one to the other.
Eye-ConTact goes further in the support of modularity. It has built-in
tools for adding modules or repurposing existing code to act as modules.
The extension tools include:
-
A generic DOS process tool
If a DOS program performs a needed task, one can call it from within
Eye-ConTact. Eye-ConTact can even pass parameters to the program in certain
circumstances.
-
A module builder
We will offer a tool within Eye-ConTact for creating the interface
to modules written by others for Eye-Contact. The module builder allows
items to be added to the toolbar and simple forms to be built for
the control of the module.
-
Accessible framework design
Finally, the Eye-ConTact framework program is built in Visual Basic
in a fashion that allows it to be extended easily by those who are familiar
with Visual Basic. We hope that add-on modules in Visual Basic can eventually
be integrated into the system without having to consult the original code.
3.2 Recording with Maps
Eye-Contact deals with the problem of recording the logic of an exploration
by encouraging the user to lay out the fundamental steps in a visual environment.
The user creates the logic by dragging out icons and "connecting the dots".
This has the advantage of acting as both a record of the flow of choices
made and a synoptic description of that flow, which should make the
research easier to grasp. John Bradley experimented in TACT with
a macro language that could record activities and replay them. This had
the disadvantage that it was hard to "read" the macro file, let alone change
the process. Graphical representation shows the logic in a more intuitive
way. With the help of these records, users can build new projects, show
and exchange them, and, finally, create custom applications that hide the
logic.
Eye-ConTact also has an annotation tool that allows one to insert comments
on the Map and attach them to particular operations. This is to encourage
verbose and contextualized discussion of the project. Such annotations
are particularly useful when the Map is to be shared.
One outcome of the Eye-ConTact approach is that it forces the user to
map out the logic of his or her exploration before generating any results.
From one perspective this is a disadvantage. The novice who does not have
a research agenda, but is simply testing the tool, will have to make a
map before he or she can see anything. By contrast, interactive tools can
present the user with a default collection of displays (the word list,
the KWIC list, and a full text display) already to be clicked on. The user
can learn about text analysis by clicking on any of the displays and watching
what happens in the others. While Eye-ConTact does not offer this sort
of immediate feedback, it can be used to create such interactive tools.
If we think of Eye-ConTact as a visual programming tool, it can be used
by experts to create applications that are interactive and immediate. In
fact, in Eye-ConTact one can, in theory, create any other type of text
analysis tool.
One design issues that the Eye-ConTact prototype
has raised is the degree of detail to be shown on Map display. If the Map
is to show the logic of a project it needs to show more than generic icons
for operations whose details are hidden in forms. At the same time, there
are operations (especially displays) whose details would be too verbose
to be shown on the Map. What we need is to find a way to let the user spill
out the details and some of the resulting displays onto the Map so that
it can serve as a reasonably complete representation of the whole.
3.3 Sharing with Alternative Frameworks
With its visual programming paradigm, the Eye-ConTact Framework is only
one possible user interface. If the framework module which manages the
modules and the user interface is treated as one more replaceable module
then one can share applications with alternative frameworks that present
alternative user interfaces. The researcher should be able to create an
interactive package for the audience, once interesting results have been
mapped out. The audience could be students or scholars. Such interactive
publications would have the following features:
-
Protection of Intellectual Property: A research package that is
to be distributed widely should have built-in protection to make it awkward
for the original electronic text to be stripped out. If one wants to share
research based on texts that are not in the public domain one needs tools
that protect the owner's rights. If such protection existed in tools we
might be able to negotiate appropriate licenses from owners.
-
Appropriate Features: A research package that is designed to forefront
the research in an accessible fashion should have only the minimum features
needed for the research issue at hand. This means the packaging should
hide unnecessary features.
-
Interactivity: A research publication should invite interactive
exploration. Unlike the research development environment where one is encouraged
to map out a project in a disciplined fashion, a research publication should
first encourage exploration of the results. If research based on computer-assisted
text analysis has not made it out of the humanities computing ghetto it
is because our colleagues cannot try out what we have done. A research
publication should be like a research play-pen
where our colleagues can understand what we have achieved without having
to build everything afresh.
We envisage two types of publications that Eye-ConTact is being designed
to support:
-
Network Publications: An increasingly important medium for the publication
of research is the World Wide Web. Eye-ConTact, as it uses a relative of
TACTweb (a CGI version of TACT) should be capable of saving projects as
specialized CGI programs. One of the difficulties of using TACTweb today
is setting it up. We hope to adapt Eye-ConTact to allow a developer to
save an application for mounting on the web as a combination of HTML pages
and CGI modules. The HTML pages could then be expanded into a full on-line
paper with embedded forms to interact with the CGI program.
-
Stand-Alone Publications: Like any interpreted programming environment
Eye-ConTact will have a feature that will allow the developer to save a
project in a form where the Map will disappear and only the relevant forms
will be accessible to the user. This is how we envisage creating interactive
publications for student or collegial use. By replacing the Eye-ConTact
Framework with a run-time version, a researcher could distribute an application
while hiding the displays and features that are not needed for publication.
[Return to Table of contents] -- [Continue]