«Creativity Support for Computational Literature By Daniel C. Howe A dissertation submitted in partial fulfillment of the requirements for the degree ...»
This type of work has been called “combinatorial literature” and Oulipo member Harry Mathews writes [Mathews and Brotchie 1998] of combinatorics whose: [object is] the domain of configurations, a configuration being the preset arrangement of a finite number of objects, whether it concerns “finite geometries, the placement of packages of various sizes in a drawer of limited space, or the order of predetermined words or sentences.” Arrangement, placement, order: because these are the materials of Oulipan combinatorial research. What results can generally be called rearrangement, replacement, or reordering, all subsumed by the generic term permutation Italo Calvino, perhaps the most internationally renowned Oulipan, was invited in 1973 by IBM to write a story using one of their computers. In response to this challenge, Calvino had the protagonist of the story, entitled "The Burning of the Abominable House," use punchcards to feed data into a computer. But according to Calvino's wife, the limited computer access in Paris, where they were living at the time, meant that Calvino worked by “carrying out all the operations the computer was supposed to do himself”[Booth 1965].
Paper seems to have been the mechanism, not just the eventual interface, of Calvino's initial foray into computing [Montfort, 2004] From the beginning however, Calvino was interested in science, and particularly so in its “cybernetic” developments. In “The Literary Machine”, for instance, he demonstrates a clear appreciation of the possibilities offered by the affordances of computer applications. But perhaps his most well-known work is If on a Winter’s Night a Traveller, a novel written in the second person. In this work, “you” are the main character, a bookseller journeying from bookstore to bookstore, attempting to locate a complete and correct version of the same book you are reading, which is never found. Though the work does not follow such mechanistic procedures as “The Burning of the Abominable House”, it nonetheless represents and enacts a constant investigation of the author’s positionality in the constructed literary work.
Like Calvino, the Oulipo as a group maintained an evolving relationship toward the
computer. Mark Wolff  describes early Oulipan experiments with Computers this way:
When the Oulipo formed in 1960, one of the first things they discussed was using computers to read and write literature. They communicated regularly with Dmitri Starynkevitch, a computer programmer who helped develop the IBM SEA CAB 500 computer. The relatively small size and low cost of the SEA CAB 500 along with its high-level programming language PAF (Programmation Automatique des Formules) provided the Oulipo with a precursor to the personal computer. Starynkevitch presented the Oulipo with an 'imaginary' telephone directory composed of realistic names and numbers generated by his computer. He also programmed the machine to compose sonnets from Queneau's Cent mille milliards de po`emes.
Yet few other works by the Oulipo directly employed computers, though it was discussed quite regularly at meetings. In fact, quite soon after the publications of Queneau's book CCMP, specialists had created computer versions of it. This led Paul Braffort and Jacques Roubaud in July 1981 to propose the creation of a new group named ALAMO (Atelier de Littèrature AssistÈe par la Mathèmatique et les Ordinateurs). For an in-depth discussion of the ideas associated with the ALAMO movement, see “Reading Potential: The Oulipo and the Meaning of Algorithms” [Wolff 2005].
“The strength of [contextual] methodologies lies in the fact that they place the study of creativity in a personal, social, societal, cultural and even an evolutionary context. The projects studied are defined by the practitioner and the research studies creativity using research based in actual practice.” [Mayer 1999]
5.1 Introduction In this chapter we present a pilot evaluation designed to evaluate the efficacy of the RiTa tools in conjunction with the Programming for Digital Art & Literature (PDAL) course.
From a combination of student feedback, assignments, and projects, in conjunction with our own perception of students’ experiences with the tools, it was our hypothesis that RiTa and PDAL achieved several pedagogical goals: affecting student attitudes toward programming, enhancing their programming ability, and supporting their creativity both within the classroom and in the larger context of digital art. To assess this we administered a survey and programming quiz before and after one iteration of the semester-long course, and performed a descriptive analysis of students’ final projects in the course. We also looked at a range of solicited and unsolicited feedback to further support the trends we have observed.
Before describing the specific methods employed, it is important to note that this research employs a qualitative methodology based upon constructivist97 learning theories. As such, it includes the cultural and personal conditions of the researchers as well as that of the research population The process is that of a participating observer, who is not only an investigator in the field of research, but also one who is a part of that field According to this approach, the researcher is conscious of the field, conscious of herself, and not only affects See pedagogy section for further discussion of this term.
reality, but also helps to create it. The researcher does not come to the research tabula rasa, but possesses a range of previous attitudes regarding the field and domain of study. The experience of the researcher affects her views, attitudes, and actions, and her voice is present throughout the research work [Hammersley, Hazan, 2001; 1995; Phillips, 1990; Ragonis & Ben-Ari, 2005; Sabar Ben-Yehoshua 2001].
5.2 Goals The first objective is to enhance the personal experience of the person who wants to be creative. The second is to look for ways to improve the outcomes and artifacts. The third objective is to support the improvement of process by providing tools that are designed with certain functional requirements in mind. [Hewett et al. 2005] Our goals in this pilot evaluation were three-fold. First, we wanted to measure changes in students’ attitudes about programming before and after a semester-long exposure to the RiTa tools in the context of the Programming for Digital Art & Literature (PDAL) class. Second, we hoped to measure changes in their programming ability and assess whether these shifts correlated with any perceived attitudinal changes. Third, we hoped take an initial measure of the degree to which these tools served to support students’ creativity in digital
media. Our initial expectations were:
that a semester-long exposure to the RiTa tools and PDAL would lead to a positive • change in students’ attitudes about programming;
that a semester-long exposure to the RiTa tools and PDAL would lead to a positive • change in both students’ assessment of their programming ability and in their measureable programming ability;
and that the RiTa tools would help students to be more creative programmers in the •
5.3 Methods Given the exploratory nature of this pilot study, we collected data using a combination of pre-post surveys, a programming quiz, coding/evaluation of student projects, informal student feedback, and qualitative observations. Each of these methods attempted to compare the learning, behavior, and attitudes of students before and after using the RiTa tools as part of the semester-long Programming for Digital Art and Literature (PDAL) class.
5.4 Participants A total of 15 students from Brown University and the Rhode Island School of Design (RISD) participated in the pilot evaluation. Students were a mix of undergraduates (from RISD and Brown) and graduates (RISD) from a variety of departments including Computer Science, Literary Arts, Visual Arts, and Modern Cultures & Media at Brown, and Digital+Media, Graphic Design, and Glass at RISD. From this group of students, 10 (0.67) were male and 5 (.33) female. 6 (or 0.40) were from RISD 's Digital+Media graduate program, 4 (0.27) were computer science majors, 2 (0.13) were from Literary Arts, while the remaining were either undecided or from one of the other departments above (= 1 per department). In addition to the computer science (CS) students, who had each at least 1 prior CS course, 3 (0.27) of the non-CS students had taken a previous CS course. The average number of years programming for the class was 21.75/15=2.13 years. For CS students, this average was slightly higher at 3 years, while for non-CS students it was slightly lower at 1.79 years (19.75/11 or 10.75/9 without most/least=1.01)98. The course included several auditors who were not included in the survey results.
5.5 Observation Set 1: Surveys 5.5.1 Pre-Survey Participants were given 20-25 minutes to complete a 32-question pre-survey (including basic demographic info and the pre-programming quiz discussed below). Presurvey participation was optional and participants were instructed that their answers would in no affect their evaluation in the course. Students provided a unique identifier (generally, but not always, their student ID) to correlate pre and post results. Surveys were administered by a third party that was unaffiliated with the course and participants were instructed not to discuss the questions or to consult any references (e.g., laptops) during the allotted time.
5.5.2 Post-Survey Participants were again given 20-25 minutes to complete a 28-question post-survey (including basic demographic info and the pre-programming quiz discussed below). Postsurvey participation was optional and participants were instructed that their answers would in no affect their evaluation in the course. Students again provided the unique identifier that they used in the pre-tests to correlate their data. Surveys were administered by a third party that was unaffiliated with the course and participants were instructed not to discuss the questions or to consult any references (e.g., books, laptops, etc.) during the allotted time.
This average is somewhat misleading due to a single student who entered a very high number. Omitting this student from the calculation, the average was 1.01 years of programming experience.
5.5.3 Attitudes Toward Programming In order to measure participants’ general attitudes toward programming we developed four questions, each of which were asked in both the pre and post surveys. In each of the three questions, a paired-samples t-test indicated differences in attitude toward programming between the pre and post surveys.
The first question addressed students’ general sense of confidence in their programming and showed significant increases between pre- and post-test scores according to a paired-samples t-test, t(11) = 3.677, p.001, d = 1.109. The second addressed students’ assessment of their programming ability and also showed significant increases, t(14) = 2.687, p.01, d = 0.718. The third question addressed the frequency with which students could “express their creative ideas” via programming and also showed a significant increase, t(12) = 2.560, p.001, d =.739. The fourth question addressed students’ feelings about programming and while not statistically significant did show a small increase between preand post-test scores While it would be premature to assert any causal relationship based on these findings, they do suggest a positive impact on students’ attitudes toward programming, results which were similarly significant across gender, department, school, and previous technical background.
5.5.4 Knowledge and Self-efficacy To measure students’ confidence, knowledge and self-efficacy in a more granular fashion, eight additional questions were asked regarding knowledge and confidence on specific programming constructs and tools. On all of these dimensions, a paired-samples ttest indicated significant differences between the pre and post surveys (see Table XX below).
While it is unclear that such differences would not have resulted under other circumstances, it does suggest that confidence and knowledge were significantly increased through the semester long exposure to the tools and techniques. To compare students’ self-assessments with their actual skills, programming ability is tested below (via Parsons’ problems) for analogous gains.
Table 6: Pre/post change in students’ knowledge and self-efficacy with programming concepts.
5.6 Observation Set 2: Code Reading and Writing Parsons problems are easier and more reliable to mark than code writing, provide an opportunity to test student misconceptions more specifically than code writing, yet they appear to require the same set of skills... This makes them an excellent alternative to traditional code writing questions. [Denny 2008] 5.6.1 Parsons Problems The work reported here stems from a desire to better understand the degree to which PDAL students were actually learning to write and (equally importantly) read programming code. To this end, pre- and post-programming tests were administered to the students in PDAL before and after exposure to the tools and course. The pre-test was given during the first class meeting, before any material had been presented and the post-test was given during the last meeting, just before final project presentations. Again, surveys were administered by a third party unaffiliated with the course and participants were instructed not to discuss the questions or to consult any references (e.g., books, laptops, etc.) during the allotted time.
Figure 18: A Parsons problem example (pre-test).
To measure students’ understanding of programming we presented each with a question designed to measure both code writing and reading skills. The style of the problem, generally referred to as a 'Parsons problem'99 presents students with a paired superset of the The term "Parsons’ programming puzzle" was first introduced by Parsons and Haden .
lines of code required to solve a programming problem. The student's task is to select the correct line of code from each pair, and then place the selected lines in the correct order to define a (Java) method that accomplishes the specified task. The Parsons problem from the pre-test for example, shown in Figure 18, asked students to define a method that would remove all 'x' characters from a String.