User Interface Management Systems for Engineering Applications

Volume 11, (1992) number 2, 113-129

User Interface Management Systems for Engineering Applications

Lakshmi Sastry

Rutherford Appleton Laboratory, Chilton, Didcot, Oxfordshire OX1 1 0QX, UK

Abstract Essential features of a User Interface Management System (UIMS) from the perspective of engineering applications’ user interface development are described. Three commercially available UIMS are validated against this set of essential features and the results of such a categorised evaluation are reported. The proliferation of user interface design tools necessitated an initialfiltering to select these tools on the basis of their availability on a wide range of platforms currently used by engineers, supplier support for the product and the prototyping tools the UIMS offer. Graphic Modelling System (GMS), TeleUSE and USEIT were selected for their potential utility to engineering applications.

An earlier version of this paper was presented at the 1991 European X User Group Annual Conference held at Queens’ College, Cambridge, UK.

This comparative evaluation is compiled on behalf of the UK Science and Engineering Research Council, for the benefit of the UK academic engineering research community.

Key words: User Interface Management Systems.

1. Introduction ments in terms of the functionality expected of high level

A perennial problem encountered by researchers wishing to utilise a user interface development tool is the selection of the most suitable of such tools for their application. At the very outset, this decision entails detailed knowledge of the functional utilities offered by each class of interface development support tool. This knowledge is essential to match the requirements of an application’s interaction semantics to the interface design that can be developed using a particular tools. This requirement matching exercise demands the application developer to identify and break down the complete application interaction into individual user level tasks at a very early stage. Adopting such a detailed interface design stage is probably most contrary to the traditional working practices of engineering researchers and may deter the exploitation of emerging interface technologies for engineering software development. However, much of the user-application interactions are common to most, if not all, engineering

interface development tools. Beyond the identification of the interaction require-

ments, there still remains the problem of making a choice among competing genre of software tools, in such a way that it minimises any eventual design trade-off. The best way to make this decision is to gain hands-on experience on a range of available software systems. However, the financial cost, manpower and time scales involved in gaining first-hand information on every available software system are generally beyond the scope of academic research projects. The Engineering Board of the UK Science and Engineering Research Council (SERC) takes an active role in responding to such information requirements of the UK academic engineering research community. SERC supports periodical survey and evaluation of interface design software packages (such as User Interface Management Systems) under the Engineering Applications Support Environment (EASE) programme.

applications and a generalisation of interaction requirements can be effectively made. This paper primarily aims to identify the interaction requirements common to engineering applications and seeks to define those require-

Under the auspices of this programme, a “snap shot in time” of User Interface Management Systems (UIMS) was taken. Three commercial products were short-listed for further evaluation. The three products selected were

114 L. Sastry / UIMS for Engineering Applications

USEIT (version 1.1) from UNIRAS Ltd, TeleUSE masking a lot of application details from the end-user. (version 1.1) from TeleLOGIC and Graphic Modelling First-time users may find UIMS’ support functionality System (version 3.0 g) from Sherrill-Lubinski Corpor- ideal in aiding the rapid adoption of state-of-the-art ation. Each system was selected on the basis that it interface methodologies. provided, at the least, one major functionality/feature necessary for engineering applications’ user interface development. For instance, USEIT is designed to run on both terminals and workstations and is capable of supporting batch and interactive modes, GMS supports object oriented real-time animation and TeleUSE provides a sophisticated OSF/Motif based interface development environment. All these systems also meet other initial selection criteria, such as the suppliers’ commitment to the product and portability issues which are described later.

The evaluation methodology of building a benchmark application was adopted’ in such a way that it enabled the benchmarking experience to be meaningfully interpreted in terms of the UIMS requirement criteria. Hence, at a secondary level, this paper describes the results of applying the definitions of requirement criteria to actual evaluations of commercially available UIMS short-listed through the product survey.

These assessments were carried out on behalf of the SERC at its Rutherford Appleton Laboratory. This paper’s intended audience are application developers wishing to use a UIMS for their interface development. The UIMS discussed here may evolve as software products or may even be superseded by more sophisticated products. However, the evaluation criteria described are comprehensive and fundamental to all interactive interface development tools and as such it is hoped that application developers wishing to make a discerning choice of UIMS will find it useful.

In the next section a general definition of a UIMS is provided in terms of its functionality, or more accurately, in terms of its expected functionality, in supporting engineering applications interface development. This is followed by the detailed description of assessment criteria. Brief overviews of each of the three software tools are provided in Section 3. The results of evaluating each system against the assessment features are reported in Section 4. Finally, a summary of results and conclusions is provided.

It is essential to emphasise that the requirements are looked at in terms of existing standards and methodologies.

1.1. User Interface Management Systems

UIMS are user interface development tools that provide support for building consistent presentation and interaction components of a user interface to an application. UIMS mediate between the user and the application

The general architecture of UIMS comprises a graphical user interface presentation component, a fully integrated dialogue development environment and an application interface module [Figure 1], as described by Pfaff2. UIMS also provide good run-time support for the executing application. The presentation component controls the graphical part of a user interface and is dependent on software subtools such as an underlying graphics system. Generally the dialogue development and control module consists of a high level interaction dialogue specification language with its compiler.

Information such as application specific data structures, application procedures available to the user interface via the callbacks and the constraints, if any, applicable to the callbacks are specified in the application interface module. Together these components of a UIMS support a variety of interface development tasks such as rapid prototyping, testing, modification of initial design and evaluation. The character of a UIMS depends on the level of support its components offer to non-programmer interface designers. The principal characteristics of the interface development supported by UIMS are :

All aspects of an application’s interface such as its layout design and dialogue specification can be developed as separate reusable modules.

The application is totally separated from its user interface. (This allows the independent development of both modules, possibly by an application programmer and a non-programmer interface designer respectively.)

It is possible to test and modify the user interface without any application code. (This functionality eliminates the need to recompile the complete application during the iterative interface development cycle.)

There is effective support for group working on complex interface development.

Unlike toolkits, UIMS themselves are interactive systems whose end-users are application programmers and/or interface designers. Hence the onus is on the system to provide a transparent and well structured interface to itself. The UIMS should aid the learning process of the interface developer as well as positively influence the quality of interfaces developed using it.

1.2. Engineering Applications and UIMS

Often in the past the end-users’ familiarity with the

