Cultivate Interactive Home Page *
*

Search Disabled

  Home | Current Issue | Index of Back Issues
  Issue 5 Home | Editorial | Features | Regular Columns | News & Events | Misc.

Creative Practices and the Design of Virtual Environments

By Colin Beardon - October 2001

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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.

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.
Creative practice tends:

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.

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,
A merely novel idea is one which can be described and/or produced by the same set of generative rules as are other, familiar ideas. A genuinely original, or creative, idea is one which cannot. (Boden 1990 p.40)


This leads her to a very specific research approach, based around the question,

…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.

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'.

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,

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,

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.

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
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
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).

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 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 [1] 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

  1. Visual Assistant Web site
    URL: <http://www.esad.plym.ac.uk/va/> Link to external resource


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. 37­57.
 
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, 76­93.
 
Dyer, C. (1999) Virtual_Stages: an interactive model of performance spaces for creative teams, technicians and students.  Digital Creativity 10(3) 143­152.
 
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) 3­10.
 
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) 251­257.
 
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, 146­154.
 
Stocker, G. (1995)  Artist's statement.  In: Worden, S. (ed)  Digital Creativity CD-ROM.  University of Brighton, UK.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Author Details

Colin BeardonColin Beardon
Exeter School of Arts & Design, UK

su1620@eclipse.co.uk Link to an email address
http://www.plym.ac.uk/ Link to external resource

Colin Beardon is Professor of Arts & Design at Exeter School of Arts & Design, University of Plymouth, UK and a Visiting Professor at the School of Arts & Communication, Malmo University, Sweden. He has an academic background in philosophy and computer science and for the past eleven years has been researching into various aspects of communication using multimedia and the design of digital technologies to support human creative practices.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

For citation purposes:
Beardon, C. "Creative Practices and the Design of Virtual Environments ", Cultivate Interactive, issue 5, 1 October 2001
URL: <http://www.cultivate-int.org/issue5/creative/>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Related articles:
If you would like to view similar articles to this one click on a key word below:

< - design - user - >

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -