Gilbert Cockton

Design principles for interactive software

Foreward. Preface. The context of interactive systems development. External properties: the users perspective. Internal properties: the software developers perspective. Software architecture models. Tools and materials. Example: interface for air traffic controllers. Conclusions. Glossary. Summary tables. References. Index.

The architectural bases of design re-use

The architecture problem for interactive systems is a hard problem. Objective, rational and well-informed analysis of interactive architectures is rare. This is not all due to sloppy thinking. Much of it is due to the many obstacles to progress in the area of software for interactive systems. The topic is inherently slippery, because it is hard to get a grip with either our hands or our feet. The minute we think we have a grasp of the main issues, new technologies rain down on us and wash away the islands of firm ground on which we are standing. Part of the problem has undoubtedly been a lack of appropriate standards. The GKS standard took a conservative approach to interactive input (Rosenthal et al. 1982), and the PHIGS standard (Shuey et al. 1986) has added no significant developments for interaction2.

Tools and Materials

An interactive system is seen by different people from different points of view. The system user is concerned with external properties, such as those that influence task coverage, flexibility and robustness during system use. The developer is often more concerned with those internal properties which address such things as the costs and reliability of development throughout the entire development life cycle.

Software Architecture Models

This chapter demonstrates how one can use analysis of software architectures to generate software designs that are compatible with a chosen ‘property profile’. Such a profile must be determined during requirements specification. The approach used in this chapter is to take each external and internal property, and describe (in)compatibilities between it and some interactive software architectures. Architectures developed and refined during the system and software design phases can be compatible with this profile in four ways.

External Properties: the User’s Perspective

The usability of an interactive system is linked to the quality of the dialog, and quality shall here be expressed through a number of measurable properties of the dialog. The aim of this chapter is to identify and define a set of user-centered properties of interactive systems which promote high quality from the perspective of the users. The set must be as complete and mutually independent (‘orthogonal’) as possible. At the same time these so-called external properties must be usable in the software development process as yard-sticks or ‘measures’ in the quality plan for the development. For a particular system, some of the properties may be absolute requirements (this interactive system must have such and such property), while others are desired in a quality plan but are given some ‘weight of importance’ (0 ≤ ω < 1). Once we understand these properties and their implications, and also the internal properties presented in the next chapter, we will be able to discuss how to construct interactive systems possessing desired and required properties.

Internal Properties: The Software Developer’s Perspective

Every engineering project is driven by the need to produce an acceptable product which matches the users’ requirements and which will therefore be accepted in accordance with contractual obligations. Where a product is being produced speculatively in the hope of attracting users, there is just as strong a set of requirements (including costing and timing) as when a specific client has ordered something.

Methods, models and architectures for graphical user interface design: IFIP working groups 13.2/2.7 joint workshop, Loughborough, UK, September 1994

The purpose of this workshop was to bring together researchers and practitioners to focus on GUI design problems. The two working groups represent methodological (13.2) and an architectures/tool (2.7) interests, so the workshop focused on intersection of how methods can support tools and user interface development and vice versa, how tools, architectures and reusable components can empower the design process. The suggested topics for the workshop were:

Visualising persistent stores

This paper summarises work to design Software Visualisations that support Napier88 programmers in understanding and using the contents of the persistent store. Two example visualisations are described. Their effectiveness in supporting their intended tasks has been assessed by studying programmers using these visualisations.

Example: Interface for Air Traffic Controllers

This chapter introduces a single large example of using the properties and architecture which have been discussed in earlier chapters. The example chosen is an Air Traffic Control (ATC) Support System. The concrete meaning of the abstract properties introduced in earlier chapters will be discussed in that context, showing how one property interacts with other properties. The relevance of this to the design is shown by examples, which are followed by a discussion of possible architectures for the ATC Support System.

The Context of Interactive Systems Development

Interactive computer systems are built in order to help people achieve some goals as efficiently as possible. Users at work have tasks to perform, and the systems they use should support these extensively and appropriately. This chapter establishes a context for discussing the quality of interactive systems.