L. Sastry / UIMS for Engineering Applications 115

Figure 1 : Logical Model of a UIMS.

application and the system were taken for granted, particularly so for domain specific applications. Hence, minimal effort was spent on the application’s interface. However, this traditional approach to interface development as an after-thought is changing rapidly. This change of attitude towards application interfaces is due to :

out on several of the then available UIMS products. The primary objective was to find the most suitable UIMS for engineering application user interface development. Fol- lowing that recommendation three products Tiger [Team Engineering, Inc., Santa Cruz, CA, USA, suppliers of Tiger ceased trading in 1989], Blox [Template Graphics Software Inc., San Diego, CA, USA, no longer market

the emergence of new ideas on human-computer interactions that relate the efficiency and productivity of end-users of an application’s interface,

the advent of hardware/software tools that enable the practice of such ideas.

The development of UIMS is, in part, a response to address the provision of a high level, device independent, interactive interface development tool that extends the facilities afforded by advances in the underlying hardware and graphics software. Such an integrated interface development support tool is of particular importance to engineering applications, especially to existing “dusty deck ” FORTRAN applications. Enhancing the interfaces of old FORTRAN applications to incorporate modern interaction methodologies will thereby ensure a new lease of life for the applications. From this perspective, the essential requirements of any UIMS should be :

Blox] and PA SET [PA SET is available as an un- supported product from SERC free of charge to acade- mics] were evaluated. That first assessment exercise reported by Prime3 concluded that none of the products considered were suitable for the purpose mentioned above. But new UIMS products such as Open Dialogue (originally from Apollo Computers Inc. [Open Dialogue copyright now belongs to Hewlett Packard Ltd.]) were just about to be made available and hence a new product survey was carried out during 1990.

Some of the important initial selection criteria used for shortlisting were that the selected product should :

run on the X Window System [X Window System is a trade mark of MIT];

be available on several platforms and help develop device independent software ;

allow the separation of the interface from the application ;

availability on a range of platforms; facilitate the rapid prototyping of an application’s

support for the complete retention of the algorithmic parts of an existing application; product is well supported.

codeless interface layout development ;

user interface (UI);

Where graphical user interaction is concerned, commercial UIMS are yet to come into their own, inde-

such as GKS (Graphical Kernel System) and PHIGS pendent of the influence from current graphics standards

part with the new interface;

the ability to link a variety of application languages such as FORTRAN and C.

(Programmers’ Hierarchical Interactive Graphics Sys- tem). While the main focus of state-of-the-art research into UIMS is on the move away from input limitations

1.3. Assessment History imposed on UIMS by the underlying graphics sub- systems, this is, as yet, of primary interest only to UIMS

The 1987 workshop on UIMS held at Glasgow Uni- versity, UK, recommended that assessments be carried

experts. Complex FORTRAN based engineering applications are still being used and developed with minimal user

complete support for interfacing the algorithmic


interface. For such applications, their developers and end-users, there is an immediate need for a stable and supported UIMS that would enable them to implement state-of-the-art user interface which would also support currently prevalent graphics standards and input concepts that the target audience are familiar with4.

Hence, an important distinction has to be made by the reader that the requirement criteria here are drawn in terms of essential FORTRAN-based engineering applications’ user interface needs rather than to draw the desirable features or architecture of a UIMS per se.

1.4. Evaluation Methodology

The common approach to the evaluation of an interface development tool is qualitative, see Hix5. The singular exception to this approach is Hix’s6 recent attempt at quantifying such evaluations. The evaluation methodology here is based on the implementation of a small interactive graphics application using the software under consideration and interpreting the resulting experience in terms of the assessment criteria. The interaction technique requirements of the benchmark application are fundamental to all engineering applications.

The rest of this paper is designed in three parts. The first part describes each assessment criterion. Then a brief overview of each software system is given. Finally, the level at which each system meets the expectations of an application programmer/interface designer is described.

[Note : Throughout this paper, the term “tool” is interchangeably used to refer to either the complete software package or to a particular modular part con- tained within that software (e.g. a layout editor). The term “User Interface Design Environment (UIDE) tool ” is used to denote any general user interface development software system. This term encompasses a wide variety of systems from basic toolkits to UIMS. If an individual criterion is more specific to a UIMS, the term UIMS is used for emphasis. “Interface” refers to user interface unless explicitly referred otherwise.]

2. Assessment Criteria

This section describes all the assessment criteria which are grouped into ten broad categories some of which contain sub-categories. The aim here is to recapture UIMS requirement expectations into working definitions so that the results of a benchmarking exercise can be interpreted in terms of these characteristics.

2.1. Automatic UI Design and Rapid Prototyping

Ideally, the user interface designer should be required to describe only the Applications’ Logical Interaction Speci-

fication (ALIS) in textual form. There should be support within the UIMS to process ALIS to produce an Application Presentation Interaction Specification (APIS). The UIMS should use the APIS to prototype several styles of the presentation component of a user interface (layout) and a prototype of the dialogue component. There should also be an interactive interface for the programmer to view and tailor any attribute of the presented prototype to customise the final user interface design. Additionally, for applications that require application specific user interface objects (e.g. CAD application) such as dials and meters, there should be a graphical editor to design and add such objects to the user interface specification.

2.2. Semantic Feedback

The general UIMS architectural expectation is that the lexical and syntactical feedback are handled by the UIMS leaving the application to handle the semantic feedback. Hence the necessity of building a large amount of application knowledge inside the UIMS is avoided. However there are many culturally derived semantic associations that can be built into the UIMS and can be functional from within the user interface. Semantic feedback, such as colour coded warnings, are used to draw the end-users’ attention to state changes during application execution and can be part of the interface rather than the application. Process control applications such as a monitoring system for a chemical plant will benefit from such a rapid-response semantic feedback. There should be support within the UIMS to build such semantics naturally into the user interface.

2.3. Interaction Technique and Feedback

The interaction tasks fundamental to all types of interactive graphics applications are selection, positioning, orientation, path generation, quantifying and specification of text, Foley et al.7. Each of these interaction tasks is performed using different interaction techniques which are dependent on the hardware and software. For instance, the interaction techniques applicable for the command selection task can be selection of that command from a menu with a cursor or a light pen or voice input or the name (text string) of the command typed via the keyboard or input via a programmed key or macro. Similarly, direct manipulation of a graphical object is a preferred interaction technique, in this instance for orientating that object on the screen. If the input is location information (a point in the graphics window), a mouse click at the appropriate location on the screen is a common interaction technique.

