Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ 2. Control Structures □ 3. Syntactic Structures □ 4. Cognitive psychology and interaction □ 5. Visual Communication □ 6. Presentations □ 7. Working Groups □ 8. Group Reports □ 9. Postscript □ 10. Position papers □ 10.1 Anson □ 10.2 Baecker □ 10.3 Bo □ 10.4 van den Bos □ 10.5 Crestin □ 10.6 Dunn □ 10.7 Dzida □ 10.8 Eckert □ 10.9 Encarnacao □ 10.10 Engelman □ 10.11 Foley □ 10.12 Guedj □ 10.13 ten Hagen □ 10.14 Hopgood □ 10.15 Klint □ 10.16 Krammer □ 10.17 Moran □ 10.18 Mudur □ 10.19 Negroponte □ 10.20 Newell □ 10.21 Newman □ 10.22 Nievergelt □ 10.23 Ohsuga □ 10.24 Rosenthal □ 10.25 Sancha □ 10.26 Shaw □ 10.27 Tozzi □ 11. Bibliography
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology of Interaction
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology of Interaction
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ 2. Control Structures □ 3. Syntactic Structures □ 4. Cognitive psychology and interaction □ 5. Visual Communication □ 6. Presentations □ 7. Working Groups □ 8. Group Reports □ 9. Postscript
10. Position papers
□ 10.1 Anson □ 10.2 Baecker □ 10.3 Bo □ 10.4 van den Bos □ 10.5 Crestin □ 10.6 Dunn □ 10.7 Dzida □ 10.8 Eckert □ 10.9 Encarnacao □ 10.10 Engelman □ 10.11 Foley □ 10.12 Guedj □ 10.13 ten Hagen □ 10.14 Hopgood □ 10.15 Klint □ 10.16 Krammer □ 10.17 Moran □ 10.18 Mudur □ 10.19 Negroponte □ 10.20 Newell □ 10.21 Newman □ 10.22 Nievergelt □ 10.23 Ohsuga □ 10.24 Rosenthal □ 10.25 Sancha □ 10.26 Shaw □ 10.27 Tozzi □ 11. Bibliography

10.21 Some Notes on User Interface Design

William Newman

I regard Seillac-II as an opportunity to discuss one of the few remaining branches of wizardry in Computer Science, namely the design of user interfaces. I think it would be fair to say that before Seillac I, many people regarded graphics system design as another form of wizardry; the Seillac I workshop deserves much of the credit for bringing it within the grasp of ordinary mortals. Now Seillac-II is faced with the task of doing the same for user interface design. I consider this a particularly ambitious goal, for there is very little in the published literature about how to design successful user interfaces - indeed many of the leading practitioners would have difficulty explaining their success. In this respect user interface design is in a much more primitive state than was graphics system design in 1975. So it will be hard to achieve as much as we did at Seillac-I.

I think it would be useful if the Seillac-II workshop could spend at least some of its time discussing how user interfaces are designed. As a starting point for discussion, let me suggest that interactive user interfaces require four components:

  1. A user's model, i.e. the user's conceptual model of the information he manipulates and of the processes he applies to this information;
  2. A command language in which the user expresses his commands to the program;
  3. Feedback provided by the computer to assist the user in operating the program;
  4. Information display showing the user the state of the information he is manipulating.

I think this list can be helpful as a means of avoiding bad user interfaces and as a means of analyzing what is bad about them. I say this because I have found most faults in user interfaces to be attributable to lack of attention to one of these four components. A common mistake is to pay too little attention to the user's model, which then becomes needlessly complex or inconsistent. Designers also tend to ignore the potential value of feedback in reassuring the novice user; as a result the user gives commands but cannot tell whether they have been correctly received by the computer.

Thus we can use the set of four components as a check-list against which to test the user interface. We can ask ourselves whether the user's model is complex and consistent; whether the command language is simple and convenient; whether feedback provides adequate confirmation to the user's commands; and whether information is clearly displayed. Viewed in this way, the set of components does offer a methodology for user interface design. The designer's skill and experience are still, however, the most important ingredients.

I would like to discuss the list of user interface components in yet another light: portability of application programs. Our ultimate goal is to design applications that not only have good user interfaces but also are easily transported from one installation to another. Each of the four components contributes to the portability problem in a different way:

  1. User's model: this does not really affect portability;
  2. Command language: this is considerably affected by the availability of input devices. To some extent we can interchange devices if we deal with them at a logical level, but this is not a complete solution; for example, we tend to design a different command language for a tablet input device than for a set of four cursor-propelling keys.
  3. Feedback: this is affected by the capability of the output device. The essence of feedback is speed, and we tend to capitalize on whatever feedback effects we can generate quickly. On a refresh line-drawing display, for example, intensity modulation and dynamic motion can be performed quickly and are therefore useful feedback techniques; neither of them can be carried out quickly on a raster display.
  4. Information display: portability is less of a problem here, since we can use device-independent software to generate the display.

Thus we face problems principally in the areas of command language design and feedback. These problems seem severe enough to prevent us from achieving true portability of interactive programs in the near future. Where programs must be designed with high quality user interfaces, device-dependent command languages and feedback techniques will be used. Where portability is of paramount importance, user interface quality will be sacrificed.

A key question for the user interface designer will thus be: does portability matter more than user interface quality? This is a question I believe Seillac-II will have to face too, in deciding what topics to address. The question does not have a simple answer: the relative importance of portability and user-interface quality depends on the size and nature of the user community and on the degree of variation in hardware characteristics. In the past, the user community for any given interactive program has tended to be small, technically well qualified, and with a wide variety of equipment at its disposal; portability has therefore been a serious problem, and quality of user interface design has not. In the future I think things will change: user communities for applications such as CAD and office information systems will become larger and less sophisticated, and equipment will become more standardized. The need for simple, powerful, easily learned user interfaces will dominate design. This is why I feel that Seillac-II must give adequate time to discussion of user interface design methodologies.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site