In most general purpose computer systems there is a wide variety of software available to users. Such software is usually provided in one of three organisational forms - routines in a library; collections of related functions grouped in a package with a common interface; independent programs called through operating system commands. This interdependent tripartite structure creates problems for non-sophisticated users as it involves different levels of user interface complexity.At the routine level a user must write programs in an appropriate host programming language to use the software. If he wishes to use a selection of routines written in incompatible languages then he may have to familiarise himself with more than one host language. In each language he must be aware of the calling conventions for routines, the possible representations of various types of data, the methods of passing parameters and the ways of inputting and outputting data to and from the external environment. This type of interface occurs with libraries like NAG and IMSL. In the case of packages the imperative user interface is usually somewhat simpler, consisting essentially of a name identifying the function required and some associated parameters which identify variables, labels, files, options, control and code values, etc as appropriate. However, function calls of this form must normally be preceded by a non-trivial amount of declarative and other "red tape" information expressed in the package interface language. Also, package environments can be restrictive in that the user is constrained to the types of data structure and analysis supported by the chosen package unless he is prepared to write programs to transform his data for other packages or to analyse it independently. SPSS is typical of this kind of package. When software facilities are provided at the program level, the user interface often consists simply of one-line program invocation commands written in the local operating system's command language, with program options and data files identified by command parameters. Common examples of such facilities are sort and archiving programs. A program level interface becomes even simpler, and at the same time more powerful, if command sequences can be formed into parameterised command procedures and if programs are enabled to conmlunicate directly with one another without the need for explicit intermediate files. In the latter type of environment the application software user generally finds that there are analytic program tools available to meet only some of his requirements. Consequently he has to embrace either or both of the other levels in addition in order to increase the analytic power available to him. Transfer between levels is not easily accomplished in most systems as facilities do not normally exist to help the user move data between levels. This difficulty comes on top of the obvious problem of having to master more than one interface and more than one level of complexity. In the SENSE project (11), which is funded by the U.K. Social Science Research Council, we are creating a prototype computing environment for social science researchers which can accommodate non-sophisticated users. The aim is to provide an integrated environment where such users will have a complete range of application software available (packages, routines and programs) through a single, simple user interface. We believe that this can be achieved by exploiting and extending the concept of software tools propounded by Kernighan and Plauger (19), so that as far as possible all software can be used through a program level interface, with its attendant advantages. Following Kernighan and Plauger we believe that software tools "can be used to create a comfortable and effective interface to existing programs", as well as providing an ideal model for the structuring of brand new application software. This paper will consider various aspects of the initial design of the SENSE software environment with particular reference to the importance of software tools in that design.
Read full abstract