A UIMS should support the end-user to interact with the system and the application using all the appropriate


interaction techniques feasible with the hardware system. 2.5.1. UI and Application Separation For instance, the tool should automatically allow the use of either the mouse or the keyboard or use them interchangeably ; the task of recognising which of these input devices is being used should be automatic. The UIDE tool should also provide the interface designer with a rich set of interaction primitives such as rubber banding and dragging in order to support all types of input echoing.

2.4. User Interface Customisability and Extensibility

User interface customising is considered here at two levels.

At the primary level, tailorability refers to the support afforded by the software tool for the development of “house style ” interactions which companies wish to preserve across the range of their applications. Where the existing mechanisms within the UIMS are inadequate for the UI developer’s requirement, there should be support for the easy extension of the existing interface functionality of the UIMS. The flexibility afforded by a UIMS for customising an interface to the desired look and feel and functionality is a measure of its product maturity. It is imperative that the UIMS own preferred style of interaction does not inhibit the structure of any dialogue the programmer wishes to develop. On the contrary, the tools should support dialogue extension to accommodate the programmer’s requirements. There should be support for style independent output by the application as well. This aspect is elaborated in the section discussing the UIDE tools’ graphics subsystem.

At a secondary level, user tailorability refers to the support provided by the UIDE tool to the end-user for customising a presented application interface, at the single end-user level. In general, current generations of UIDE tools support the end-user in tailoring a UI layout, customising keys and aliases so long as the individual user has access to the UIDE tools’ interface builders. In such cases, end-user customising reduces to one of invoking the interface builder of the software tool to alter the interface and retain it as a private version. Alter- natively, the interface designer can include routines that elicit end-user preferences and integrate them into the interface at run-time.

2.5. Relationship Between the User Interface and Application

The sub-criteria discussed here included UI and application separation, the nature of the run-time control and the UIMS communication handling.

The predominant utility of a UIMS is to separate an application from its user interface so that the two can be separately and simultaneously developed and tested, easily maintained and updated. Such a separation of an application from its interface will ensure the portability of the application across different user interfaces and systems. As sophisticated UIDE tools become available, a completely separated interface of an application can be easily updated to take advantage of the advancements in interaction techniques with minimal programming effort. The UIMS should also facilitate the development of user interfaces with at least some reusable components. This helps to reduce future UI development time.

It is worthwhile to note the recent redefinition of the “application ” as a “functional core of an interactive system ” to which extended functionalities of the user interface belong8. The need for refining this definition further, into user interface independent and dependent parts, is considered of little practical use because rapid prototyping greatly diminishes the effort involved in redesigning the user interface dependent part of the functional core of existing applications that require radical change to their user interface. It is indeed impossible to avoid the complete redevelopment of the user interface dependent part of the functional core/ application output. However, in practice, UIMS offer very little support for this activity. Given that the set of user interface functionalities required by most functional cores is finite, it is possible for the UIMS to provide much more than a mere “semantic repair tool” to support the application programmer in redesigning this part of the application. This applies to the functional cores of old applications as well as to new ones that require user interface functionalities that extend beyond that afforded by the UIMS (for instance, the application requires to use PHIGS or GKS-3D objects interactively and the X based UIMS cannot support this functionality). If the UIMS cannot provide such a sophisticated support tool, at the least, it should be designed to share the interaction control between itself and the application9.

Currently prevalent UIMS place much emphasis on their rapid prototyping tools but in practice offer very little support for building the user interface dependent part of the application’s functional core, firmly placing it as part of the application code to be developed from scratch often at the X library level. UIMS demand a complete design rethink from engineering application developers, a loss of run-time control, a steep learning curve and reduced programming flexibility. Unless the UIMS provides an interactive interface tool to support the building of the user interface parts of the functional core, the utility of a UIMS to an engineering application is minimal. The application developers will be tempted to


Figure 2: Structures of Run-time Control.

opt for a toolkit level UIDE that provides greater flexibility and the additional code generation would still be more cost effective. This in turn will discourage the use of UIMS for engineering applications, depriving UIMS of much of their commercial success and widespread use.

2.5.2. Run-time Control

The control of communication between the user and the application can lie either with the user/UIMS or with the application or can be shared by both as appropriate to the state of the interaction2 [Figure 2]. When control lies with the UIMS it acts as an external control on the execution of the application. When the user is in control, all the interactions are event driven and the UIMS invokes the application in response to the end-user input. Event- driven UIMS should also provide mechanisms for the application to initiate an interaction in response to a state change within the application.

the application. This interface should contain information on the application callback routines, their input parameter data structures (or abstract forms of the data structures ; e.g. opaque pointers) as well as any constraints on the operators. This will help the UIMS to avoid sending semantically incorrect input to the application. Failing that there should be mechanisms for error recovery. Equally, there should be support for the user to abandon a command half way through. These two tasks require the UIMS to maintain a record of state changes so that the values of all the variables can be reset to a previous state of interaction. Additionally, it will also require the dialogue control component to hold a logical view of user interface objects/parts of the presentation component and maintain control over it so that the layout can be restored during error recovery/undo. Such control will help the dialogue manager to read from and write to the appropriate user interface objects. The consequences of the lack of such a mechanism are discussed with respect to two of the UIMS evaluated.

2.5.3. Communication Handling Provisions must be made for the programmer to build- in prompt texts, error messages, range and default values for user inputs. Consequently, the system should automatically handle the tasks of input prompting, range checking and default value substitution for missing values of the parameters.

This criterion explores the efficiency of the bidirectional communication between the user and the application via the UIDE tool; in short, the mechanisms provided for effective I/O data handling. The aspects under consideration include transmission of input to the application, the handling of data types, default types, default definition, prompting, input error checking and recovery. 2.6. Device Interaction

The intercommunication between the interface and the application should be able to provide complete support for the seamless transmission of user requests, user data and application results. The application may use the flexibility allowed by the underlying application language (e.g. C) to define new data structure (such as event records). The UIDE tool should not impose any external restrictions on the use of such data structures and should be able to handle all legitimate data types efficiently.

