School of Information Management
University of Brighton
[Thread: structuring frameworks for HCI Pattern
The last five years has seen a growing interest in the possibilities for Design Patterns in the domain of human computer interaction. Some practitioners, perhaps taking their lead from trends in pattern usage in the Object Oriented Software Engineering Community, have been mostly interested in uncovering individual problem-solution linkages and writing them up as patterns. Indeed given that the development of HCI patterns is on its early stages, this may be the most practical way to proceed. However, when Alexander described his architectural patterns, it was not as a flat list of 253 items, but as a hierarchical "language" where one pattern directed the reader to lower level patterns, rather like the kind of grammatical rewrite rules familiar to us from transformational grammar. This hierarchical structuring is tremendously powerful, since not only does it enable easy retrieval of individual patterns but it also contributes to the generative force of the patterns, as each pattern shows the sub-patterns required to resolve more detailed design issues in the context of the larger design. In the HCI domain, several "sub-languages" for specific domains are being developed, for instance for Web applications, visualisation software, robot control systems, music applications and control room software. However, they are like pieces of a large, ambitious but rather anarchic patchwork quilt that at the moment has no overriding structure to it: small patches are filled in but large areas remain blank. Individual sub-languages do not draw on others, which leads inevitably to redundancy as each pattern writer creates a different pattern for more or less the same phenomenon. Perhaps more importantly, there is no sense of the scope of the general pattern language writing project and therefore no public agenda for future efforts in pattern writing, as the impetus to produce pattern languages arises from either personal or organisational interest in a specific corner of a larger domain.
In this paper, I would like to explore the idea that genre may be a useful conceptual tool for structuring interaction design pattern sub-languages, allowing links to be perceived and providing a sense of the scope of the territory to be mapped. After briefly describing current theoretical understandings of genre in its home discipline of applied linguistics, I shall consider the applicability of the concept to the software domain and explore how individual pattern languages already developed might usefully be connected using the genre concept.
Genre Theory and Software
The term "genre" is used in an informal sense to refer to types of artefact in areas such as painting, film, television and literature: still life paintings, spaghetti westerns, soap operas and detective novels would all be seen as genres. It may be useful, however, to use a more formal and demanding notion of genre developed by researchers in Applied Linguistics, where it is used to describe recurring types of linguistic communication event. Swales (1990) sets out a number of features of these "real-life" genres:
What would the advantages be?
Genres have evolved in human-human communication because they deliver a number of benefits, some of which affect designers/writers of communication artefacts and some of which are more relevant to users/hearers/readers.
As far as software genres are concerned, the designer’s task is made easier if s/he recognises that s/he is operating within a set of constraints imposed by previous programs of the same type. The sensible designer investigates previous examples of software genres before embarking on a design task. In addition, a shared understanding of the features of a software genre can facilitate communication in the design process, whether this is between users, clients and designers or simply within the design team. However, at present the designers’ knowledge of the implications of genre membership is largely tacit and ad hoc. There is no set of agreed functions for spreadsheets, authoring environments of word processors, nor is there a tradition of critical analysis of examples of software that would help in the recognition of such features. The development of design patterns for each genre could be a useful way of packaging this knowledge. This is the "what" of design, i.e. the set of features a piece of software should incorporate.
As far as the design process is concerned, effective solutions to recurring problems can be expressed via patterns, constituting the "how’ of design, i.e. the approaches which make the required features available to the user in a fluid and natural way. This sort of re-use is of course one of the major attractions of design patterns in general. A particularly useful advantage in identifying a proposed piece of software as an implementation of a particular genre is the strong possibility of re-use via the inheritance mechanism, made possible by existence of the hierarchical structuring of software types into genres and sub-genres (of which there may be several layers. A piece of software which is an example of a sub-genre, such as an e-commerce Web site, will be subject to the patterns that refer to Web sites in general and to e-commerce sites in particular. This holds out the promise of an efficient structuring of design patterns, with no little or none of the current redundancy.
As far as consumers of both communicative and software genres are concerned, recognising that a text or a program is an example of a particular genre is an enormously powerful aid to learning and understanding. Someone who has used one Web authoring program, for instance, is in a strong position when confronting a new, different Web authoring program, as the same (tacit) patterns will be at work in the design of both. More powerfully, that individual will also be in a strong position when faced with, say, a multimedia authoring system, as the two sub-genres share a common ancestor, the authoring system, from which they inherit many features.
This has simply been a brief discussion of the notion of genre and a set of suggestions about some of the potential advantages of using genre to map the space of HCI pattern languages. The substantive work remains to be done. This will involve: