Tag Archives: WilliamTurkel

Sustained disruption

William Turkel’s presentation and workshop last week opened with the notion that those who engage in physical computing have the opportunity to “build objects that convey a humanistic argument.” This reminded me that DH scholarship isn’t constrained to data and digitization. While access to digital information and artifacts plays a huge role in the genesis and momentum of the digital humanities, working with data can simply be seen as working with knowledge in the most popular medium of the day. The systems we work within have multiple entry points, and many possible layers to manipulate. Beyond software (and the industry and implications of big data), physical computing and fabrication offer us an alternative way to formulate questions about interfaces, manufacturing, and the politics of innovation.

Always when working with computers and digital tools, we confront not only the black box of processes that we don’t fully understand, but also the scholar’s entanglements with the prescriptions and rules of consumer technology. But a physical computing project works on a more fundamental level of abstraction. While, as Tukel pointed out, there is always a proprietary (non-transparent) layer involved, a physical computing project does allow its maker to experiment with and change a different set of parameters and functionalities than software allows. It’s important that we have permission and the resources to take a hands-on approach to computing because it can disrupt and deepen our relationship to the technologies that we’re ultimately accountable for when DH practice becomes critique.

But I got the feeling that Turkel wasn’t overly concerned with that kind of broad or absolute speculation. I’m interested in the fact that Turkel’s lecture and workshop didn’t necessarily move in the direction of solving what it means to work with hardware, sensors, or fabrication. His talk sidestepped making heavy-handed theoretical claims or predictive expansions on his opening thought, and instead moved into a discussion of his students’ individual projects. I’m not sure his lecture outline was a statement in itself, but it did seem that he refrained from making explicit claims about the need for or purpose of physical computing in answering DH objectives or critiques. Turkel seemed to be saying that while physical computing—as a medium for play and exploration—can represent ideas and embody cultural critique, the future of the humanities does not depend on our mastery or reinvention of microchips. Even though we are bound to make objects that convey arguments, Turkel’s pitch for the essentialness of making didn’t seem wholly contingent on the scientificness or theoretical stakes of our approach. Perhaps “making” outside one’s comfort zone is important in itself, and represents a commitment to the interdisciplinarity that we have presumably already embraced.

I’m interested in the simplicity and purity in the invitation to play and fail, and wonder about this as a sustainable framework for understanding new tools and asking new questions. It’s interesting that Turkel made a few references to his love of kindergarten, and the values we lose after we leave that early classroom environment—a place of beginnings, an environment that’s ideal for experimentation.

In a sense, humanities scholars who decide to delve into hardware hacking, software, and interface design are also engaged in a kind of beginning or frontier. This last week, I’ve found myself asking questions about the relationship of beginnings to experimentation and play, and wonder how Turkel’s hands-on imperative will evolve as the contexts, spaces, and available expertise for making technology grow and change.

Making and creating and not worrying about failure

William Turkel’s lecture “The Hands-on Imperative”, his subsequent talk to our DHpraxis class and then workshop had me thinking about a number of different things, specifically the issue of space, the issue of tenure portfolios that contain fabrication and physical experimentation projects, and how failure is something to embrace and not fear.

His discussion of space and the need for a place to make things, to play and create resonated with me.  In a blog post “A Few Arguments for Humanistic Fabrication” on his blog “Digital History Hacks 2008”  Turkel said

“The limitations of our physical spaces can be more difficult to circumvent. Most of the teaching and research environments available to humanists at my university are designed to support solitary or small-group office work. These spaces are almost comically unsuitable for the kinds of things I try to do with my students: soldering, mold-making and casting, building and lighting physical exhibits, programming in groups, creating displays or signage.”

One really has to always be aware of space and how and why a space is being used.
As a librarian I’ve always been aware and concerned with the physical space and layout of a library and how the space affects people’s use of the library.  If the space is not inviting, if it doesn’t match what people are using a space for it can be a real hindrance, stifling creation and education. The fact that humanities spaces in academia are not set up for play and creation of physical objects does not surprise me at all.  We need to be able to break out of the confines we find ourselves in but many times in academic or corporate spaces we are not allowed to break out.  Trying to convince administrations to permit a space in an academic department where you can vent fumes, use power tools etc. is not going to be easy, I mean we aren’t even allowed to pick a different wall color to paint our student lounge. If we cannot even personalize the color of the walls of our own student lounge, how can we expect to create a space where we can have “high ceilings, natural light, plenty of ventilation, cement flooring, workbenches on casters, locking cabinets, big blank walls where you can hand things on. No carpeting, no beige cubicles, no coffee tables with plants.”