If an error in user input is at a semantic level, this may not be detected until the application parses the complete command. Ideally, there should be a distinct application interface between the dialogue control component and

Criteria such as portability are essentially concerned with a UIDE tool’s low level interaction capability with a host’s hardware and software. These are discussed below.

2.6.1. Portability

Portability refers to the ease with which applications based on a UIDE tool can be run on platforms other than the one on which they were developed. The tool should have been developed to adapt to different host environments, mask the underlying devices and provide a uniform higher level interface for application development and execution. The UIMS should facilitate the


development of separate and device independent code for both the interface and the application and improve the portability across different hardware and software environments.

2.6.2. Windowing

The UIMS should operate in a windowing environment to enable other applications to run alongside the UIMS/ toolkit based application so that the user may temporarily suspend interaction with it and interact with another application. This is particularly valuable when the user is required to wait for the UIDE based application to complete computations. If the system is adapted to a windowing environment, then concern focuses more narrowly on the type of window management system that the tool sits on and whether the system itself allows multiple windows for a single application.

With the emergence of X as the de facto standard, it is necessary for a UIMS to be not just compatible with the X window system but actually support an X toolkit/widget based user interface development. Applica- tions built on such UIDE tools will be able to exploit the device independent graphics and enhanced portability that X offers.

2.6.3. Low-level Control and Communication

The dialogue manager should enable the application to gain low-level access to the I/O devices, should the application need to do so. Alternatively, an application may warrant rapid graphical interactions which can be achieved if the UIMS/toolkit supports direct run-time access to the Operating System (OS) or the specialised hardware. This facility is not desirable as it may en- courage hardware and OS dependent application development which diminishes portability. Nevertheless there are practical situations where this may be a necessity such as a “game” program wanting to control the keyboard device as well as utilise fast graphics processing.

2.6.4. Distributed Systems and Multimedia

The UIDE tool should be able to adapt to distributed systems and to advances in hardware technology such as multi-processors. There should be support for a variety of novel input and output devices such as video, voice, gesture and touch beside text and graphics.

2.7. Compatibility

Compatibility measures the amount of modification required to an existing application to enable it to execute in the enhanced interface environment provided by the UIDE tool. More often than not, this depends on the

UIDE tool’s ability to accommodate a graphics package other than its own, alongside its own subsystem. Ideally, a UIDE tool should base its own graphics on current or emerging graphics standards such as PHIGS so that a large number of potential applications would already be compatible with the system. Failing this, the system’s graphics should adhere closely to the prevailing standard and there should be mechanisms within the tool for communication between the system’s and the application’s graphics. The latter mechanism will enable the symbolic graphics that supports the interactive process and the user interface to be based on the UIMS’ own subsystem while allowing other standard packages to be used for the direct graphics that represents the application data (results of computations).

2.8. Interface Inplementation

This section comprises the issues concerned with the provision of tools such as an interactive layout editor within the UIDE system for the implementation of modular reusable user interfaces.

2.8.1. Tools

If a UIDE tool provides only a low level language for user interface development, much effort is wasted on getting the correct syntax of the UI code specification. This is especially true in the case of novice interface designers who may be reluctant to disturb a working prototype and thereby inhibit their experimentation. In order to increase the innovative productivity of the interface designer, there should be mechanisms for the codeless development of user interfaces within a UIDE tool. It should be possible to evaluate all interface designs easily without having to compile the corresponding application. Ad- ditionally, the UIDE tool should provide mechanisms to convert any interface developed with it into portable modules.

To minimise repetitive code, a UIMS should extend automatic generation of stubs for command action/event callback routines to the application.

2.8.2. Recompiling

The bonus of a modular approach to interface development is the ability to test, alter part or all of an interface and rerun the modified version without having to recompile the complete system including the application. Generally, a completely separated interface is read into memory and linked to the application during run-time by the UIMS’ interface manager. Hence, changes to the application that do not affect the UI do not require the recompilation of the UI and vice versa.


2.8.3. Complexity of Application Interaction Specification Code

Beyond the graphical user interface stage there should be a high level dialogue specification language to describe the interaction. The UIMS should also provide a rich set of application callable library routines for the run-time manipulation of the user interface. This should be part of the UIMS’ application development support.

2.8.4. Specification Granularity

The interface designer/programmer should be allowed access to all levels of interface specification by a UIDE tool. The system should allow lower level operation routines to alter a higher level specification. Alternatively, any low level specification from the application should be accepted and interpreted by the UIDE tool.

2.9. Other Run-time Aspects

The run-time aspects include the input processing, dialogue style support, incorporation of help and support for style independent output.

2.9.1. Input Processing and Dialogue Styles

The point of interest here centres on the input processing capabilities of the UIDEs.

The UIMS’ toolkits’ run-time input interpretation should be dependent on the system state and be transparent to the user. The UIMS dialogue manager should be able to validate user input with reference to the underlying application logic and the state of the interaction. The system should be able to cope with more than a single input device at a time and should allow the interaction to continue in cases where a previous user command requires the system to undertake time con- suming computations. For applications that handle such computations, the system should support the rest of the application to be run in batch mode. There should be support for running the application remotely and for displaying output in remote display devices. During interactive sessions, the system should log user commands which may be used to simulate a future session.

A salient feature alongside input processing is the UIMS’ support for unrestricted navigation through the dialogue. There should be minimal restrictions on the structuring of the interaction dialogue. The restrictions imposed on the dialogue should be for the sole purpose of improving the structure of the interaction. The dialogue development tool should aid the development of reusable components. The common styles of dialogue may be one of:

tree structured dialogue, which offers an entry-level

selection of commands that branches randomly according to the user’s previous selection. (Hier- archical menu-driven applications use this form of dialogue sequence.) ;

circular dialogue;

multi-threaded dialogue where the execution of one command is suspended in favour of the most recent one the user has issued;

multi-threaded and multi-programming style in which several commands are processed simultaneously.

2.9.2. Help

The help provided by the system comprises help for using the system itself and help for the end-user for familiarisation with the application. The help system itself should be unobtrusive and there should be no need for the end-user to learn its functionality. Ideally, UIMS should also provide tools for the UI designer to build end-user models and application data models. Additionally, there should be support within the UIMS to exploit these user and data models for the development of interfaces. This will help the interface designer to meet various levels of application end-user expertise and their expectations.

2.10. General System Aspects

