Position Paper for Ger Koelman
Hollandse Signaalapparaten B.V. Tel: +31742483433
Zuidelijke Havenweg 40
7554RR Hengelo (Ov)
As a subsidiary of the French Thomson CSF, Hollandse Signaalapparaten B.V.
in Hengelo, the Netherlands develops Radar Equipment and Naval Command
and Control Systems for Navies around the world.
A Command and Control System is a multi-user (5-15) real-time distributed
system, consisting of hundreds of applications with an interface to the
end-user. For each user a number of these applications have to co-exist
on one or two display screens, via which the user has to fulfil his various
Software for Command and Control Systems is often time- and life-critical
and puts a very high strain on the aspects of reliability and usability.
These aspects have to be secured in very large software dominant projects
that are realised by large development teams. Nowadays these teams are
often international and geographically divided. This makes managing the
quality and consistency of the User Interface being developed very difficult,
because every company uses its own experience. Up till now we have tried
to manage these aspects by writing extensive style guides and HCI design
guides. Practice however has shown that without the accompanying experience
of a real expert, these documents prove to be less valuable than they could
be. The accessibility of the documents is too low and the amount of rules
and guidelines is only overwhelming for the average HCI practitioner. It
does not contain / reveal the underlying knowledge of experienced HCI designers.
From this point we started to realise that describing this ‘knowledge’
in the way Gamma does for Software Design patterns, might be the key to
Amongst many other activities in our HCI experts group, in 1998 we had
a research project, during six months, on the subject of Design Patterns
for User Interfaces. From this study we have drawn the conclusion that
in our situation, HCI Design Patterns would be of great use. It would enable
us to use expert experience and knowledge from others, record our own experience
and knowledge, and it would provide us with a language to discuss HCI design
Own HCI experience
From 1985 up till now I have been working as a system engineer in the field
of Human-Computer Interaction. Before that period I have been a software
engineer for four years. For a summary of the various activities see the
chronological list below:
1885 - 1986
- Specification and implementation of alphanumeric interaction screens.
1986 - 1988
- Exploration of suitability of evolving graphical standards like GKS,
- Exploration of suitability of WIMP interfaces (for Naval C&C
1988 - 1990
- Specification of software capabilities of a Multi-Function Operator
- Functional analysis and specification of system software functionality
in relation to user’s tasks.
1991 - 1992
- Design and specification of corporate GUI style components.
- Evaluation of GUI development libraries and tools.
- Development of a specification method for User Interface Design
- Design and specification of corporate GUI design tools.
1992 - 1995
- Lead GUI designer for an internal ‘first-of-class’ project.
- Lead GUI designer for 4 external projects.
1995 - 1997
- Team leader of an HCI team for a multi-company, multi-site software
- Specification and guidance of the HCI Development Process, Style
Guide, Design Guide as well as the
conceptual HCI design for the above project.
1997 - 1998
- User Task Analysis
- Evaluation of GUI and components based development tools
- Conceptual Design of the next generation of Graphical User Interfaces
for our C&C Systems.
- Supervision of the research project on HCI Design Patterns.
1998 - now
- Object-oriented User Interface design and integration of usability
techniques and processes
into the software development lifecycle.
Status on HCI Patterns
During our research project on HCI design patterns, for us important steps
are made to take the User Interface design process to a higher level. The
existing knowledge on patterns, especially from outside our company, is
examined and a referential structure has been set up for the use of patterns.
By specifying a number of design patterns, both domain specific and generic,
we enhanced our understanding of design patterns.
Highlights of our findings:
1. During the literature study for this project, we were struck by the
similarity between the architectural design patterns of Alexander, and
the subjects that are dealt with in user interface design.
The hierarchical structure as used by Alexander can be translated to the
User Interface domain levels of design:
City - System
Group of buildings - Screen with applications
Single building - Single Application
Room inside building - Application (sub)window
(this one we added ourselves)
Each of these levels describes a number of steps that lead the designer
through the decisions he has to make.
Every design pattern is related to one specific step. The patterns
themselves refer to relevant patterns of the other levels.
Also regarding abstraction levels, we can learn from Alexander. Patterns
are arranged in levels, but also these levels are structured:
The first steps in a level create structure, as do the related patterns.
So the designer is ‘forced’ to apply structure first. The last steps in
a level are for beautification. They provide decoration for the chosen
structure and the chosen implementation. Beautifying patterns are much
more concrete than structuring patterns.
We can compare this also with the difference between design rules and
Analogy in patterns:
Many of Alexander’s design patterns can be translated directly to the HCI
design by simple analogy.
2. We have investigated the relation between user task models and HCI
design patterns. Although we strongly have the impression that task structures
and task types could add to bridging the gap between Task Analysis and
HCI Design by relating HCI Design Patterns to them, we still couldn’t come
up with examples that are generic enough for general applicability. The
idea was to identify generic task structures for generic task types like
Monitoring Task, Search Task, Verification Task, Control Task, etc. The
next step would be to find generic solutions / designs for these types
of tasks and document these as design patterns.
3. When design patterns are structured as described in point 1 above,
documenting them in a hyper-linked structure makes the pattern library
(Near) Future plans:
We are planning a more extensive project on the subject of HCI Design Patterns,
in order to develop an interactive HCI design guide. This guide will be
a companion while designing user interfaces and will provide novice as
well as experienced designers with expert knowledge and experience. It
will show solutions to problems, alternative solutions and designs, relations
with other relevant patterns and the essential decisions to be made by
the HCI designer during the process of design. Example solutions (implementations)
could even be interactive demos.
Additional discussion topics for the Workshop
How do HCI Patterns relate to User Task Structures, Task Types and Task
How to deal with corporate (domain specific) HCI Patterns?
What hierarchical structures/levels/steps apply to HCI design patterns
as compared to Alexander’s levels?
What could be the relation between HCI design patterns and Component Technology?
Should we search in a pattern library based on The Problem, The Solution,
A position paper prepared for the Usability
Pattern Language Workshop at Interact