Abstract
I present a vision for the integration of art in software design. The perspective is to support evolutionary application development with end users as active participants. A step towards this is component-based design. The paper starts by identifying some issues involved in component-based design by showing examples of how some everyday objects (e.g., bicycle wheel, urinal, coat rack) have be reused and redesigned in fanciful ways. A set of concepts and techniques for radical tailorability of software systems (i.e., software readymades) is proposed.
Introduction
This essay examines two areas of design, an art discipline and component-based software development, respectively. I argue that they merit comparison and even cross-fertilisation. The two areas are 'readymades' (seen as art objects) and software components (seen as readymades). A commonality between the two and a basic premise of this essay is that the unit of design is a 'mass produced' and 'ready to hand' object that everyone (both young and old) can relate to. These characteristics are examined in some detail and ideas from readymades are reused in order to propose new concepts and techniques for software design.
Marcel Duchamp coined the term 'readymade' to explain the activity of making everyday objects art objects by certain operations performed by the artist. These operations were different from what most people associated with artwork. The end results were new objects only slightly different from the originally purchased objects, but after Duchamp's operations more fit for a museum rather than as tools for practical work (i.e., as originally conceived by their manufacturers).
Software components and component-based design have received much attention in the software engineering and application development communities over the past 5 years. Software components allow systems to be built by starting from high-level reusable building blocks instead of writing program statements in a general purpose programming languages. A goal of this approach to systems development is to find new ways of shortening the (often costly) software development cycle, to stimulate programmers to reuse each other's assets, and to make it more practical to include end-users in systems development.
Although there are similarities between readymades and software components, there are differences we need to identify before we embark on a closer analysis. Readymades is strictly not a design concept, but an approach to disassemble, reuse, re-arrange and extend already manufactured objects. Software components are parts to be assembled with other components in order to create new software systems. However, both approaches consist of ready-to-hand objects as the basic unit of design.
Readymades as art objects
Duchamp coined the word readymade by selecting manufactured objects from manufacturer’s catalogues and calling them art objects even though they were not his own creations. His operations were simple: choose certain objects, label them by a serial number and sign them by a short sentence to aid to the spectator (see the Fountain). In other cases it meant to take existing objects, taking them apart, and reassembling them in new ways to form radically different artifacts (e.g. stool and bicycle to create a bicycle wheel).
Duchamp's role as artist consisted in selecting existing objects he found 'interesting' and of presenting them as art. Since the world was already so full of interesting objects, why did one want to add to them? Instead, the artist could just pick one, which should be a choice of mind rather than the work of hand. Naturally, this way of working scandalised critics in the early part of this century.
Although Duchamp's readymades are only slightly modified versions of manufactured objects they have been carefully chosen and given radically new meanings (i.e., they can no longer be used as originally intended). In this way the readymades make us aware of aspects of everyday objects we normally do not attend to when we use them in our everyday activities. They serve instead as a counterexample: pointing out what an object is not.
The readymades not only shocked the critics, but they also challenged the conventional way of presenting art, e.g. as hanging on walls. Duchamp’s readymades were not placed on walls, but hung from the ceiling or were nailed to the floor, as shown in Figure 3.
Figure 3: The artist's studio in New York 1916-17. The urinal, hat rack, and snow shovel are hanging from the ceiling. A coat rack is nailed to the floor (not visible). None of the objects are directly accessible for use. A complex web of thin wire-frame integrates some of the readymades.
Duchamp's pictures and diagrams were 'snapshots' of existing physical objects and presented from different viewpoints. He put great emphasis on the time and date of selecting, cutting (disassembly into parts), and reorganisation. Time and date were vital information in addition to their serial numbers. Many of the readymades continued to evolve on paper for many years (some even until the artist’s death). Since none of the original readymades no longer exist, their pictorial and diagrammatic representations serve as their reminders. Figure 4 shows a series of snapshots in the development of the Urinal readymade.
Figure 4: Time Line of Readymade Series of Urinals (1917–1989)
Contemporary approaches to computer art include continuing the evolution started by Duchamp. Two examples of work along these lines are multimedia renderings and 3D animations of two of the classic readymades (Urinal and Bicycle wheel).
A multimedia rendering of readymade in a video of Urinal animation (QuickTime movie) is at: http://www.toutfait.com/issues/issue_3/Multimedia/Shearer/images/43c.mov
An assembled 3D model of Bicycle Wheel by Rhonda Roland Shearer (QuickTime) is at: http://www.toutfait.com/issues/issue_3/Multimedia/Shearer/images/16B.mov
Compositional structure of readymades
One reason why readymades have not vanished from the art scene is because they identify aspects of everyday objects we normally do not recognise when we interact with them (i.e., when the objects are ‘'ready to hand'). We do, however, recognize the other aspects when they are shown us explicitly (i.e., when the object becomes 'present at hand’). This can be seen in the later snapshots, which reveal cuts (parts) that are only weakly connected to their physical counterparts. However, more importantly, the cuts reveal aspects of a well-defined structural composition. The effects of this are explored in the remainder of this essay.
An approach to decompose the Urinal readymade is seen in Figure 5. The cuts identify ‘parts’ that constitute its compositional structure (its sub units). The Urinal, consists of at least three distinct cuts: 1) Drain holes, 2) plumbing hole with the artist’s inscription next to it, and 3) mounting holes with the readymade’s serial number attached. The two first are parts that perform a well-defined function when the artifact is in use. Drain holes are the sub-unit of the urinal men interact with when using the urinal. The plumbing hole is the sub-unit that integrates the urinal with the sewer system. The mounting holes are used when ‘installing’ the urinal in a public bathroom.
It the latter part of this essay we refer to the parts of a readymade as its ‘aspects’ for practical reasons. Aspects are ways to see, rather than to build, a readymade.
Figure 5: Decomposing the Urinal readymade into three distinctive parts (referred to as aspects): Handle to mount on wall (37B), drain holes (37C), pipe hole (37D). In addition, the handle has a serial number attached, and next to the pipe hole is the signature and time-stamp of the selector (artist).
Another (contemporary) readymade (chosen by the author) is shown in Figure 6. The same three aspects can also be identified here, but now they are put together again. This kind of readymade is what we call an 'application unit'. It is ready-to-hand (i.e., it is meant to be used) rather than present-at-hand (i.e., Duchamp's readymades were made for exhibition).
Figure 6: The TrioVing cardkey. A readymade with three aspects exposed: 1) Handle, 2) recommendation for use (end-user-aided signature), and 3) coded mechanisms.
Software components and component-based design
A component is a unit of composition with well-defined interfaces to other components. It can be deployed independently or be subject to composition by third parties. Components are tools that together allow application developers to create applications by gluing together ready-made component without the need for programming.
Integration of components to build software applications can be compared to connecting Lego bricks to make toys. By keeping interfaces (connection points) general, each brick can connect to many other bricks (of different shapes). One of the great advantages of composition is that it has the potential to be performed at runtime (i.e., when the system is in use). Connecting two components requires only 'glue code' (i.e., a high-level script) that records the connections between the components. The computer can in many instances automate the writing of glue code, and this is an important aid for end-user developers. A 'snapshot' of this process is shown in Figure 7.
Figure 7: Component-based development with IBM’s Composition editor.
The complete scenario of this example, which shows
the steps for connecting the components is at: http://www.ifi.uib.no/staff/anders/teaching/iv131/visualage/quest7.html
The steps a user has to go through in order to assemble the three software components according to this scenario are as follows:
1. Select the Composition editor (a software development tool in IBM's Visual Age for Java)
2. Components can now be chosen from a component palette (see Figure 7).
3. Choose a button, a text field and a text area (shown in Figure 7).
4. Modify the Button's default names in the Button’s property sheet (named 'Overfør' in Figure 7).
5. Connect the three components: the effect should be to copy the text in the text field to the text area when a user clicks the button.
6. The logic for this is placed in the Button's 'actionPerformed' method[1]. Create a link with this method as the starting point.
7. The link is connected to the “getText” method of the text field component.
8. 'getText' is again connected to the 'append' method of the text area component.
9. The methods are accessed by right clicking on the components in the work area in the Composition editor.
Structure of components: application units
Duchamp revealed two kinds of mechanisms in the Urinal: artifact mechanism (drain holes) and mechanisms for integration with other artifacts (plumbing hole). These kinds of mechanisms (and their division into separate areas of concern) are useful for software components as well, especially for separating the definition of interfaces (software methods) from component functionality. We also need information about how to use the components, which is yet another area of concern. This is what distinguishes application units from readymades. However, the use dimension can be added to readymades by software. One way to accomplish this was shown above (multimedia and video animation). An alternative approach is to use software as handle (user interface) to serve as a point of convergence between the different aspects of a readymade, hence linking them together. The concept was not foreign to Duchamp, but developed by him only in mathematical terms.
Figure 8: Application units in the BasicDraw application (a small drawing program). Holding down a modifier key (alt, shift and control) on a user interface object allows the user to access each of the different aspects of an application unit. The aspects are partly interdependent. Each aspect may have to be changed during system development.
Software components needed to realize this are referred to as application units. Each application unit is a visual component with three aspects: (1) user interface, (2) design rationale, and (3) program code. These aspects have been inspired by the structure of readymades, such as the cardkey shown in Figure 6. For the software equivalents, the user interface is the point of convergence between the three aspects. This is accomplished by the 'event handler' mechanism. To view the different aspects the user simply needs to hold down a modifier key while performing the normal interaction gesture on a GUI object. This is illustrated in Figure 8.
Tailorability is needed for modifying individual application units and to create new ones during evolutionary application development (i.e., redesign and further development). Each of the aspects is tailored separately by three techniques known to as customisation, integration and extension. Customisation means changing the user interface and choosing among alternative configuration options (analogous to Java Bean’s property sheets shown in the scenario of Figure 7). Extension is modifying program code by subclassing and method extension. Integration is tailorability at an intermediate level. It includes both integration of new application units (composition) and integration of design rationale (to document the changes made). A goal of end-user tailorability is to bundle tailoring tools with components in order not to overload the user with irrelevant information nor make access to tailoring tools unnecessarily complicated.
Summary & discussion
This essay has identified some similarities of readymades-as-art-objects and readymades-as-software-components. It has argued that the compositional structure of Duchamp's readymades can be useful as structure for user-tailorable software components as well.
An open issue for further work is how Duchamp's artful integration of readymades (as illustrated in Figure 3) can inform us how to integrate software components. We can explore the dimensions of this issue by identifying several levels of 'software readymades':
· Software readymades as components of applications (as shown in Figure 7)
· Software readymades as complete applications, but running on the same machine
· Software readymades as applications running on different machines.
Integration of software components by end-users to make new applications is far from a trivial issue since it requires that end-users know what interface methods are defined on the various components and how they must be called to realise the integration of two components. In other words, flexibility at this level has still a long way to go before reaching 'artful integration'. Interestingly, a model for software component integration has been Lego toy construction. Lego construction has great flexibility in how two components can be coupled together. This generality is approached in software by method interfaces that cater to many combinational needs. However, the cost of generality (advantageous for component developers) is paid at the expense of end-user mastery because connection points will not have intuitive (domain-specific) names and may require parameters to be specified so that they can be used in many combinations. This requires programming expertise.
It may be simpler to consider stand-alone applications as the unit of composition since they allow greater degrees of flexibility (seen by an end-user). Imagine connecting a database system to a spreadsheet for plotting the data. This is integration at a higher level of abstraction that connecting software components. However, this may also require some form of programming. A scripting language can be used to get access to the data and to send it to the spreadsheet application by callings its plotting functions. An advantage of a scripting language compared to an object-oriented language is that is smaller and easier to comprehend by most end-users (i.e., functions rather than classes and methods).
Finally, software readymades can also be seen as applications running on different machines. Imagine a group of users located in different parts of the country (or world) that has decided to collaborate on a joint task over some time (e.g. a funded project). They should be able to select a suite of Internet tools (e.g. email, group discussion, chat) and be able integrate these tools in ways that support their needs. This localised 'ensemble' of tools may only be relevant for a short period of time (i.e., data storage is temporarily disk space can later be recovered). To create such an ensemble should not require any programming expertise, and it should minimise administrative overhead (i.e. it can be automated by the providers of the tools).
For software readymades to approach artful integration it is necessary that end-users (including artists) – rather than programmers and developers – are able to reuse and recombine user-oriented components. We are still not there, but the last scenarios I presented are within reach. However, to reach the level of artistry exemplified by Duchamp's studio of 1916-17, or fanciful Lego creations made by small children, is further away.
Note: most of the pictures shown in this essay are taken from Reference 5 below.
References
Ades, D., Cox, N. and Hopkins, D. (1999). Marcel Duchamp. Thames and Hudson, London.
Mørch, A. (1997a). Three Levels of End-User Tailoring: Customization, Integration, and Extension. In Computers and Design in Context. M. Kyng & L. Mathiassen (eds.). The MIT Press, Cambridge, MA, 51-76.
Mørch, A.I. (1998) Tailoring Tools for System Development. Journal of End User Computing 10 (2), 22-30.
Mørch, A.I. and Mehandjiev, N.D. (2000) Tailoring as Collaboration: The Mediating Role of Multiple Representations and Application Units. Computer Supported Cooperative Work 9 (1), 75-100.
Shearer, R.R., Alvarez, G., Slawinski, R., Marchi V. and Gould, S.J. (2000). Why the Hatrack is and/or is not Readymade: with Interactive Software, Animations, and Videos for Readers to Explore. Tout-fait: The Marcel Duchamp Studies Online Journal 1 (3), December 2000.
at: http://www.toutfait.com/issues/issue_3/Multimedia/Shearer/Shearer03.html
for image and the full essay see: http://imweb.uio.no/seminarer/designingdesign/Component_based_design.htm
No comments:
Post a Comment