The aspects of concern here are the training and technical support provided by the software supplier, ease of installation of the tool, the quality of the user manuals and the run-time performance of the system when the application is executed. Additionally, there should be support for the end user to trace back and analyse the design of a presented user interface. This will be especially helpful to novice interface designers to master novel interface design ideas.

3. System Descriptions

3.1. USEIT

USEIT is a User Interface Management System marketed by UNIRAS Ltd. It is written in ANSI FORTRAN-77. Any application using it must also be written in FORT- RAN-77. USEIT operates in both mainframes and workstations and can support graphic displays, pointer devices and alphanumeric terminals. Version 1.1 of USEIT runs under X as well as SunView. USEIT [Figure 3] requires FGL/GRAPHICS as a graphics subsystem for dialogue. A positive aspect of USEIT is that it extends interactive graphical user interface designing facilities directly to FORTRAN applications.

The complete interface (screen layout, menus and the


Figure 3: USEIT System Architecture (Courtesy: UNIRAS Ltd).

interaction dialogue) of a USEIT based application is specified in a high level language called UDL (User Dialogue Language), in a text file using an ordinary text editor. UDL allows the interface designer to specify WINDOWS, PANELS, MENUs, COMMANDs, command PARAMETERS, DATATYPEs, HELP texts, MESSAGEs and HOTKEYs as individual user interface items. All such interface items are parameterised and commands are associated with corresponding action numbers in a command table. Once the command table and the interface layout are restored by USEIT (from the USEIT system files USF), the application execution loops around a single call to the command interpreter. The command interpreter waits for and traps all user interactions.

3.2. Graphic Modelling System (GMS)

Sherrill-Lubinski Corporation’s Graphical Modelling System (GMS) is a UIDE toolkit for building and animating display images associated with real-time data- driven applications. In order to facilitate this type of user interface development, GMS offers a large array of graphical primitives, an interaction graphics editor (DRAW) for creating complex user interface objects using the graphical primitives and a host of library functions, through the Graphic Modelling Function and Dynamics Libraries (GMF-GMD), for the dynamic

manipulation of these UI graphical objects. The structure of the tool [Figure 4] enables the display images, built with GMS, to be linked to an application’s data by a layer of code. These images can then be animated to reflect external real-time information. GMS facilitates images (or graphical objects) to be visually updated, at rapid intervals of about every fifth of a second, as the values of the linked variables change. GMS also provides a command language (GML) to create the user interface objects.

GMS is currently available on a wide range of mainframes and workstations and for operating systems compatible with these platforms. Individual configurations of GMS can be tailored to integrate with terminals dedicated to graphics packages such as GKS, any other special-purpose display software or X.

3.3. TeleUSE

TeleUSE, from TeleLOGIC Programsystem, Sweden, provides a OSF/Motif 1.1 based environment for user interface development. TeleUSE is currently available for Sun 3, Sun 4 and DEC3100 workstations. It is geared to handle graphic and alphanumeric terminals and also the pointer device. Applications using TeleUSE need to be written in C.


Figure 4: Schematic Diagram of SL-GMS (Courtesy: SL Corporation).

TeleUSE [Figure 5] splits the UI into three generic components, namely :

a graphical interface;

dialogue control;

an interface between dialogue control and the application code.

TeleUSE provides separate tools for the modular development of an application’s UI along the aforemen- tioned lines. These tools encompass an interactive WYSIWYG (What You See Is What You Get) type graphics editor called VIP, a rule based dialogue description language called Dialogue, an application interface manager and a UI builder that assembles an executable program from the individual modules created using VIP and Dialogue. Another useful and novel tool is the Debugger that can be invoked during the construction of the interface for checking the dialogue.

4. Assessment Results

As mentioned already, the results reported herein are based on the individual software system’s performance during the implementation of the benchmark application. The details of this benchmark application and the performance of each system in relation to this application development along with comprehensive descriptions of the UIMS components are published separately as an EASE Technical Report’. In this section the perfor- mances of the three systems are described in terms of the assessment criteria detailed in Section 2. The names of the assessment categories are repeated here for easy reference. The numbers in brackets correspond to those under Section 2.

4.1. Automatic UI Design and Rapid Prototyping (2.1)

The level of prototyping support facilitated by the UIDE tools under study is much below the ideal level of automatic generation of several styles of interfaces from a single design specification.

TeleUSE associates user events with application callback routines. The programmer can also define certain events to occur internally from within the system when the values of associated flags become true. The UIMS’ dialogue manager processes all events according to the

4.2. Semantic Feedback (2.2)

event descriptions, invokes relevant callback functions and handles all output.

GMS has explicit support for the inclusion of culturally derived application semantics into the interface objects.


Figure 5: TeleUSE Architecture (adopted from the manual).

4.3. Interaction Technique and Feedback (2.3) GMS provides feedback such as rubber-banding at the interactive interface development stage. Dynamic feedback can also be built into GMS based user interface objects. The interaction primitives offered by USEIT are very limited.

All the three software tools are designed to support both keyboard and graphical user interactions and support the logical view of the input. End-user interactions via static, pop-up and pull-down menus, hotkeys, aliases and macros are easily implemented using any one of the three ~- software packages under consideration: GMS additionally facilitates the programmer in building application specific graphical input interface obiects (e.g. a robotic

4.4. User Interface Customisability and Extensibility (2.4)

ar

m) for direct manipulation by the end-user. USEIT provides an icon editor for creating static user interface icons.

The graphical part of the UI development, supported by USEIT, is rather narrow and unimaginative which may be attributable to the underlying graphics package. On

All three systems support for basic input echoing. the other hand, it provides a free panel mechanism to accommodate command structures that differ from the

Only TeleUSE supports continuous feedback to both the interface designer and the end-user automatically.

tree-like structure the UIMS prefers. Once these free panels are defined in the UI definition, USEIT library

124 L. Sastry UIMS for Engineering Applications

routines enable the application to temporarily suspend the dialogue handler and access the user interaction via the free panels directly. Thus, the UIMS architecture of USEIT provides an effective input interrupt mechanism for dialogue extension for the applications based on it.

GMS, being a toolkit, imposes neither an interaction style nor a specific look and feel of its own on the UI developed using it. It is possible to define class extensions using the optional GMS C + + library. There is no system imposed structure on the dialogue.

