How I Learned to Troubleshoot
Rachel Lovinger May 23, 2011
Tweaking the signals at the Experimental Television Center (photo by jonCates)
As an undergrad I studied film and video. It was an experimental film and video program, not the nuts and bolts of Hollywood filmmaking. My video professor, Ralph Hocking, had a couple classrooms filled with analog and digital machines, wired up to video players, computers, cameras, monitors and recorders. There were oscillators, video toasters, modulators, and all kinds of other devices that were designed (or in some cases, custom modified) to alter the video signal in various ways.
The process was very experimental, as well as the resulting video work. There were no manuals for these machines. You just had to hook a bunch of things together and adjust the settings until you got the results you wanted. Sometimes you got what you expected, more often you didn’t. And sometimes you got nothing. Our teacher would just advise us to trace back from the source (a camera, computer or video player) through each machine in the chain, pulling pieces out and adding them back in until we figured out where things fell apart.
Recently I’ve been working on a CMS project with a lot of new parts: a brand new Content Management System, new display templates, new content. There are many people, from many disciplines, working on different pieces of the puzzle. When we look at the rendered web pages and things don’t appear as expected, a number of people have to jump in and try to figure out where the problem is taking place. Most people are hoping the problem lies with some part that they aren’t responsible for.
Is there something unexpected in the content fields? Is there a problem with the way the different content elements are assembled? Is the data configured improperly when it’s saved to the database? Is the content being pumped back out of the system incorrectly? Or is there an error in the presentation template? Investigating what’s happening with the content at each of these stages reminds me of those days: working in the video lab, turning dials to see what happens, inserting a monitor in the middle to see what the video looks like part-way through the web of machines, unplugging things to figure out what might be introducing a critical failure.
Troubleshooting might not be an activity we normally think of as being closely associated with content strategy. But if you’re a content strategist who’s interested in the technical side of content you may find yourself playing a key role in helping to track down the root of the problem. The content is the signal traveling through the system and getting stuck somewhere along the line.
I recently emailed my one-time professor/mentor and told him that I was writing this post. I don’t think Hocking ever considered this to be part of the curriculum. He humbly summed up his approach to troubleshooting as: “Just remember not to start in the middle.”
