Including a user interface management system (UIMS) in the performance relationship model

This paper discusses the design and applications of an object-oriented user interface management system (UIMS). Specifically, the Lockheed User Interface System (LUIS) is described. LUIS is based on a user interface model that includes declarative and procedural components. The package has been used by both non-programmers and programmers in several applications at Lockheed. Experiences derived from applications of the package are used to address several key issues in the UIMS field, such as procedural versus declarative specification, separation of the user interface from applications, UIMS flexibility, and UIMS support for design evaluation.

This article is focused on the system side of the multidisciplinary problem of building User Interface Management Systems (UIMS) for distributed and heterogeneous I/O devices. It presents a new architecture that decouples applications from their interfaces by using distributed synthetic file system interfaces (similar to /proc on UNIX) to export user interface elements and a new UIMS, O/live, following this approach. The UIMS has been in use for several years on a daily basis, in our laboratory and personal computers. It supports transparent distribution, replication, and migration of user interface elements among highly heterogeneous devices. Moreover, it is highly programmable without the need for special tools, which (a) facilitates experimentation and iteration for new human–computer interaction techniques and (b) enables the creation of orthogonal services to manipulate programmatically and independently the elements of the distributed UI. This article describes both the approach and the O/live UIMS and window system.

A UIMS (user interface management system) that is completely based on nonproprietary software has been developed. A central part of the UIMS are processes (mapper) that act as universal X-clients for each specified X-server. Mapper (graphic server) and applications (graphic clients) exchange requests by an event-driven interface. The communication protocol is free from any graphical information. The most powerful mapper client is a former interpreter that can be programmed to act as an equipment access server. The concept of a graphics server and a form interpreter allows the man-machine interface to be developed in a descriptive way. Appropriate to the level of abstraction in the UIMS, a specific UIDL (user interface definition language) had to be introduced.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

A User Interface Management System (UIMS) handles the dialogue between an application program and the end-user, and it provides tools for construction of the dialogue. Ideally, it should be possible to develop the dialogue part concurrently with the application part. This would speed up development and allow a user-centered dialogue design to be combined with a more formal application development. To what extent this is actually possible, depends on the interface between the UIMS and the application program.

A user-interface management system (UIMS) is a system for developing and executing user interfaces. It provides design tools, human factors guidelines, definition languages, and run-time support for user-computer interfaces. The engineering information system (EIS) is the specification of a software framework providing services for accessing, controlling, managing, and exchanging design data and tools (into which organizations that use EIS place their own tools and databases). The authors describe the benefits of including a UIMS in a framework system such as EIS and present the EIS-UIMS concepts, model, and architecture. The two most important features of the UIMS are the separation of computational behavior from appearance and the provision of a script language that allows interface designers to represent the interface at a high level of abstraction, the user task level. The whole EIS program, including the UIMS activity, is currently in the design stage.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

The increasing size and complexity of mega construction projects result in having several geographically distributed stakeholders, collaborating with each other to successfully deliver the project. Electronic Product and Process Management Systems (EPPMS) are recently emerging to facilitate the collaboration between stakeholders, reduce the surprises and issues, and improve the project productivity. These are commercially successful but evolving systems. An important component of EPPMS is the Interface Management System, which aims at formalizing and automating the communication channels between stakeholders. An interface is generally considered the link between construction elements, phases, or stakeholders. An interface Management System (IMS) involves five iterative steps: (1) Interface Identification, (2) Interface Documentation, (3) Interface Transferring, (4) Interface Communication, and (5) Interface Closing. A fundamental part of step 2 is recognizing different roles in dealing with interfaces. Each stakeholder is assigned a different role, such as responsible, accountable, consulted, and informed. In a mega project, several thousands of interfaces exist with complex relationships between stakeholders. Therefore, identifying stakeholders with higher responsible roles has been requested as useful information to the project owner in dealing with some of the project risks. After the interfaces are determined, and the responsibilities are allocated, the critical stakeholders are identified using the centrality concept in Social Network Analysis. The critical stakeholders can be determined at the highest level, considering all types of interfaces, as well as for each specific type or discipline-related interfaces. The proposed methodology is applied on a hypothetical offshore project with over 500 interfaces. In fact, this project is a simplified representation of a real scale Liquid Natural Gas project. In order to reduce the complexity of calculations and clarity of explanations, the simplified case study is used. By implementing IMS in mega projects, different parties not only formalize the communication between each other, but also gain better visibility concerning their roles and responsibilities. In addition, the owner benefits from analysing the complex relationships between stakeholders to further identify critical ones, along with other criteria like package cost, stakeholders’ experiences, etc.

