Teaching How to Troubleshoot

Spring semester is over. I've turned in the grades for the graduate technology course I teach to school library certification students. The padawans are starting up summer project work.

There's one project we do annually for the Physical Therapy department. The PT students take 9 medical conditions for which quality of life can be improved with strength-building exercises. Here are some of the topics: End-stage Renal Disease, Cancer-related Fatigue, Fibromyalgia, Childhood Obesity, Down Syndrome, Juvenile Rheumatoid Arthritis. The PT students present current research and exercise strategies to 2 audiences respectively, professional and consumer.

The basic strategy is to videotape the speakers presenting off of paper notes. With accompanying PowerPoint slide durations timed simultaneously, we can then synchronize the slides to the speakers. Videotaping the speakers away from the project slide presentation allows us to avoid lighting problems. We then composite the videos together with the slide shows. I manage the instructional technology padawans from videotaping through to the video creation in Flash format. We post the videos for Arcadia University-affiliated clinical instructors to learn from and recommend to patients. We replace them every year with new presentations created by the next year's student class.

We just finished videotaping the presentations for 2010. We'll create the final 18 presentations throughout the summer. Every year we improve on the videos with more streamlined procedures, better quality, faster throughput. And every year we have to troubleshoot the new procedures.

In 2008, we composited the final presentations using QuickTime Pro. A related problem is that we had to use the videos with the exact original videotaped dimensions. QT Pro isn't flexible enough to zoom in or otherwise alter the video's appearance. For instance, if we didn't zoom in enough on presenters of smaller stature, we ended up with videos of mostly background. Also, if the video file sizes got too big, e.g., much larger than 1 Gb (or some 20 minutes of presentation), QT Pro was unable to process a final video image. We had to turn large .avi files into more modest .dv files or even smaller .mov files to be able to accomplish the compositing.

In 2009, we began using Final Cut Pro. Because our processing skills were so elementary, we synthesized clunky techniques through sophisticated software. More specifically, we turned PowerPoint presentations with timed slides into video files to composite with the speaker videos. Whenever we found timing errors, we had to program in the new slide durations in PowerPoint, create new slide videos, then composite them together again with the speaker videos. I won't go into how drop-frame time coding (a default setting in FCP that we didn't even learn about for another year) made those slide videos unpredictable in length thus further complicating the composition process.

This year, we finished videotaping on Monday and Wednesday and already had trouble that we didn't have last year simply downloading the video files from the digital camera's memory cards. The file formats are .mod. Last year we learned how to convert them to .mov files that FCP could handle. This year 25% of the files could not download without error messages.

Guessing that those files were unlikely to have been corrupted over the 2 days it took to bring them from the video site to computer lab, I guessed that the operating system on our iMac simply couldn't manage those few files. I wondered if Windows XP could do any better on a pc. And indeed it could; we downloaded the 4 troublesome files to a pc, transferred them to the server, then transferred those files to the iMac. No problem. Best of all, the downloads that took multiple hours to the iMac (alright, no doubt there are other issues with our OS) became file transfers lasting 15 minutes total. (Fine, if we worked at it, we could probably fix all the issues with the iMac, but why? This system worked fine and didn't make the process that much more difficult.)

My issue over these 3 years has been that I've been the sole person able to identify the problems and conceive of solutions. Sure I manage the lab, but I am not a computer superhero. I'm a reference librarian who has learned technology from padawans who have graduated and moved on, by experimentation, by googling effectively for solutions, and by standing back and considering the bigger issues. I suspected this year that the iMac's OS couldn't handle some otherwise perfectly decent video files. I considered another OS, albeit on a different platform. And then I tried out a hunch that worked out.

If I had left the file downloading to the padawans, they would never have completed the task. They might even have attempted to re-videotape the speakers with no guarantees the resultant files would have downloaded any more successfully.

If I have no fantastic technology skills, I often wonder whence comes any problem-solving abilities I have. Maybe fantastic technology skills come less from mastery of the technology and more from the ability simply to stand back and think, to see the picture from a little bigger perspective.

I talked through my entire thought process with the 2 padawans to help them think more. The challenge is to help them learn how to problem solve, too. Just.

A Man of Ideas

I'm generally a sociable guy. But not always. Like many sociable people, I need my own quiet time even in public. Recently, though, I've begun to realize that the problem might not be so much my need for quiet that keeps me from conversing.

I've realized vaguely for several years and more consciously for many months that the most tedious meetings for me are news only meetings. This is true both in the university and in my church where I serve on the lay leadership. I'm most stimulated and engaged by meetings in which ideas start bouncing around.

