Author Archives: Amy

[Cross-posted] The conundrum of public creation

In the first blog post for our Travelogue: Mapping Literary History project “Welcome to Travelogue” written by our great Project Manager Sarah, she talked about the excitement the group felt at embarking on this project and our eagerness to learn new things and to create a great digital project. She was speaking the truth; we are all excited about working on this project.

For me, as the web site developer, the first thing I had the opportunity to learn was WordPress. The idea was that I would create a meta-blog site and the whole group would use the site to blog and post about the process we were all going through to create out project, “Travelogue – Mapping Literary History”. The process of creating this meta-blog site would give me the opportunity and a place where I could learn and play with WordPress so that when I had to create the official web site for our actual public project, I’d be comfortable and familiar with the CMS.

In her post Sarah also referenced a post I had written for our Fall 2013 Digital Praxis seminar, where I talked about not being afraid to fail. While I wrote about not worrying about failing and how the process itself of learning and trying new things was a success, whether the project failed or not, I must admit that while that may sound good, in reality it is hard to live that philosophy. I was afraid to fail, I was afraid to create a site which would be less than and to do it in public no less is not easy. It is not easy working and creating “in public” (a phrase our professor Matt Gold likes to use). It is not easy to talk about your worries and concerns in public. In my work life I’ve worked where you don’t show the process to the public, just the results. You know, you don’t want to see sausage being made; you just want to eat the sausage. I had to keep reminding myself that part of this class and project was actually doing a good portion of our work in public and letting the public see what we were doing, the difficulties we were having, along with our successes. Stay tuned for my next post where I will write about some of my failures and successes so far in creating these 2 sites and what I’ve learned so far working on this group project.



New tools for online cartography

Annotating online maps to provide context and narrative

Mapping tutorials

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.