Colin Beardon
Exeter School of Arts & Design, UK
Abstract
Traditional approaches to the design of
software emanate from technical practice yet, as environments come to contain
more multimedia, there is a need to appreciate the nature of creative practice.
This is not simply a matter of borrowing specific techniques but requires
a fundamental review of the design process and, particularly, the role
of prototypes and the concept of the 'user'. The 'creative user'
has particular features which lead to a different design method in which
(in a post-modern sense) the software designer releases some control over
the meaning of the software. These ideas are explored and illustrated
through the example of the Visual Assistant software developed for visualisation
in the domain of theatre.
1. Introduction
Design practice in relation to the production
of computer software has grown historically from a set of concerns that
are derived from the conception of the computer as a processor of symbols.
The development of multimedia computing during the 1990s raised many questions
about the viability of such approaches (e.g. Bjerknes & Bratteteig
1995; Crampton Smith & Tabor 1996). The present combination
of techniques for producing images and sounds, time-based sequencing and
user-interactivity presents us with a vastly more complex user experience
which requires a fundamental review of our design practices.
It is a cliché to say that 'a picture is worth a thousand words' but in the field of multimedia computing this is demonstrably true. In terms of mathematical information theory, an image file is typically about one thousand times the size of a text file meaning that it contains that much more 'information'. More fundamentally, that quantitative increase leads to a qualitative change in the nature of the information. The meanings that we assign to a detailed colour image are much more complex than the meanings we assign to, say, a boolean expression as a database search term. The visual domain generates meaning in a different way and therefore necessitates a different kind of practice, one that is traditionally referred to as 'creative practice'.
If this was true for two-dimensional images
and early multimedia pieces, how much more true it is for those animated
three-dimensional environments with interactivity we call 'virtual environments'.
Understanding them and designing them requires a range of skills and approaches
that stretches the capabilities of any designer and forces us back to some
philosophical considerations. For example, the question, what does
software mean? was examined at length during the 1970s in the attempt to
provide a sound semantics for programming languages (leading to VDM, etc.)
but this question needs to be asked again in the context of virtual environments.
Similarly, the relationship of software and system design to 'the user'
has been studied over the years mainly with respect to office based systems,
but the 'user' of a contemporary virtual environments is unlikely to operate
in a well-defined organisational context or have the performance of routine
tasks as a high priority.
2. Users and creativity
If we admit a role for creative practice
in the design or use of a system then a clearer understanding of the concept
of 'creativity' is key to the development of a sound design process.
As the word is used in many different contexts, and is in danger of overload,
I will try to be reasonably precise in my usage. For the purposes
of this study:
'creativity' is a mode of human interaction with the world that can be contrasted to a technical (or systematic) mode of interaction.That is to say, when seeking to produce something or solve a problem in the world we are faced with the option of adopting a technical strategy or a creative strategy (or possibly others). This is the first part of the description of the term; simply to describe it as a mode of interaction is insufficient and we need also to say what differentiates it in terms of its practices and values.
• to explore visual, spatial, textural and audio representation;A technical strategy, by contrast, will tend to use formalism, symbolic representations and logical reasoning; will try to eliminate ambiguity; will seek certainty and pursue correctness, completeness and detail.
• to avoid detail and value abstraction;
• to embrace ambiguity as enabling richness of meaning; and
• to bring into play our intuition and imagination.
During any significant real-world task, whether it be the proof of a theorem, the construction of reliable software, the production of an art piece, or the performance of a play, we need to employ both of these modes of interaction with the world. Given the nature of a problem, each mode may prove more or less effective at different times during the process, but a combination of the two is almost always necessary.
Creativity, by this account, is not an attribute of a few romantic outsiders (Cubbs 1994) nor a simple property of things: it is what Gilbert Ryle called a 'disposition' (Ryle 1949). If we say that some person or task is particularly 'creative' we are not saying that their every action involves pure creativity, and we are not saying that only certain people or tasks are creative. We are saying that a successful practitioner is able to operate in both creative and technical modes, and will be able to employ each ability to maximum effectiveness.
This view of creativity is shared by Margaret Boden.
Nor is [creativity] confined to a chosen few, for — despite the elitist claims of inspirationists and romantics alike — we all share some degree of creative power, which is grounded in our ordinary human abilities. (Boden 1990 p.12)Boden also argues that to be called creative, an idea needs to be quite radical,
…what must a program be like, to appear creative? [p.150]a formulation shared by other researchers (e.g. Partridge & Rowe 1994).
There is a problem with this formulation in that we are given no prior independent description of creativity to separate it from the technical formulation of the research question — the danger being that the conclusion of the research becomes limited by the original formulation. What is required is a concept of 'creativity' that is independent and empirically grounded.
The grounding of 'creativity' occurs through the concept of 'creative practice', a term which refers to what people actually do when they are engaged in this mode of interaction with the world. This is the starting point of Malcolm McCullough who is critical of technical ways of describing creativity.
…many recent studies of creative computation have confined themselves to decidable methods in symbolic processing. Despite the loss of certainty having been demonstrated even in mathematics, orthodox academics in countless disciplines hold fast to deterministic knowledge. It is as if scientism is the only way to legitimate creativity. (McCullough 1996 p.104)McCullough uses the term 'creativity' sparingly, opting instead for the notion of 'craft' within a digital context. This choice of words signifies that, when dealing with creativity on its own terms, we should focus on working methods and practices, not on products or people.
Adopting such an approach leads to a very different research question:
Is it possible to employ technology in order to assist the (human) processes of creativity?It is this question which guides the development programme described in this paper and the wider considerations of design issues.
3. Software for creativity
Sadly, for the majority of people involved
in creative practice the computer has become associated predominantly with
routine practice; a situation reflected in the cliché, The computer
is only a tool. Seeing the computer in this way associates it with
technical practice and the consequences are quite negative.
[The computer] begins to draw by starting from the details: ‘No detail, no design.’ The order is inverted: you no longer follow the age-old method which used to consist of working up a rough idea, going on to the sketches — introducing precision step by step — and arriving at the details at the end of the process. The detail ... is required right from the start, during the preliminary phase: the natural order is inverted. (Parent 1995 p.93)
Using computers for routine, technical
tasks is seen in opposition to creative problem-solving,
I have observed that when students are
allowed to initiate the problem-solving process on screen, they spend unrewarding
hours dragging forms around the screen and not evolving an idea.
They are simply rearranging it. (Morin 1999)
and the technology becomes quickly restricted
to performing purely technical tasks.
In contrast, a recent UK Arts Council report argued that multimedia can be used to liberate creativity. Comparing multimedia to drama, it said that
…multimedia can act as a similar servant to the curriculum, in that it offers a means to explore other subjects in an imaginative and motivating fashion.The Report also identifies specific general skills which creative multimedia can help to develop…
…working in groups; the value of pre-production planning; the fact that students traditionally excluded from our educational system can participate; the high premium placed on discussion, decision-making and negotiation; the fact that other core skills (for example, numeracy, design work, keyboards) are used in the production; and finally the fact that the product can be displayed and used by a peer audience. (Sefton-Green 1999)
Normally, creative practitioners have
a sophisticated relationship to their tools and their reduction of computers
to routine tasks indicates a significant design issue which needs to be
understood. Tools help define a medium within which users can create
work. In this context, the notion that there should be one all-embracing,
complete, coherent and purely technical tool is highly questionable.
Within each creative practice people will ensure that they use a variety
of objects as tools, and simple tools (e.g. a pencil) often create a rich
medium within which expressive ideas can be realised. This may be
the reason why one designer-maker has expressed a preference for early
versions of software products, finding that as the product becomes more
embracing and consistent then it becomes less useful for creative practice
(Beardon et al 1997). The technical values of completeness and consistency
may work counter to the needs of the creative user.
Within the craft (or 'designer-maker') tradition uncertainty can also have benefits. The wood carver, David Pye, drew the distinction between the “the workmanship of risk” and “the workmanship of certainty”. In the workmanship of risk “the quality of the result is continually at risk during the process of making”, whereas in the workmanship of certainty “the quality of the result is exactly predetermined before a single saleable thing is made” (Pye 1986). Pye held that the workmanship of risk was essential to creative craft practice and can be read into the products by the knowledgeable observer. We may go further than this and say that it adds to the 'aura' and even to the value of the created object.
Such opposition to the technical values behind much software leads some artists and designers to adopt a distinctly 'subversive' attitude towards the software they use. For example, one artist has written
…it is up to the artist to subjugate the program by subverting the deliberate short cuts written into it, which have been designed to make the lay user feel as if they can obtain the same results as an artist. (Stocker 1995)
These bold assertions of the values
of creative practice indicate that the radically 'new' is unlikely to be
generated by clever variations of the technical but, rather, by creative
human beings re-possessing and re-interpreting the technically designed
products they are presented with. Allowing for user involvement within
a technically-driven design paradigm is one possible model for user participation,
but from the standpoint of creative practice the possession and redefinition
of software tools is already happening. Ultimately, as we shall see,
it is not the software designers but the users who need to decide what
software 'means'.
4. Software specification
To be 'novel' or 'radical' is a necessary,
but not a sufficient, condition for calling something creative. As
Partridge and Rowe point out, it also needs to be 'appropriate' in some
sense (Partridge and Rowe 1994 p.7). Umberto Eco addresses this issue
in The Open Work (Eco 1983). In the chapter entitled Openness, Information,
Communication, Eco attempts to relate the aesthetic concept of the 'open
work' to mathematical information theory. There is a clear tension
between the modernist framework within which we are accustomed to consider
that theory, and the postmodern view that meaning is (at least partly)
created by the user or the audience. Eco resolves this tension by
describing the open work as 'potential':
This tendency towards disorder, characteristic of the poetics of openness, must be understood as a tendency toward controlled disorder, toward a circumscribed potential, toward a freedom that is constantly curtailed by the germ of formativity present in any form that wants to remain open to the free choice of the addressee. (Eco 1983 p.64-65)
A similar analysis is provided by Pierre
Levy in his formulation of the 'virtual' as being opposed not to the 'real'
but to the 'actual'. Virtual objects, Levy argues, have a 'real'
(e.g. material) existence but they differ in that their full potentiality
has not yet been actualised or 'realised' (Levy 1997). The comprehension
of that potential must occur through some 'code', be that formal, scientific,
metaphoric, or whatever.
As computing tends towards multimedia and virtual environments we must become increasingly aware that software produces a rich cultural meaning. Furthermore, environments that intend to support creativity must ground their meaning within a post-modernist perspective. The meaning of a virtual environment no longer resides entirely with the designer of the product, but significantly with the users. To restate this in a different frame of reference, we might say that the task of the environment designer becomes to create a 'code' (or a 'language') within which other people (the 'users') can make interesting statements.
This means a shift in the traditional role of the 'user' with respect to the computer-based system. Traditionally, users have been seen as operators of a machine very much within the Taylorist model of the division of labour. The user had a precise task to perform and the computer performed some proportion of that task, with the human user performing the remainder. There was essentially no difference between the two types of activity as both were defined functionally. An alternative simile to the machine-and-operative is that of the composer-performer-audience. Here the software designer can play the creative role of composer and the software product becomes likened to the musical score. The 'user', in this version, is compared to the musician or musicians who make something that can be experienced. A third group (sometimes referred to as the 'usees') can be compared to the audience who (hopefully) appreciate the object thus created.
The processes whereby we specify, develop and evaluate software thus conceived are significantly different from those commonly accepted for more traditional software (see Beardon 1999). In essence, the designer must first reach an understanding of the 'language' in use within the field of practice and then design a novel code for the (partial) expression of this. This code is then embodied in a piece of software which is presented to potential users as a medium but without a clear steer as to what it might be used for. I have referred to this process as 'put-it-on-the-table' design. This is, of course, an idealised model but it can be taken as an alternative to strict task-oriented approaches to design. Through a process of development, evaluation, reflection and redesign the product not only evolves in a broad context of use, but the real meaning (or potential) of the product becomes better understood by all involved.
Software environments developed in this
general way will need to take care in their initial formulation.
In general, they will want to present an accessible, believable and relevant
code but the software also needs to define a new medium within which people
can work creatively to advantage. When it comes to evaluation, the
aims of such software should be clear: for example,
• to be useful for creative problem-solving
activities (rather than for detailed technical description);
• to function as a means to support critical
person-to-person dialogue about the creative product;
• to be judged by any improvements in
the creative process (rather than by the intrinsic quality of its own outputs).
5. The Visual Assistant: the design
of a virtual environment for visualisation in theatre
Many of these ideas have evolved over
the past six years during which time the author has been involved in a
continuing project to design and develop software for visualisation within
the context of theatre (the Visual Assistant). It is always possible
to present the design of software with the benefit of hindsight as an example
of functionally-driven design. As two software engineers have described
it,
The preceding describes the ideal process that we would like to follow and the documentation that would be produced during that process. The process is 'faked' by presenting the documents that would have been produced if we had done things the ideal way … No matter how often we stumble on our way, the final documentation will be rational and accurate. (Parnas & Clements 1986).For some purposes such a description might be valid, but in an article on design methods such 'faking' would be dishonest. If at the outset of this project I had ideas about the advantages that the software might eventually provide, they at considerable variance from the advantages that have been achieved. In presenting this account it is therefore important to present the sequence of issues as they arose and this I will attempt to do.
The first discussions took place within the HaMLET project team where a number of fundamental aims were established. The environment was to provide a means for visualisation within the domain of theatre and it should relate to the needs to both theatre professionals and those in theatre education or training. It was to be concerned with communication over long distances — both how professionals may collaborate without being in the same physical location, and how theatre education might take place at a distance. As an EU-funded project, it was to address the issues of different cultures within Europe (especially different theatre cultures). It was also to recognise the existing working practices of theatre practitioners, and acknowledge that they have no particular liking for computers or willingness to overcome large initial difficulties in the interests of some potential longer-term gain. In short it had to develop with the approval of working practitioners.
Most fundamental, though, was the recognition that theatre is itself the 'virtual environment' par excellence.
…the theatre puts one or two objects on a planked wooden floor, throws light on them, and asks the audience to believe they are seeing, let us say, ancient Rome. (Hall 1989)The main challenge behind the VA project was to devise an environment that works alongside such creativity: one that complements human creativity rather than attempting to replace it.
The complexity of existing software for modelling 3D environments, plus a tradition that can use only a few props to imagine a rich world, led to the exploration of a new 'code' for theatre visualisation. This code aimed to utilise the relative abundance of 2D images and the simplicity of manipulating them with computers. The challenge became this: would it be possible to develop a code for the arrangement and manipulation of 2D images within a 3D space that was both simple to use and rich enough for theatre practitioners to explore or develop their imagination? And, having done so, would the result be of any particular creative advantage with respect to their final theatrical productions?
The VA environment attempts to address these issues by combining both 2D and 3D representations in a manner that reduces the complexity for users while providing an extension of the techniques of sketching within a 3D environment. In order to do this it was necessary to abandon traditional 3D representation based upon the geometry of light and to utilise a different representational convention. The most obvious for our purposes was collage, wherein discrete objects are juxtaposed. The cultural traditions of collage, particularly in enabling the appropriation and reinterpretation of culturally bound images, led to a degree of enthusiasm for this approach.
In addition to a new 'code' based around
the vague idea of '3D collage', it was also necessary to aim for simplicity
of use. In particular, the design aimed to,
• be immediately accessible: ideally users
should be able to see someone else using it for 10 minutes and then confidently
use it themselves;
• enable users to produce meaningful results
quickly;
• avoid being over-complicated: in particular
the number of functions should be limited to about 40;
• produce results which support peer group
discussion;
• produce results which can be communicated
over a distance.
The resulting software is not large or
complex and some readers may question it being called a 'virtual environment'
at all. It contains about 15,000 lines of C code and will run in
8Mb of RAM, producing only standard VGA output (for details of the software
see Appendix 1). By working with the users' imagination I have attempted
to provide a contribution within a particular domain which owes much to
the appropriate technology movement (but that is the topic of another paper).
Significantly, from the user's point of view there is a sense of involvement
and users have shown a preparedness to use the 'virtual environment' I
have built and to read the output from it as a representation of another
imagined 'virtual environment' that they will create on stage.
6. Usage, evaluation and meaning
in context
The process of development, implementation,
usage, reflection and re-design has been long and intermittent. Many
of the design and evaluation methods employed in software development have
had to be reviewed. In particular, the roles given to prototyping
and usability testing.
While prototypes of virtual environments can have some use, in testing formal relationships for example, they are inappropriate for testing more holistic features. I recall an occasion where students created a mock-up of an interface in order to explore underlying functionality. They created the boxes that were to contain information and then wished to indicate the absence of a visual design, so they printed the boxes and applied a rough watercolour wash for the remaining areas, scanning this compound image for use in the prototype. The users of this prototype were fascinated by the watercolour wash effect, to the extent that they expressed little interest in the formal aspects. The single useful outcome of the prototyping exercise was that this visual effect should be retained. While the intention of using it was to neutralise the visual aspect, the users could only read it as part of the proposed design.
Once it is accepted that multimedia and virtual environments use complex ways to convey meaning, building a prototype that neutralises certain aspects is a problematic activity — every pixel, every delay, every sound may be relevant. Creative practitioners, if they retain their traditions, will be very sophisticated readers of software and will tend to see everything as a potential finished product. Consequently, it is difficult for the software developer to present users with prototypes (something that might have been predicted as the true meaning of the software, and hence control over parts of that meaning, have yet to be resolved). The question needs to be reformulated: in what sense is it possible to have a 'prototype code'? The answer is that it is not possible, but it is possible to have a simpler, or in some sense 'incomplete code', and that is probably the direction in which prototyping for this kind of environment should go.
One of the techniques for user involvement during a prototype-driven design method is usability testing (Dumas & Redish 1994). This is a product-oriented procedure that addresses the viewpoint of the user by involving a group of typical users at each stage in testing through the performance of real tasks. As a technique it is usually based around the assumptions that the software will perform a particular pre-defined task and that the computer will function as a well-defined symbol-processor and it does not take into account the specifics of multimedia computing or creative practice. If forced to describe the task of the VA software, it would be "to provide a novel code within which creative things may be made". This would not get us very far with traditional evaluation techniques.
To adapt usability testing to the creative domain we must first accept that the meaning of a software product will only be determined though use. The development method therefore involves creating sample products and seeing how they may be used, thereby generating meaning. We build upon the greatest areas of success and need, and reduce those areas which are least successful (in order to keep the overall functionality within limits). Like any living language, it must evolve to match the community's needs.
Early versions of the Visual Assistant were used by members of the HaMLET project, principally educators, professional theatre directors and scriptwriters. At this stage there was still a tendency to think of the software as a device for creating prototype set designs. The comments of these potential users corrected this: the VA was seen to be good at allowing the imagination to flow, at creating an atmosphere rather than a detailed model, at suggesting the environment within which actors can perform, and at providing a way in which textual and visual notes can be combined in a hypertextual way.
Further significant understandings and developments were derived from a series of workshops held in 1998 and 1999. In October 1998 the VA was used in a workshop at Malmö University College, Sweden with a group of 18 students for five working days. The VA was used as an environment for imagining scenes from Strindberg's A Dream Play and we were able to hold several plenary sessions at which progress was discussed. It became immediately apparent that projecting the image, rather than viewing it on a monitor, brought about a qualitative advance in understanding the output in the context of theatre space. Furthermore, the ability to manipulate the model, both in the VA and in a VRML browser, led to peer group review sessions that could pursue alternatives in real time. There was a positive sense of the technology residing in the background, yet supporting an intellectual discourse about the realisation of the play.
Figure 1. A design for A Dream Play
Created by students at Malmö
University College, Sweden using the Visual Assistant.
Viewed using Cosmoplayer plug-in.
In May 1999 a three-week workshop was held at Central St Martin's School of Art, London Institute involving about 12 students from the second year of the Set Design degree course. The objective of this exercise was more abstract: to imagine a dramatic moment in Bruckner's play Woyzech. In addition to working within the Visual Assistant, students were also asked to develop their designs into working set design models using Chris Dyer's virtual_Stages software (Dyer 1999).
With more time, students developed more complex ideas and began to use the VA in different ways. For some, the number of images was still limited but more care was been taken over the quality of images. For others, it gave the opportunity to represent a large number of objects (e.g. a crowd) and to explore issues concerned with movement. Another student was able to produce designs with a truly architectural quality. Yet another became interested in the potential of collage in terms of the real set design.
A video projector was only available at the end of the project and this was the only time that group discussion could occur. Nevertheless, the ability to project images and manipulate objects in real time led to some interesting discussions. Questions of scale became apparent (set designs without a human figure are difficult to scale), as well as the potential of rotating stages, and of the effect of changing colours. Issues such as these were discussed in the presence of live manipulations.
Figure 2. A design for Woyzech
Created by a student at Central
St, Martin's School of Art & Design, UK .
Created and viewed using Visual
Assistant..
In February 1998, and again in February
1999, the VA was used at the University of Plymouth with a group of about
40 first year Theatre and Performance students. This is a more general
Performing Arts degree course, typical of many currently offered in the
UK. These courses face some fundamental issues concerning contemporary
culture. For example, theatre education, though essentially about
doing things, is dominated by words and the visual, spatial and action-oriented
nature of it are often underplayed. When it is visual, our culture
tends to be two-dimensional (e.g. magazines) and many people have difficulty
imagining three dimensional forms and spaces. Television, while addressing
some of these issues, creates an expectation of close-up photography, yet
stage drama requires full-body representation. For a fuller discussion
of these issues and the potential of the VA in helping address them see
Beardon and Enright (1999).
7. Discussion
During the design, implementation, evaluation
and use of the VA I have felt that I, as a software designer, have made
an important transition from a technically-oriented software designer (i.e.
a computer scientist) to a designer-maker of software (i.e. a craft worker).
The full implications of this transition are not yet clear for sometimes
there is a definite need for technical skills, but the main thrust of it
lies in a revised design philosophy. I am working with a user community
in a creative interaction, where my creative skills are being employed
to understand their domain at some deeper level and to posit, in software
form, some new reality/code within which they may themselves become more
creative. This has required a major re-think of design practices
and a merging of technical software design and designer-maker practice.
Software designers are now facing a dilemma
as users adopt an increasingly creative role. As designers they must
accept responsibility for the use of their software (it is not acceptable
to excuse themselves by claiming their software was used 'improperly')
yet they must delegate some responsibility for its meaning to the users.
This is a major ethical issue in the design of virtual environments.
The design of the VA has, I hope, begun to open up some of the issues involved
in this dilemma, but there is still some way to go before our understanding
is commensurate with the task before us.
Appendix 1. The Visual Assistant
software
The main features of the Visual Assistant
(VA 1.5) are as follows.
• The user is presented with an imaginary
three-dimensional space, the lower surface of which is referred to as the
'floor'.
• There is a front viewing position which
is central and at a fixed distance from the nearest side. There is
a top viewing position directly above the centre of the floor, which thus
appears as a square.
• The VA's window will always be the maximum
size for the monitor used and the space is scaled onto the monitor to enable
smooth updating while minimising the size of the clip rectangle.
• Existing 2D images can be brought into
this space from files and common geometric shapes can be created directly
within the software. There is also a 'sketching' facility to enable the
drawing of pictures which then exist as separate objects within the space.
There is an eraser which can be used on any image.
• A range of image and object manipulation
tools are available (e.g. resize, flip, pattern, colour, group, text notes).
• Four degrees of freedom are adequate
and reduce complexity. It is sufficient to move objects along three
axes and to rotate objects around the y-axis only. Two separate move
operations are used: move (x and y axes ) and move-deep (x and z axes).
Move deep and rotation about the y-axis take place in top view.
• Images can be enlarged onto the floor
of the space and can be made to fill the rear or side walls of the space.
Masks are provided for different shapes of floor.
• Light and shade are under direct control
of the user both at object and scene level. Scene lighting is represented
by a two-dimensional light filter, allowing control over the shape, colour,
contrast, diffusion and location of the light.
• Animation is available through twenty
time slots: amendments to a scene take place at one of these slots.
Each slot is taken as a keyframe and in-betweening occurs when the animation
is shown.
• Saved folders include both a VA specific
file plus a VRML version of the model. The VRML version can be viewed,
on- or off-line, by using a VRML plug-in to any Internet browser.
The Visual Assistant currently runs on
Apple Macintosh computers only. A PC version is under development
and should be ready soon. Check the project's web-site <www.esad.plym.ac.uk/va/>
where free downloadable versions are available. The Apple version
currently occupies under 600K of disk space, making it transferable on
floppy-disk if desired. To run it needs 8Mb RAM. The current
version of the VA (1.5) runs on any PowerPC or G3 processor but will not
work on the older 68000 series models (Classic, LC, Performa). Graphics
performance will depend upon processor speed and VRAM (233 MHz with 4Mb
VRAM seems to work acceptably).
References
Beardon, C., Gollifer, S., Rose, C. &
Worden, S. (1997) Computer Use by Artists and Designers: Some Perspectives
on Two Design Traditions. In: Kyng, M. & Mathiassen, L. (eds.)
Computers and Design in Context. MIT Press, Camb, Mass. pp. 27-50.
Beardon, C. (1999) The design of
software to support creative practice. Proc. IDATER 99 Conference,
University of Loughborough, August, 1999.
Beardon,C. & Enright,T. (1999)
Computer-based improvisation: some experiences of using the Visual Assistant
in teaching. Digital Creativity 10(3) 153-166.
Bjerknes, G. & Bratteteig, T. (1995)
'User participation - a strategy for work life democracy?'. In Trigg,
R., Anderson, S.I. & Dykstra-Erikson, E. (eds.) PDC’94 Proceedings
of the participatory design conference, Chapel Hill, NC, 27-28.
Boden, M. (1990) The Creative mind: myths
& mechanisms. Weidenfeld and Nicolson, London.
Crampton Smith, G & Tabor, P. (1996)
The role of the artist-designer. In Winograd, T. (ed.) Bringing
Design to Software. Addison-Wesley, Reading, Ma. pp. 3757.
Cubbs, J. (1994) Rebels, mystics, and
outcasts: the romantic artist outsider. In Hall, M.D. & Metcalfe,
E.W. The artist ousider: creativity and the boundaries of culture.
Smithsonian Institution Press, Washington, 7693.
Dyer, C. (1999) Virtual_Stages: an interactive
model of performance spaces for creative teams, technicians and students.
Digital Creativity 10(3) 143152.
Eco, U. (1983) The open work, trans. Cangoni,
A., Harvard University Press, Camb, MA.
Hall, P. (1989) Introduction.
In Goodwin, J. (ed.) British Theatre Design: the modern age. Weidenfeld
& Nicholson, London.
Levy, P. (1997) Welcome to Virtuality.
Digital Creativity 8(1) 310.
McCullough, M. (1996) Abstracting
craft: the practiced digital hand. MIT Press, Camb, Mass.
Morin, J. (1999) Integating technology
into a problem-solving curriculum. Unpublished paper presented at
ICFAD 99 Conference, Auckland, 8-13 October 1999.
Parent, C. (1995) Senso inverso
o senso vietato? Spaces and Society, Jan/March 1995, 91-93.
Parnas, D. & Clements P. (1986)
A rational design process: how and why to fake it. s 12(8) 251257.
Partridge, D. & Rowe, J. (1994) Computers
and creeativity. Intellect, Exeter.
Pye, D. (1986) On Workmanship.
In: David Pye: Wood Carver and Turner. Crafts Council, London.
Ryle, G. (1949) The Concept of Mind.
Penguin Books, Harmondsworth, UK.
Sefton-Green, J. (1999) A framework for
digital arts and the curriculum. In Sefton-Green, J. (ed.) Young people,
creativity and new technologies: the challenge of digital arts. Routledge,
London, 146154.
Stocker, G. (1995) Artist's statement.
In: Worden, S. (ed) Digital Creativity CD-ROM. University of
Brighton, UK.