A number of months ago, I was at a church gathering in which members from different social strata were supping together. The edict came down from the organizers for everyone to sit at a table where they didn't know at least 2 people. Obediently, I did so. I struck up a thoughtful conversation with 2 college students, one of whom I knew only a little from a membership class I taught. I started getting a bit creative about the idea of volunteer service and ended up enjoying myself immensely. Not that I wouldn't have been conversational anyway in such a setting, but what made this particularly enjoyable was that ideas were starting to bounce around. By my own definition, I was engaging in i-rumination, and I was loving it.

I've been to social gatherings in which I've met new people and talked superficially. In those circumstances, I've enjoyed myself nominally. I've been to other gatherings in which I've connected well with people and gotten into some rousingly thoughtful and enjoyable conversation.

The difference is the exchange of ideas.

I've started to realize just how important to me the ability is to i-ruminate, ruminate intellectually. I've been aware of the importance in meetings. I've been aware of the importance in social gatherings. Now I think I discovered the importance to me therapeutically.

I was supervising a padawan in the library's Faculty-Staff Technology Resource Lab today. While editing a video project procedure with her, I caught myself getting compulsive about the details. The question was how much information to include. More now was time-consuming, but less now could mean more work or confusion for someone else later. I settled for more information now, but the need to resolve the issue of when to invest more time or not bothered me.

With a bit less work pressure during the summer than normal, I headed into the staff area vaguely desirous of a conversation with one of the other librarians. The boss JB was in a meeting with the collection development manager. The circulation manager was in late to cover evening hours. The serials librarian was away from his desk. Ambling into the break room, I found him starting a pot of coffee. He acknowledged he had some time and I sat down. I started tossing out the newest details of the video project (of which he already knew something being a media person in a former professional life himself).

He let me lay out the issues about this fairly trivial issue and let me connect it to the bigger issue of task management. With this project I was thinking to redesign some larger aspects of this annually recurring effort. Last year we were too hampered by the impending deadline to dare even tweak the procedure. This year we had started early enough to have the whole summer to breeze through. If we invested some time now, we could make life easier for someone else later and even have a better product. It didn't take long to recognize that the time we had available made it possible to do some experimentation with the procedure and still get the work done under the old procedure if a new one failed.

Good enough for me. I'd had the chance to process the issues by talking them out and reached a productive conclusion. And my mood had lifted considerably.

So, I've come to a greater understanding of how important it is for me to be able to talk ideas. It satisfies me professionally, socially, and now, at least I can speculate, emotionally.

If we ever meet, feel free to share with me something you've been thinking about lately. Share with me your own piece of intellectual candy. I'm sure to conclude the conversation happier and more thoughtful. And hopefully, I'll offer you a piece of i-candy in return.

Troubleshooting technology

At Arcadia University, reference librarians work with instructional technologists in a unit within the Library Department called Instructional Technology and Library Research Services. The details of why this is and why it's a good idea are for another post. The significance is that besides being the Sciences Librarian, I'm also the student supervisor for instructional technology.

With final presentations fast arriving (it's Week 13 of 14), we're actively managing poster printing. These posters are the big ones you see at professional meetings that students have prepared based on their research.

The lab where the padawans work (read padawan as student apprentices--only the Sith have apprentices) is in the library physically. The large format printer is in Information Technology in a neighboring building. This makes life interesting because we have to monitor the progress of printing remotely. Although you can see from the printer window if a print job has failed, you don't necessarily know exactly why. So far the only causes I've known of are empty ink cartridges or a spent paper roll. I haven't known of more causes because this year is the first that I've done this supervision and, thus, been involved with the printing process.

One phenomenon that I did notice as we monitored printing remotely is that there are other users printing other projects that aren't posters. You can see them interspersed with the presentation poster print jobs we send.

Here's the lesson. It is important to get to know the relevant processes before giving full control to a padawan--or anyone else for that matter. After all, knowledge is power.

I'm sitting next to the printer now because there are no padawans on duty. Normally I'd be in the library but the printer report indicated that there was a failure. I could have called an IT student apprentice (they must be Sith over in IT) to check on the printer status, but I figured I'd just look myself.

What I found was a lab full of design students. My poster print job was failing because the design students were trading out paper rolls from poster paper to drawing vellum. I watched a student change the paper back but still had the poster print job I was handling fail twice more. I looked at the printer and noticed it querying for the user to load the paper even though she already had and had then left for the day. I removed the poster paper and reloaded it. Then I realized that she had never changed the printer's paper setting. She had changed the paper to poster paper, but the setting was still for vellum.

If I had been sitting in the library, I would never have realized that the other print jobs I was seeing in the queue could be contributing to failed print jobs. So now I know of 3 possible reasons why a print job can fail that I can notify the padawans to be aware of.