{Marco.Ronchetti, Diego.Feltrin, Vincenzo.Dandrea,
Giancarlo.Succi}@lii.unitn.it
Many programs are now in use since more than a decade. They control valuable information, but their user interface is still based on early technology, and their use is not considered user-friendly any more (if it ever was!). Often their code is not documented, and to put the hands in their code is a very expensive and error-prone task. It would therefore be desirable to be able to apply, possibly with little effort, some aesthetic surgery on them without risking to compromise their health. In a poster presented at the WWW'95 in Darmstadt, [ron95] we suggested that WWW can provide safe and relatively inexpensive means to build a better user interface to them.
We built an interface for such an application: an information system for all the public libraries of a small region in northern Italy, well known for its beautiful mountains and ski resorts. The CBT system (Catalogo Bibliografico Trentino) was established one decade ago on a proprietary systems to serve all libraries of the Trento Province (6000 Kmq), using the Dobis-Libis system. IBM 3270 terminals were placed in the civic libraries (even in the smallest villages) and connected through an X25 network. Libraries of the local University, and research centers also belong to this system. The CBT system is also reachable via telnet through a gateway (which converts VT100 emulation in the 3270 protocol). Of course, the (character based) user interface remains the one designed one decade ago, and typically users find the system rather annoying to use, especially through the telnet connection.
We therefore built a translator which on one side establishes (and keeps alive) a permanent connection with the CBT system through some of the available telnet ports, and on the other side responds to CGI scripts invoked through the HTTP server. The system is now in use, and received thankful attention from frustrated users of the original system.
Aim of our contribution to the workshop is to share the lessons we learned in developing our interface. We will sketch here a short summary of them.
A limited amount of reverse engineering was therefore necessary: we reconstructed the users requirements in part from the (very terse) user manual, and mostly from an exhaustive examination the behaviour of the original application. Of course, one can imagine cases where some rare behaviours (like exception raising in particular conditions) cannot be explored, and therefore the investigation of the original application cannot be exhaustive. In such cases the translator would misbehave in those rare cases, which suggests some particular care in adopting this approach when critical or sensitive data are treated.
Besides the user requirements, the reverse engineering on the original application allows to extract the basic functionality provided. The user requirements are then used to define the interface toward the user (i.e. the HTML pages, which can be either static or generated on the fly: we found necessary to use a combination of the two) while the specification of the functionality is used to code the translator.
Having performed the analysis mentioned at the previous point, we realized that we has conquered a new degree freedom: we had a list of basic functionality, which we could now consider as LEGO&trademark; building blocks. We had the possibility to build a new interface which not only masked the painful aspects of the original interface, but could also offer new services achieved as composition of the basic functions.
To better illustrate this point, we describe a trivial example. The original CBT system divides the libraries into two classes: "regular libraries", which includes mostly the civic libraries, and "special libraries" which regards university and research center libraries. When a query is performed, the user has to choose one of the two classes: to extend the query to the other class one has to repeat the whole process. It looks to us like a badly designed interface, which we were able to fix in our interface by using the available building blocks. We offer to the user the possibility to choose "both classes": in such case we perform both queries to the system, we collect and format in a uniform way the results and offer to the user the full answer. The whole process is now transparent to the user, who does not even need to know about the existence of the two classes. In fact, we could even have decided to completely drop the distinction between classes on the user's side, since we think that such distinction is rather artificial: in the end we left it as an option, in case it made sense for some user.
In addition, it is conceivable to seemlessly extend the CBT system on a local basis. A library could decide to add information about (a subset) of its books. For instance, an image of the table of contents could be stored on a local machine. The translator could be easily modified so as to integrate the CBT system with queries to a local database, providing the available additional information. In the same way any legacy system could be integrated at low cost with new information (which can use state-of-the-art technology like for instance multimedia)
A corollary of the above statement is that the network is not necessary if the goal is just to make a better interface: one could install an HTTP server on an isolated, local machine for the sake of enabling local users to use a new interface to the old app.
At least three mainstreams can be followed, which differ for the way the state is saved: in the first case it is responsibility of the original app, in the second of the translator, in the third the state is saved at the user's site.
The first approach spawns a new copy of the original app for each user: the translator must identify the user and send her/his requests to the correct copy of the app. Backtracking is a problem: it must be recognized, and errors must be sent back to the user. There can be problems with dangling sessions, when the user abandons the interactions (maybe due to network problems). A timeout can gracefully close such orphan sessions.
The second approach and the third approaches can be used if it is easy to rebuild a state, i.e. if, given a state, a path is known for reaching it using a reasonable amount of resources (e.g. the state can be reached in a short time, without incurring in additional expenses like repeating expensive operations). In such case, once the translator knows the requested state, it can drive the app to that state before applying the operation requested by the user. In the second approach the translator stores and retrieves the state associated to the user. As in the previous case it is therefore necessary to identify the user, and backtracking is again a problem. In the CBT system we used the third approach: the state is coded in an invisible part of the page sent back to the user. When the user replies, the translator can read in the reply the user's state. In such case backtracking is no problem, since each page carries consistent information about the state.
To close this short section, which would need a much deeper discussion which we plan to present elsewhere, we say that whenever possible one should use the last solution, which does not require identification and allows for backtracking. The second solution should be used when the state has such a complex representation that it is not feasible to send it back and forth through the net. Finally, the first solution should be attempted only if the original application does not allow to reach an arbitrary state using a reasonable amount of resources.