TeleUSE is based on the OSF/Motif widget set and provides an OSF/Motif look and feel to any application interface built using TeleUSE. However, TeleUSE also provides a template mechanism for grouping the user’s own widget sets alongside OSF/Motif and Athena widgets. Thus, TeleUSE supports the extension of the widget functionality and also customisation of the look and feel of the interface to the user’s own style. TeleUSE’s support for button mapping adds to the flexibility of the interfaces developed with it. TeleUSE does not impose any restrictions on the interaction dialogue/command structure.

4.5. Relationship between the User Interface and Application (2.5)

Only TeleUSE supports an explicit application interface module. Hence its run-time support is more robust.

4.5.1. UI and Application Separation (2.5.1)

TeleUSE, GMS and USEIT facilitate the development of UIs that are completely separated from the corresponding applications. They conform to the general two modules architecture of UIMS, namely, a preprocessor for the UI implementation and a run-time support environment. As part of the separate UI development facility, TeleUSE and GMS facilitate the previewing of an interface as an integral part of their interactive graphical editor, while USEIT requires a dummy application routine for this purpose.

4.5.2. Run-time Control (2.5.2)

The run-time control with USEIT is a mixture of both external control by the dialogue manager and internal control by the application. The USEIT dialogue handler awaits a user command, interprets it, and any local action associated with the command is performed without reference to the application ; all application commands are associated with the corresponding action numbers and control passes to the application. USEIT also supports batch mode execution of the application where user commands are retrieved from a system file.

The toolkit functionality of GMS is explicit in the

internal control exercised by the applications based on it. Even though the software is claimed to support user- defined callback functionality, in practice, such implementation has not proved to be straightforward.

TeleUSE is primarily event driven and facilitates the inclusion of callbacks naturally. The TeleUSE widgets possess the inherent ability to generate events. However, it also accommodates internal control by allowing the programmer to set series of flags.

4.5.3. Communication Handling (2.5.3)

USEIT handles character strings, numerical values, choice, boolean, graphical locations (points) and array data. The user-specified input value is stored by USEIT in the relevant cells of any one of a real, integer and character arrays as appropriate. The value is then directly passed on to the calling application subroutine as input. USEIT supports the specification of range and default values for parameters (excepting location information), input prompt texts and error messages and handles these independently without recourse to the application. USEIT additionally allows the programmer to specify whether or not a user input is optional.

Since GMS is targeted as a toolkit for real-time data driven applications in specialist areas such as engineering, medicine and economics it enables interface objects to be bound to user database through application variables. For such simulation applications, GMS graphically updates the interface objects associated with the application variables with minimal end-user interaction. GMS requires the application to make explicit calls to GMS library to implement mechanisms such as range checking and error handling. GMS applications are written in C.

TeleUSE uses “ opaque pointers” to interact with the application data structures so there are no restrictions on the application’s exploitation of the C data structure definition flexibility.

Default specification, range checking and prompt and error messages can be built into the interface with TeleUSE and USEIT and the UIMS handles these at run- time independently. Range and dynamics can be built into GMS user interface objects.

In all three tools, error recovery is limited to the system discarding the latest data entry as a result of their type and range checking. The combination of an application interface and in-built characteristics of the widget based user interface ensures that the level of control and error recovery are effective for TeleUSE based applications. Neither the dialogue handler of USEIT nor the application based on GMS has control over their respective presentation component. The lack of such control is most


visible in USEIT’s input interpretation, output redirec- tion and hence effective error recovery. GMS is a powerful tool for building process monitoring applications. Hence it is rather unfortunate that the run-time system/application has no control over the presentation layout to prevent unwanted user actions altering the presented user interface.

4.6. Device Interaction (2.6)

4.6.1. Portability (2.6.1)

All three tools have been developed to produce portable code. As long as the tool is available on a hardware platform, applications developed with the tool can be run with minimal effort on that host. As already mentioned in Section 3, the three UIDE tools under consideration are available for a wide range of mainframes and workstations. GMS provides a workstation object that completely adapts and controls the resources of a workstation’s hardware and software. With this facility, GMS is able to extend the use of dedicated special purpose devices such as high resolution monitors, printers or display software such as GKS to any application that has been developed in a less sophisticated environment. It may be the case that under such circumstances the porting will involve some programming overhead.

4.6.2. Windowing (2.6.2)

At the time of this evaluation, GMS did not have a configuration based on X for the Sun workstations but X based versions were available for other platforms. Tele- USE is completely dependent on X as its subsystem and provides a convenient interface to Xlib and X Toolkit Intrinsic. USEIT is supplied with device drivers for X and few other popular windowing environments.

Of the three systems, only TeleUSE is capable of supporting multiple windows for every application that runs on it. GMS’s screen State Management System can support multi-layered graphics screens (rectangular areas of the host’s monitor), switching sequentially from one layer to another.

USEIT does not support multiple windows except in a notational sense. The application UI layout is confined to a single base frame of fixed pre-set size pre-set by USEIT. This base frame can be manipulated like any other window management system’s window but resizing does not result in proportional changes to the layout graphics.

4.6.3. Low-level Control and Communication (2.6.3)

Applications based on TeleUSE and GMS are written in C and permit a degree of low-level control and communication.

4.6.4. Distributed Systems and Multimedia (2.6.4)

The three UIMS are adapted to distributed systems but none of them support multi-processor hardware or novel I/O devices.

4.7. Compatibility (2.7)

All three software packages require all parts of the dialogue of an existing application to be rewritten. None of the three UIDE tools’ utilise standard graphics such as GKS or PHIGS for their underlying system; nor do they provide mechanisms for its graphics subsystem to coexist with another.

USEIT supports GKS metafiles to be read at run-time.

GMS provides support for applications to run on dedicated GKS terminals. The graphics of GMS is indeed very powerful and compares well with PHIGS.

Only X graphics based applications are compatible with TeleUSE.

4.8. Interface Implementation (2.8)

4.8.1. Tools (2.8.1)

TeleUSE leads the three systems in the user interface development tools it provides. TeleUSE‘s Visual programming Interaction Primitive (VIP) layout editor is sophisticated and user friendly and supports the building of the graphical presentation component of a UI. VIP enables the programmer to create instances of individual widgets from the OSF/Motif, Athena and user’s own widget sets and placed them hierarchically in the application’s user interface module. The resultant bundle, saved as a PCD (Presentation Component Description) file, is reusable across applications. Other subtools that exist within VIP are:

