«Creativity Support for Computational Literature By Daniel C. Howe A dissertation submitted in partial fulfillment of the requirements for the degree ...»
One of those myths is that creativity lies in applying the right tool for the right task—i.e., managing technology. Magazine editors, advertising execs, and Web site producers regularly employ “creatives” to spice up their products. The assumption behind this ludicrous adjective-turned-noun is that a creative person is simply a painter of pictures or a teller of stories— especially one adept at Photoshop or AfterEffects. While managing technology is certainly a valuable skill—for artists and others—it’s not the same as creativity. When you manage technology well, you are simply carrying out the agenda of the designers of that technology. A composer who uses a car to drive to the concert hall is managing technology. But when Laurie Anderson composed a drive-in concert of motorists beeping car horns, she was being creative. To misuse technology is not just to manage technology, but neither is it to mismanage technology. There’s nothing creative about broken links or glacial downloads. Misuse is deliberate. When [Nam Jun] Paik made a work for violin, he did not merely play it badly. In ‘One for Violin Solo’ (1961), he raised the instrument slowly over his head and then brought it crashing down on a table, smashing it to smithereens.
Mismanagement can sometimes be overlooked; misuse is unmistakable.
As Ippolito recognizes, it is often the misuse of technology that allows for the discovery of affordances either invisible to the designer or in direct contradiction to their aims. Such unexpected affordances often become the special ingredient that turns a programmatic work into an “art” piece, rather than just a re-inscription of the technology designer’s intentions.
3.5.3 Supporting ‘Inverted’ Use In the discussion of Design Tensions presented above (see section 2.2), we discussed the notion of crossover as manifested in students’ n-gram projects. In addition to presenting a technical challenge, this design tension helped to illuminate another case in which the arts context suggested practices that contradict those of generally employed in research. While the typical application of n-grams would be to find sentences that are most likely to occur, individuals engaged in literary art practice often desired the opposite, specifically the generation of relatively novel sentences, those that could logically occur, according to the constraints of the model, but were less likely to do so. In fact, as the size of the statistical models grew, ideal sentences were assigned an increasingly small probability for generation.
Although this result was unexpected it makes a good deal of sense when we consider, for example, Ezra Pound’s exhortation for writers to always “make it new”. Further, as novelty is a central element in nearly all definitions of creativity [Sternberg 1999, Hewett et al. 2005], then what literary artists looks for is often what could, but has not yet, been written. This “inverted” use pattern proved to be a recurring theme when algorithms were borrowed from existing areas of research for use in creative practice, a topic discussed again in the chapter 6.
The question of how to support such use patterns is one that perhaps can only be addressed adequately by evaluating tools in areal-world contexts in which such uses can be manifest, and by trying to minimize, to whatever extent possible, assumptions about the “normal” uses for processes borrowed from other contexts.
3.5.4 Supporting Micro-Iteration Almost as soon as we start to play with (and talk about) one prototype, we start to think about building the next. This process requires both the right tools (to support rapid development of new prototypes) and the right mindset (to be willing to throw out a prototype soon after creating it). [Resnick et al.
2005] While rapid iteration is stressed in a range of software methodologies64, it is essential in an arts context, as functional requirements are not defined, but created anew in each iteration. Further, project cycles are generally shorter, especially in an educational context, (from a few days to a few hours) due to the relatively small size of teams (often a single programmer). University programs add still further time constraints, as many students are taking five or more classes simultaneously and a typical 14-week semester provides little time for a leisurely pace, especially as the first and last weeks are absorbed with introductory materials and final projects respectively. With these factors in mind, enabling what we called micro-iteration (rapid iteration on the order of seconds as opposed to minutes or hours) became an important design-constraint for the RiTa tools, without which the project-based format of the course would likely have been impossible.
“Extreme” and “Agile” methods (the latter uses the term “timebox”) generally target iteration cycles as short as 1-3 weeks.
As one insightful student commented, “this is how the creative process works.
Sometimes you have an idea that's not all that great, but you still spend a lot of time having to discover that. The experience makes me want to perfect my creative process in general towards getting ideas realized (or at least conceptually tested for technical plausibility and personal investment) sooner rather than later.” To facilitate this goal, several additions were made to RiTa, most notably the addition of server-mode processing via the RiTaServer object65. The RiTaServer component allows students to debug, modify, and run their programs any number of times, without noticeable delay, no matter how many text files, databases, or models are required. Resource-loading and model-creation, in server-mode, are handled by the RiTaServer process, which runs in its own virtual machine (either locally or remotely). By adding a single line of code to an existing RiTa program, methods can be dispatched to the server process, via a custom remote invocation subsystem, and results returned with no perceptible overhead.
Lazy instantiation of nearly all RiTa objects also serves to facilitate micro-iteration, as resources are only loaded when used. For example, while the core RiTa library contains a full English lexicon, it is only loaded (by default) when actually used during the run of a program. The same is true for the default RiTa fonts, Text-to-Speech samples, WordNet data files, statistical models, etc. Thus, each program only “pays”, in memory and processingtime, for what it uses, while the library still supports a range of diverse use-cases, each of which is highly resource-efficient.
See Chapter 2 for a detailed description of this component.
3.5.5 Scaffolding and Transparency Constructivist approaches to education advocate situating learning in realworld problems- but these problems are complex. Providing scaffolding allows learners to deal with a problem’s complexity and successfully solve and learn from these kinds of problems. [Hmelo and Guzdial, 1996] Abstraction (generally via encapsulation) is an important part of tool design—in fact, it is often the primary reason for programmatic support tools in the first place—the abstracting away of implementation details that are either too difficult, too time-consuming, or not relevant to a particular problem. Similar techniques are often applied in pedagogical contexts, where they are generally referred to as scaffolding. Guzdial  describes scaffolding as educational support structures designed “to enable students to achieve a process or goal which would not be possible without the support and... to facilitate learning to achieve without the support. Yet there are many ways of implementing scaffolding, each with specific benefits and costs that relate directly to the learning environment at hand.” He continues, “in an educational context it is important that we don’t confuse the ability to ignore certain concerns with the inability to access them at all.” Hmelo and Guzdial  refer to this as the distinction between “black-box” and “glass-box” approaches to
Black-box scaffolding is scaffolding that facilitates student performance.
Black-box scaffolding performs a task in place of the student performing that performance goal, usually because learning to perform that goal is determined to be unimportant for the learning goals of the activity. Glass-box scaffolding is scaffolding that facilitates performance and learning. It is important for the student to understand what glass-box scaffolding is providing because we want the student to be able to take on the functions that the glass-box scaffolding is providing.
While facilitating “performance” (most often understood as “productivity”) is an important goal in an educational environment where the difficulty of very basic tasks can otherwise lead to mounting frustration, its costs can outweigh its benefits. When the scaffolding that enables such performance is invisible or opaque, it can confuse students as they encounter new concepts and cause them to perceive the often inaccessible lower levels as “magical”. Further, opaque tools and subsystems can serve to disempower, leaving students to perceive themselves only as increasingly advanced media-consumers, rather than creators. Yet at the same time, the mass of details that go into programming even a very simple sketch can be overwhelming to learners, especially so in some high-level languages, e.g., Java. Researchers like Hmelo and Guzdial  have suggested various shades of “glass-box” scaffolding that provide support, but in a transparent fashion. With such an approach, students would to be able to ignore extraneous details whenever it is advantageous to do so, but still have relatively simple access to all of the layers below, should they progress to the point that they are curious as to the mechanisms at work in those layers.
The RiTa tools attempt to provide such a glass-box environment in several ways.
First, through the initial use of the Processing environment, a range of difficulties inherent to Java are immediately avoided: from path and classpath configuration; to separate compile and run steps; to the complexities of the ‘main()’ method; to the scoping details for classes, methods, and variables; to the distinction between static and non-static elements; all of which can be baffling to new users. In contrast, to run a simple Processing program (the ubiquitous “hello world”, for example) one simply types in ‘print(“hello world”);’, and pushes the ‘play’ button. Like Processing,66 RiTa is open-source, but in contrast, to further facilitate At the time of this writing the Processing source code is available only via the Subversion (SVN) concurrent versioning system.
transparency, the source for RiTa is included with every download of the library.
Additionally, multiple types of documentation are made available, including tutorials, a user’s guide, a simplified index of the most-used methods in the library, and a full javadocstyle reference for more advanced users. Early on, as students are switching to the Eclipse environment, a tutorial is presented on linking to library source files, so that a single key press on a method name immediately takes one to its definition, down from RiTa, to Processing, to the core Java libraries themselves.
3.6 Supporting Creativity: ‘Productivity’ and Beyond In its 2003 report, entitled ‘Beyond Productivity: Information Technology, Innovation and Creativity’, the National Academy of Sciences [Mitchell et al. 2003] states that: “software tools must not only be available, but they must be objects of critical reflection… Artists and designers can do more with IT if they become deeply conversant with its capabilities and limitations.” While it may be useful in the short run to provide students and artists with tools that accelerate their productivity, it will be far more transformative to teach them how to “think procedurally” in their practice. This is what inextricably links creativity support with both computational thinking and procedural literacy. Rather than simply accelerating the rate at which practitioners accomplish their traditional day-to-day tasks, CST researchers are beginning to provide artists with direct access to the power of procedural methods and computational practices.
The analogy of the hungry man and the fishing instructor is apt in the case of classes designed both to teach core computer science concepts and engage the creativity of artists.
Rather than giving away fish, we might instead teach people how to fish, or better yet, especially in the case of artists who have historically created a majority of their own tools, help them learn how to build fishing rods of their own. In this way, they gain not only insight into the nature of fishing, but into the nature of mechanics, gravity, tension, fluid and aerodynamics, and physics itself. Facilitating this iterative model of understanding requires two rather simple steps: a) we need tools that can be critically examined by their users; and b) we need users with enough basic understanding of computational processes that such access will be rewarding. For the first, we need to create and disseminate tools that not only are opensource, but that are transparent at multiple levels; with high-level descriptions and examples, careful documentation, and open access to all the layers of authoring that comprise the tool.
For the second, we need to teach artists basic procedural literacy, without which no amount of transparency can be leveraged. RiTa attempts to be a tool that simultaneously addresses both of these objectives.