This workshop is offered as part of the Media Technology and ArtScience programs. It deals with the question of how art installations (in the broadest sense of the word) can be documented in a structured manner. Such documentation can serve to promote the resulting work, explain it, get financing, or to describe the process by which it came about for a broader audience.

The method of documenting one's work that we discuss uses many elements from scientific writing. Central in this are:

• a compact structured description
• logically explaining the choices you made that resulted in the final work,
• describing the context of your work: how does it relate to work by others, to your own works, to existing knowledge, and what is its place in time?

Part of the workshop is spent on documenting the works that students created. The results of this exercise are discussed within the group and feedback is given. This should kickstart the possible describing of these works for future use.

Maarten Lamers of the Media Technology MSc program at Leiden University. Follow these links if you want to know more.

What works did you create?

• Who of you have described their art installations in writing? How?
• With the web it seems more common. See for example the Information Aesthetics website.
• There seems to be very little history or conformity in describing art installations.
• Why would you want to describe your work?
  
  

Scientists have been writing down the results of their thinking and research for ages, in a highly structured and focussed way. In fact, writing is usually the only output of scientific labour. The method that I propose for documenting your work uses elements from academic writing:

• It is intended for a critical and informed audience, people who understand what you are talking about. In the case of art installations, such people may be fellow artists, exhibition curators or knowledgeable viewers.
• It places the work in its proper context, demonstrating its relevance within current and past ideas, happenings, trends, and theories.
• It explains your choices in a rational manner.
• It gives others the possibility to react to your work.

That's very true (I hope). However, reading your writing may be very different from experiencing your work. Reading about an artwork may enhance its experiencing or even kill it. But here's the thing: your writing is usually meant for another audience (curators and fellow artists, for example), and to add to the experiencing of the work itself. It is intended for people who want to go beyond experiencing your work.

The context of your work is what gives it meaning. It is the collection of knowledge, other works, human behaviour, current events, your own experiences, trends, whatever, that your work relates to.

• By making this context explicit, you establish the meaning of your work, and its relevance.
• For artworks especially, the context includes works by other people that can somehow be compared to your own work, and its place within "history" or current trends. This doesn't imply that the other works must be similar to yours. It just means that they are interesting to compare.
• If you use certain theoretical foundations, for example about how people react to color, then this is also context.

• To get from the context of your work to the concept that it expresses, you had to make a series of choices. Making these choices was the most important thing you did! Think about what these choices were, and motivate how you made them.
• Why you did not do certain things may be equally important to motivate.
• Make a difference between conceptual choices (why do you express something in color and not in sound? why did you choose a certain user interaction? what should it trigger in the viewer? why did you use a specific medium?) and implementation choices (why do you use MIDI instead of RS232, Mac or PC, Processing or Max/MSP?).
  Rule-of-thumb: everything that happens "underwater" and is not part of the viewer's experience is technical.

• Before you start writing down al the technical details, think about how important they are to mention!
• Usually, it's enough to just mention them briefly. But this really depends on who your intended audience is.
• Rule-of-thumb: mention just enough technical details to satisfy immediate curiosity. If you want to go into technical details fully, consider doing this in another document, a "Design Document" for example, or a "Technical Report".

It is wise (and good practice) to include a short reflection on your own work at the end of your documentation. Perhaps you can draw some conclusions from your work or mention area's of improvement. Certainly when it comes to possible improvements, it is better to mention them yourself than to have someone else point them out to you afterwards.

Start your document with an appealing title. If you named your product or installation, you can include that name. However, most often it is wise to give your documentation a more descriptive title, so that people can decide from the title if they want to read it. And don't forget to mention your name(s). Some examples:

• If your artwork is called "Life24", then a title for its documentation might sound like "Life24: An Affective Visualization of Global Events".
• For an installation such as the Digital Pin Display, you could consider the title "Digital Pin Display: Greyscale versus Physical Depth".
• If your product is named "Furby", then your documentation may be titled "On the Boundary Between Pets and Robots: Furby".

An abstract is a short summary of your document (approx 100-150 words). Every scientific article starts with one, and they are a good thing to have.

• A good abstract is very useful for the reader, but also for communicating your work. It can be used for exhibition invitations, for example.
• It's always better that you write a good summary of your work than have someone do it who does not really understand what your work is about.

• The Khronos Projector by Alvaro Cassinelli. A very complete description of the project. Good title: it captures your interest. Good division between conceptual and technical choices. Has "Experiments" and "Conclusion and Remarks" sections. Very complete project documentation.
• String Thing by Ben Dove. A fairly good project description. Nicely structured. Somewhat short text for the important parts, and a very oversized process description.
• Flight Patterns by Aaron Koblin. An example of a nice project, but minimal description of his work. In terms of describing your work, this is not what I mean...
• Vizster by Jeffrey Heer and Danah Boyd. Their 'research paper' contains a very scientific explanation of the project. But see how they separated the truly technical information in another document, what they call the 'early design document'.
• Have-a-Seat by Media Technology students Michiel Stade, Sylvain Vriens and Mika Igarashi. The draft paper that goes with the sofa describes the context of this work very extensively. Note how only Section 5 (one page!) discusses the work itself.
• A Tactile Closed-Loop Device for Musical Interaction by Media Technology student Staas de Jong. Excellent length (only 2 pages). The context is described rather shortly in the "Introduction" section (too shortly, I think). Note how he reflects on his own work in the "Conclusion and Future Work" section. By describing his project in this way, it was accepted for presentation at the International Conference on New Interfaces for Musical Expression, 2006 in Paris.
• Globe4D, time-traveling with an interactive four-dimensional globe by Media Technology students Rick Companje, Nico van Dijk, Hanco Hogenbirk, and Danica Mast. In only 2 pages the paper gives a very good description of the project's aims and results. The "Introduction" section makes clear the context of this work. Note how the paper nicely separates the conceptual and technical choices into sections 2 and 3. Also a video was made to explain the project. The paper and video were presented at the famous ACM Multimedia Conference, 2006 in California and won the Best Video Presentation Award there.

Getting started is the difficult part. Most importantly, try to keep it simple at first! If you know a good project description that you like, use it as an example. Here is a suggestion for the steps that you can take:

1. Think about the context of your work. How does it relate to other works? What theory does it use? Why is your work relevant at this time? Make a short list with some context issues. If necessary, find information about these issues on the web or elsewhere.
2. What are the most important (conceptual) design choices that you made? Make a short list of a few, and make sure that they are conceptual choices, not technical ones.
3. Make a structure for your document. Suggestion: 1. Introduction, 2. Context, 3. Your Concept (with design choices), 4. Technical Issues, 5. Conclusion and Remarks.
4. Start by writing the Context section. After that, describe your concept and design choices. Then the Technical Issues (keep it short!).
5. Shortly discuss your own work in the Conclusion and Remarks section.
6. If you then still need it, you can write a short Introduction section (sometimes this gets merged into the Context section).
7. Come up with a descriptive and catchy title.
8. Finally, write the abstract that shortly summarizes what you wrote.

Describe the work that you created for this course. Start with the structure that I proposed (1. Introduction, 2. Context, 3. Concept, 4. Technical, 5. Conclusion). Try to get as far as you can, and don't worry about the writing style. Present your writing before the group.