Until recently work in the area of User Interface development has been almost entirely ad hoc. Implementors have had to rely on their own judgement not only in the area of the interface appearance and dynamics, but also in the internal structure of interaction management. Considerable confusion exists in defining what constitutes a good User Interface, and in the management processes required to construct them. Insufficient software foundations and a lack of formalisms, tools and methodologies are contributing factors. To some extent these problems have been addressed by the User Interface Management System (UIMS) community, primarily for those working on large systems. This paper describes a methodology, developed as part of the design of a User Interface Manager, aimed at providing implementors with a structure for building interfaces which are separable from their underlying applications.

User interfaces are assuming an increasing importance within the design of a software product. This paper examines the various levels and components of window user interfaces and exposes their impact on software maintenance. It covers window systems, user interface toolkits, user interface management systems (UIMSs), dialogue separation and other user interface development concepts that will lead to more maintainable software. It also examines the research work on the testing of user interface software that is being pursued at the University of Durham.

The so-called “User’s Conceptual Model” (UCM) now occupies a place of importance in the design of the user interface of interactive (computer graphics) systems. At the computer side of the interface there has been much excellent research done on (graphical) input tools, culminating in the ideas that now form the basis for the Graphical Kernel System (GKS) Version 7.2 input functions. On the user’s side of the interface there is still much to be done. It is envisaged that models of UCMs will form the basis of an Information/Knowledge/Data Base that is accessed by a “User Interface Management System” (UIMS), an integrated collection of software tools whose function it is to enable the specification, implementation and maintenance of a user-computer interface that is “user-oriented” and (self-)adaptive. The formal specification of such UCMs is a natural prerequisite for that of the user-computer dialogue. A formalism based on Minsky’s frame theory and an extension of the Vienna Development Method (VDM) is outlined in this paper. Taking “user” to mean “application programmer”, I present examples taken from a model of a UCM of GKS Version 7.2. Canonical encodings are presented in Ada 1 and canonical semantics in Anna, a language for annotating Ada programs.

Most User Interface Management systems are state based and some use state transition diagrams for dialog specification. Although these diagrams have significant advantages, they suffer from drawbacks that make them impractical for the specification of complex user interfaces. Statecharts are a hierarchical extension of state transition diagrams and are well suited for specification of complex user interface dialogs. Statemaster is a UIMS implemented in C + + that uses statecharts for dialog specification. It has been successfully used both for rapid prototyping and target implementation of user interfaces. This paper describes the use of statecharts for dialog specification and the implementation of Statemaster.

This paper describes an approach to object-oriented interface design that goes beyond mere object decomposition. In our user interface management system we use logic and filters to declaratively specify and control a space of ways that objects may be composed to create interfaces. A filter is a package of constraints and associated typed objects that express the relationship of data and representation objects.Conceptually our system is completely based on constraints. Filters provide the high bandwidth constraints to maintain the components of the direct-manipulation interface while the logic forms the low bandwidth constraints to combine and provide communication between these components. The use of Horn-clause logic to compose separate interface objects facilitates both the distribution of computation onto multiple processors and the generation of multiple views of data. Intelligent backtracking implemented in the logic allows for user- and system-initiated undo operations to correct errors and/or try alternative approaches to a problem. We illustrate the power and flexibility of this approach by describing a floor layout and design system.

User Interface (UI) development tools (e.g., toolboxes, user interface management systems), design guides and guidelines provide essential support for interactive systems development, but they are not enough in isolation, since no fruitful outcome of an interactive application development process can be guaranteed. Ideally, development methodologies for interactive business applications should combine searching analyses of business processes, with design models and appropriate development tools that impose structure on development and guarantee high quality solutions, in both their technical and ergonomic aspects. This ideal may be Utopian. A more feasible and profitable goal is for a methodology’s phases to satisfy some minimal properties. Such properties require key activities to be integrated into development methodologies for interactive systems. Each activity can ensure coherent integration of the outputs of different phases, preserving these through subsequent phases without loss of information, yet entailing no further work. Each activity supports the convergence of development phases at a satisfactory solution.

User interfaces to support the design process

The UofA* User Interface Management System (UIMS) generates graphical user interfaces based on a high-level description of semantic commands supported by the application. A main part of the UIMS, called Chisel, generates the presentation component of interfaces. Chisel selects interaction techniques, determines their attributes, and places them on the screen of the display device. While doing so it is capable of considering device properties, end user's preferences, and interface designer's guidelines. The aim of this paper is to discuss in detail the design and implementation of Chisel.

: Serpent (Software Engineering Rapid Prototyping Environment) is an example of the class of systems known as User Interface Management System (UIMS) . It uses the X window system to interact with the end user, and is useful both as a portion of a production system and as a separate prototyping tool. Serpent supports the development and execution of the user interface of a system. It provides an editor with which to specify the user interface and a run-time system which communicates with the application to get the data to display. The system then uses the specification previously output from the editor to decide how to display that data. This report provides a technical overview of Serpent, its components, the module used in specifying the user interface, and the editor used in constructing the user interface.