The interactive widget attribute tailoring tool.

The widget browser (enables the viewing of the hierarchical tree of the complete layout either by name or by widget class).

The editor also provides support for previewing the interface and logging the preview interaction.

GMS also provides an interactive, mouse driven graphics editor, called DRAW, for creating graphical models that are recognised and manipulated by the other components of GMS. With DRAW the interface designer can create objects and/or change their attributes and add dynamics to them. Once a model has been finalised, the system menu enables the user to save the model by name and also replicate, restore and edit it. The Graphics Modelling Language is a command interpreter provided


by GMS for producing portable ASCII files of the interface objects in C structures.

GMS provides an extensive set of templates for graph display as well.

USEIT is minimal in the interface development tools it provides. The UDL dialogue language has the dual purposes of specifying the graphical interface layout as well as the interaction dialogue. No doubt the UDL interface specification language i s quick and easy to master, but its scope is rendered too narrow by the tool’s underlying architecture. USEIT also provides an icon editor.

Automatic stub generation is not appropriate for GMS based applications.

USEIT passes command action numbers to the application. Typically, each action number is associated with an application routine. So the programmer has to write a basic i f . , , then. . . else branching subroutine to call the appropriate routine for each action number. Since all action numbers are already specified in the UDL file, this branching routine could very well be generated by the system. Unfortunately it does not.

Similarly, the parameter elicitation is explicit with USEIT and is often repetitive. This elicitation has to be performed before calling the application procedure associated with the command. Given that each parameter associated with every action is already specified in the UDL description, these elicitation calls could have easily been generated automatically with the stubs but is overlooked.

4.8.2. Recompiling (2.8.2)

All three UIDE tools support independent modular interface development. The interaction dialogue of an application based on GMS is embedded within the application and any change to it inevitably requires recompilation of the application but not the graphics part of the interface. TeleUSE once again leads in supporting an independent three pronged selective alterability of the interface layout, the dialogue description and the application. The same effect can be achieved with USEIT but in a rather clumsy and circuitous way.

All three UIMS allow the interface to be altered while the application is running but incorporation of the changes will be effected only by rerunning the executable program.

4.8.3. Complexity of Application Interaction Specification Code (2.8.3)

The Dialogue language environment of TeleUSE consists of an event driven rule-based language used for describing

the dynamic behaviour of the UI, the Dialogue language interpreter and a graphical debugger for checking the UI dynamic descriptions independently from the application. The Dialogue language has an easy to learn syntax and is versatile. There is also a Dialogue language compiler which translates Dialogue language into C code for compilation and execution.

In the Dialogue language environment the dynamic behaviour description is split into two components [see Figure 5]. One of these contains the event descriptions together with any parameters required by the associated function. The other dialogue language module is a declarative part that defines the events the module accepts and sends, its flags and other local variables. The rest of this module contains the rules that specify the resultant actions associated with all the events. Thus TeleUSE helps conveniently to split the interface development into intuitively distinct components. Indirectly, the combination of these tools has a positive influence in the structuring of the user-system interaction dialogue.

The TeleUSE run-time library contains Dialogue language and C-callable routines that initialise, access and manipulate parts of the UI at run-time. These routines manage all the widget, X and Dialogue language event handling and provide convenient interfaces to Xlib and X Toolkit Intrinsics. Apart from producing an executable from all the different modules, the TeleUSE UI builder also facilitates the debugging of all or parts of the dialogue at source code level.

The USEIT based application dialogue is described in the UDL. USEIT also provides a host of application- callable library routines to handle I/O. The USEIT interface coding is simple but is limited by the underlying graphics subsystem in what it can offer.

With GMS, the run-time dynamics of all the user interface objects can be defined at the time of their creation without recourse to coding. The GMS screen state interface manager handles all these dynamics at run- time. Additionally, the GMS functions library also supplies the programmer with an army of complex routines to manipulate the interface from within the application. The dialogue has to be specified within the application and has to be written in C. There is little or no restriction placed on the dialogue by GMS. However, the toolkit nature of GMS forces a very steep learning curve. The effective use of the sophisticated graphics depends on getting to grips with the underlying architecture and on exploiting the Graphics Function Library. Any resultant code developed is verbose relative to the task. Binding the model variables of the interface objects to the application database variables i s complex but the resultant animation is powerful.

L. Sastry UIMS for Engineering Applications 127

4.8.4. Specification Granularity (2.8.5)

TeleUSE is the only tool that allows low-level access to its subsystem. The interface specification itself is protected from the need to program at such low-levels. However, applications programmed at the Xlib level are connected through the “opaque pointers ” and widget representa- tions.

4.9. Other Run-time Aspects (2.9)

4.9.1. Input Processing and Dialogue Styles (2.9.1)

USEIT’s support for the context sensitive interpretation of interactive graphics input is very clumsy. This draw- back stems from the graphics sybsystem and the UDL definition of the UI items. The complete user interface layout, built using USEIT, is a single active graphics window. Parts of this basic layout are usually assigned for the purposes of displaying menus via selection panels or eliciting textual information via a text window or graphical display of application results. There is no real distinction apart from notational terminology between these panels and the presentation and interaction parts of the layout. Hence, the dialogue handler does not have a logical view of the presentation layout partitions. There is no application interface module either to provide some information on application semantics. Hence, there is total lack of in-built mechanism for the dialogue manager to cross-check the contextual relevance of a location input to the physical UI object it emerged from. The information is indiscriminately validated with respect to its syntactic definition. As a consequence, all uninten- tional button clicks are treated as legitimate inputs and processed, leading to end-user frustration and disfigured UI layout.

Recognition and handling of input via a GMS interface are strictly controlled by the application during run-time so there is very little information provided about input handling and interpretation aspects in GMS.

With TeleUSE, all parameters associated with application functions are specified along with the respective event description by the programmer. The widgets act as individual cells of data-entry forms in getting the user input. TeleUSE distinguishes parameters as either static or dynamic. The static parameter values (such as the value of a push button in a calculator) are set at the time of building the UI. The values of the dynamic parameters are filled in at run-time by the TeleUSE dialogue handler from the appropriate widget fields. Whether the parameter is static or dynamic, the built-in characteristics of the widgets enable the TeleUSE dialogue manager successfully to ignore inappropriate data input.