Another hot topic in DH, which we have been reading and talking about in class, which Turkel’s talk and workshop had me thinking about were issues of tenure and how DH building projects and work relate and are counted towards an academic’s tenure portfolio. In Stephen Ramsay and Geoffrey Rockwell’s chapter “Developing Things: Notes toward an Epistemology of Building in the Digital Humanities” in the book Debates in the Digital Humanities the authors ask “how do we”  and “can we” count the work of builders, hackers, coders as scholarship?  How is work on and about XML, XSLT, GIS, R, CSS and C counted and evaluated?  Is it scholarship? How will it be evaluated and can it lead to promotion and tenure?  Lev Manovich believes “a prototype is a theory.” Stan Rueker and Alan Galey say that “the creation of an experimental digital prototype [should] be understood as conveying an argument about designing interfaces” and that digital artifacts themselves, not just their surrogate project reports should stand as peer-reviewable forms of research, worthy of professional credit and contestable as forms of argument.  “It is the prototype that makes the thesis, not discursive accompaniments like white papers, reports and peer-reviewed papers.”  My question is – are these beliefs truly occurring in practice in academia today?  Can a faculty member truly include the objects they make using Max 6, Phidgets, Arduino or Makey Makey in their tenure portfolio and have it count in a meaningful way towards tenure?  Are academic departments and institutions willing to accept this type of work as scholarship and worthwhile of tenure?  And if not then what does that mean?  Should we stop making things or should we continue to make things even if they are not counted? How can we work to ensure that this type of work is considered scholarship?

Finally, Turkel talked about failure and what can be learned from failure.  He talked about how some of the best students in his class are those who have no training in programming or shop classes and therefore have no preconceived notions of what can and cannot be done and are not afraid to fail.  At various library jobs I had, where I had staff, I would tell them not to be afraid of making a mistake when working on the library catalog.  I would tell them to be inquisitive and to explore the program and to ask questions.  I assured them I set it up so that they couldn’t destroy the catalog and that their exploring and using the system was how they and I would learn.  I try to follow this philosophy myself when setting up database interfaces and catalog systems. However, it is not always easy.  Fear of failure and the consequences of that failure on job security (and sometimes grades) are real fears.  I think it is great that Turkel is able to assure his students that they will not fail his class if their projects fail but in many instances, in many jobs, this is not a promise one is given.  I always joke that the only job where you can be wrong all the time and fail and not get fired is weather person.  I say it jokingly but it is somewhat true.  In academia or in corporate culture, having a project fail is not always looked upon in a positive light.  As the people feeling the heat from the Federal Government Affordable Care Act Marketplace web site can attest to, people do not seem to think the current problems are “learning experiences.”  How do we then promote inquisitiveness, willingness to take chances and possibly fail in the projects we work on in DH without the fear of the consequences of our failure?

“I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.” — Said by Michael Jordan in a Nike ad, written by Jamie Barrett.  http://youtu.be/GuXZFQKKF7A



Physical computing as a DH approach

Within the last weeks different approaches to DH have been presented to us, many of them based in outstanding research projects of respected academy professors and investigators.  Many of us (I think) are developing ideas for our final project, with a certain doubt if we will manage to mature our projects through this DH research tools, we might be asking if they are suited for our own research or event if we could truly understand how to use a data visualization program or hack a kinect device without even knowing how to code.

William Turkel has made a good point in approaching technologies through direct acts, “Just because the separation between thinking and making is longstanding and well-entrenched doesn’t make it a good idea. At various times in the past, humanists have been deeply involved in making stuff: Archimedes, the Banu Musa brothers, da Vinci, Vaucanson, the Lunar Men, Bauhaus, W. Grey Walter, Gordon Mumma. The list could easily be multiplied into every time and place, but the main point is that getting your hands dirty might be worthwhile, even if you’re not da Vinci.”1 from a personal point of view, I tend to see that the first step to clarify how or when certain DH method could be used we must “play” with it.

Physical computing provides a tangible example of getting right into the work, like making a laptop produce a sound based in the variation of human heath with the help of a thermal sensor plugged into a PC/MAC (Example from the workshop). Someone could think that this exercise lacks of concept, but in fact it can be the first step to approaching to a particular DH research technic or tool.

1. http://digitalhistoryhacks.blogspot.ca/2008/11/few-arguments-for-humanistic.html