USEIT allows the application to be run in batch mode. However, there is no support for switching between

interactive and batch mode during an application’s execution.

GMS explicitly supports remote display.

All three systems allow a simple method of recording

USEIT favours tree structured dialogue but, as mentioned previously, supports the application-specific dialogue structure as well. GMS and TeleUSE impose no restrictions on the dialogue structure.

An additional aspect of interest is whether the system supports data-entry form style input for multiple fields in a random order. There can be dials and switches attached to the form for input and there should be scrollbars to enable inspection of entries on long forms. This is possible with both GMS and TeleUSE.

user commands.

4.9.2. Help (2.9.2)

All three UIDE tools are accompanied by extensive demonstration examples that aid the programmer’s familiarisation. In fact, fairly complex applications can be developed using these examples as templates. Well written manuals and the usual “ README” on-line files are supplied with each of the systems.

Both TeleUSE and USEIT enable the programmer to include help for the end-user to understand the application and the input expected at each stage. The end- user has explicitly to request the help information to be displayed. None of the systems support building in a user model, nor are they capable of making an intelligent decision automatically to display appropriate help messages.

4.10. General System Aspects (2.10)

All three system installations are straightforward. Well written documents are supplied with each system.

The suppliers of GMS and TeleUSE offer training with their products.

Of the three suppliers, TeleLogic offered by far the best technical support. Unlimited access to technical assistance for this evaluation via electronic mail, telefax and telephone was offered ; the support was prompt and addressed the issues raised. The evaluation agreement on GMS did not include any component of technical assistance. Technical support for USEIT was virtually non-existent, except for a single offer to forward parts of the troublesome code to the parent company.

All three systems were evaluated on Sun workstations. The architectures of the host machines were different so a performance comparison between the systems cannot be made.


As for back tracing, it is possible to visualise the complete widget hierarchy of an application’s interface with TeleUSE’s widget browser. GMS interface models can be converted to readable structures. The UDL specification of USEIT is self explanatory.

5. Summary of Results

USEIT is designed to run on both terminals and workstations. The unfortunate trade-off in such a design is that the system fails to exploit any functionality offered by the windowing environment on a workstation. The scope of the interfaces developed with USEIT is limited. Nevertheless, USEIT does offer some crucial UIMS functionality. USEIT can operate both in interactive and batch modes. As such, USEIT offers a first generation level support for interface development for FORTRAN applications. Beyond that, there is very little to commend USEIT.

GMS is an application development kit rather than a UIMS - GMS provides natural support for real-time animation and direct-manipulation interface objects. There are the steep learning curve and the considerable programming overhead but the right class of applications will benefit very much from using this system. [Note: Version 4.0 of GMS has been targeted to include enhancement such as FORTRAN-77 bindings, SQL interface for databases and X based configurations with either OSF/Motif or Open Look widget set compatibility.]

TeleUSE, among existing UIMS, offers the best UIMS functionality. The architecture of TeleUSE, its interface development, run-time environment and control are intuitive ; the widget based interface development is at the state-of-the-art level and commendable. Knowledge of the X Window System and X based toolkits programming conventions are essential pre-requisites for using Tele- USE. [Note: Version 2.0 of TeleUSE is targeted to include full support for OSF/Motif 1.1 and Athena, compatibility with X Release 4, automatic generation of C code, generation of UIL and the capability of adding user widgets and toolkits.]

Both TeleUSE and GMS offer the interface designer a UIDE tool that exploits the most up to date developments in programming environments. TeleUSE has the edge in its utilisation of the X Window System as the underlying subsystem and the functionality offered by the OSF/ Motif based widget set. GMS offers an object-oriented approach with an optional C++ library for class extensions.

6. Conclusion

These assessments were carried out with the primary aim to study the suitability of UIMS for engineering applica-

tions, especially for the large “dusty deck” FORTRAN applications. None of the above systems met all the requirements. Each system harbours some inadequacy in their adoption of emerging standards. In practice, it had been rather easier to abandon the old code completely and write the application from scratch; the style and structure of old FORTRAN application code may have to be blamed for this but the UIDE tools do not provide even partial support for such an exercise. Even for new applications, no single system exists that is adept at providing the programmer with complete freedom to build user interfaces across a variety of applications with equal ease. Hence it is up to the programmer to match closely the application’s requirements with either GMS or TeleUSE functionality before deciding on the system to use and to be prepared to accept the trade-off.

7. Acknowledgement

The author wises to acknowledge the financial support of SERC for this project. The comments of colleagues are gratefully acknowledged. The author wishes to thank the referees for their reviews.

The results reported here are the author’s personal opinions based on the experience of building benchmark applications using the three software systems.

8.

1.

2.

3.

4.

5.

6.

7.

References

M. Sastry, C. T. Walls, B. Ritchie and J. C. Bicar- regui, “Evaluation of Five User Interface Man- agement Systems”, EASE Report, ETR10/91 (1991).

E. Pfaff, User Interface Management Systems, Springer-Verlag (1985).

M. Prime, “User Interface Management Systems - A Current Product Review”, Workshop on User Interface Management Systems, Glasgow Univ. (1987).

R. A. Guedj, P. J. W. ten Hagen, F. R. A. Hop- good, H. A. Tucker and D. A. Duce, Methodology of Interaction, North-Holland (1979).

D. Hix, “Generations of User-Interface management Systems”, IEEE Software, pp. 77-87, Sept. (1990).

D. Hix and R. S. Schulman, “ Human-Computer Interface Development Tools : A Methodology for Their Evaluation”, Communications of the ACM, 34(3), pp. 74-87 (1991).

J. D. Foley, V. L. Wallace and Peggy Chan, “The Human Factors of Computer Graphics Interaction


Gomes, F. R. A. Hopgood and J. R. Lee, Springer- Verlag (1990).

8. P. J. W. ten Hagen et al., “Concepts, Methods, 9. J. Hardenbergh and J. Michener, “Integrating PHIGS and User Interfaces Systems”, Computer Graphics Forum, 10(1), pp. 27-36 (1991).

Techniques”, IEEE Computer Graphics and Applica- tions, pp. 13-48 (1984).

Methodologies Working group ” in User Interface Management and Design, eds D. A. Duce, M. R.

Documents

User Interface Management Systems for Engineering Applications