Troubleshooting Reflection EPSY 457

by Karen Hamilton - Monday, 20 July 2009, 05:27 pm

When I began reading the Pool, Edwards and Jarvis article “The Home Network as a Socio-Technical System" article, I was immediately struck with the sentence, “Our analysis unpacks a number of these properties, including deep heterogeneity and multilayered nature of home networking and the character of networking as an infrastructure technology and the intertwining of the ephemeral, digital aspects of networking with the physical infrastructure of the home.” My immediate reaction to this sentence was, “Say what?”

Fortunately, the article does go on to explain what they are talking about. Interesting to me was that one of the points they make is that there is often a gap between the language of the expert who helps troubleshoot the problem and the person who needs assistance. They note that there is a need to find a common ground.

In any communication the words we choose are important to getting our message across. I’m sure most of us have come across the person who is so inside their topic that they no longer speak English as we know it. Academics and IT people can both be guilty of this. Their point about finding common ground is an important one. I’ve taken some courses in web design where the teacher was quite an expert in the subject, but was not terribly successful in imparting the knowledge to the student because he was unable to recall what it was like to know nothing or little about a particular topic. For me one of the key things when helping someone else troubleshoot is empathy and a recollection of a time when I knew as little as the person I’m trying to help.

On page 280 of the Pool, Edwards, and Jarvis article they say that studies have shown that, “technicians calibrate the advice they give based on how much technical expertise they perceive the caller to have.” This point stuck home to me. On the rare occasions I’ve had to call for technical assistance- usually Rogers –internet issues, I’ve very quickly dropped a few techie words and said I’ve done a few more complex troubleshooting things that let them know they don’t have to talk to me like I’m six! Again this is finding the common ground.

The biggest issue I experience with any systems and seeking help is that because I’m a Mac user, I always get the words, “We don’t support mac” whether it is on my college's website or the internet company I deal with. Luckily, mac users don’t usually need their support!!!

Reading the article about setting up a home network made me think about my own experience of setting up my own. I’ve set up a few; but if I think of the last one, the first key was finding a system that was mac friendly and one that promised to work with my operating system. There was a CD, but my mac recognized what was going on, so it wasn’t difficult to set it up. I’d say too that because it was something I’d done before and helped others set up-even PC friends it didn’t seem difficult.

The article also points out that neither the caller nor technicians have a “holistic view of the network” and that this makes understanding and troubleshooting difficult. I’d say this is one of the biggest problems. I’ve tried to help friends over the phone with troubleshooting their various problems. One problem I’ve encountered is that people can be so obsessed with whatever they can’t do that they won’t just stop and take a deep breath and look at the big picture. I was recently trying to help a friend over the phone. She was creating a web page using Komposer. She was telling me that the page was now on the internet, but when I went to the website it was not there. I understood that the reason she thought her site was on the internet was that the links to her pages and images were relative to her computer so for her alone it looked OK. As I was trying to explain to her that her page was not on the internet, she was getting really angry with me. The problem was that she did not have the big picture of how links relate to each other. Finally I asked her to go to her daughter’s computer to bring up the page. When she saw that on her daughter’s computer her page wasn’t there, she realized that maybe I wasn’t making it up. So, I’d agree that both sides really do have to have an understanding of each one’s view. But also it's important to step back and look at the big picture.

The article also suggests that the user be provided some resources to provide basic and relevant information how things function so that a person can figure things out and not need to call. I’d say this is one of the key things we all have to think about when we are creating any online materials. First we should have a site user-tested to gain feedback. If possible have a survey but better is to watch how a person uses something. That way we can see what doesn’t work or is confusing or needs more information. Sometimes things have to be said twice or in multiple ways. If we look at the online orientation to CTER and the Help-seeking PowerPoint by Crystal and Jinhee, we can see that questions are addressed and answered every which way and if something is in question there are mechanisms set up so that the user can ask a question. What I thought was brilliant was that most of these technical issues can be worked through before even the first class begins. Reading through some of the examples in the Home Networking article, you have to laugh at some of the assumptions people make- like the person who assumed if you just take it out the box and plug it in, it will magically work or the people who managed to connect to their neighbours wireless! In the future the guy who takes the product out of the box, may in fact be correct that it sets itself up.

The first thing I thought of when I read the article on using stories and case-based reasoning by Jonassen and Hernandez-Serrano to support problem solving was-So that’s why we are blogging about our troubleshooting stories! When I think of how I wrote my own first troubleshooting blog post, I can say that although I saw the analytical outline, I choose to tell the story in my own voice and then afterward break it out analytically. But if I think of how I actually approach a troubleshooting situation it’s analytical and probably a lot like what Ross and Orr suggest. Largely I’d say I agree that stories are meaningful and helpful in understanding and problem solving. I might suggest some other reasons why stories are meaningful and are memorable. When we process a story, we are creating a mental picture, recreating a scene, constructing it in our own visual vocabulary and we are engaged. For me this causes a kind of different stickiness. We remember things that engage us and it’s not a stretch to say that we would remember troubleshooting tales and that we index these in our own memory bank. So I’d say stories and cases are useful, but I wouldn’t say the be all and end all, more a part of a tool kit. When I worked in advertising, I worked with a few recent MBA graduates. I’d been working in advertising for a few years in the trenches so I had a good idea about what happened in the real world. I would be in meetings with the young MBAs and they would invariably start seeing everything based on this case or that case. I wasn’t the only one who would have to explain to them that everything couldn’t be reduced to this case or that case and that what we were in was a dynamic evolving unique situation.

So although stories have a distinct appeal for me, I don’t like too much structure. Troubleshooting for me isn’t always linear. I wondered if I had something in common with Ross and Orr’s resistant group. I like a good story but my science side always reminds me that my story is an anecdote, and doesn’t necessarily mean my experience will translate to anyone else’s.

I found Ross and Orr’s “Teaching structured troubleshooting” interesting and relevant to not just troubleshooting but also to instructional design. Their 6 stages seem to be not unlike what I do when I approach problems. It was interesting that the group that had the most change appeared to be the ones who translated its use to everyday life situations. It’s interesting too that the group who would be considered most closely related to the novice category had the most gains and the ones who considered themselves to have the most effective troubleshooting skills, didn’t see the benefit of using the approach. This made me wonder about the nature of the groups being examined. Did they have different temperaments? Is a person who is drawn to a career that requires significant problem solving skills fundamentally different from one who is in a career that requires just a moderate level of problem solving?

Problems are my business
If I think about myself, I might suggest that a love for problem solving is part of my temperament. Maybe environment has an effect too. My family background was challenging and nothing was ever easy. Perhaps that helps make a person a natural to problem solving. I love a good challenge; asking for help isn’t something that comes naturally. I want to conquer whatever it is that comes up. So when the question is asked, “Who do I go to for troubleshooting?” The answer is, “ mostly me.” And if somebody else has a technology problem, I can’t wait to try to help solve it. For me what helps is a level of confidence. Lots of encountered problems builds the database, but also helps see things in different ways. Being around the people who fix things is always something I’ve loved. But also taking things apart and seeing how they work, sometimes is helpful- not computers..but maybe toasters and things! If something is beyond my scope, I’ll ask. In general doing a lot of different things and reading about a lot of things helps.

Where do I go for help? Google- a well worded concise phrase almost always gets me what I’m looking for in a minute or two. If the problem is from a specific area, and I have an expert in my community of practice, I will make a call, but more often I’m the one helping out my friends with setting up their computers, networks HD TV systems, fixing their software problems.

How can troubleshooting be improved in my workplace?
There are several ways troubleshooting could be improved at my college. The first would be to consider all users. Having a statement like, “So and So College does not support Macintosh.” excludes a significant group of our learners and that’s not a good thing from many perspectives. We live in an age where the help desk is outsourced, and we aren’t allowed to approach people we work with. We have to call some outside agency to get a ticket. I’m not going to get anywhere fighting that battle; we did however, manage to intimidate the school to get the help desk back in Canada at least! I think things could be improved if sometimes we didn’t have to go through that ticket process and could just get help directly. What would help students taking completely online courses would be some 24/7 help where a real person could troubleshoot or at least promise a response within a short period of time. If there were better communications between departments, and a better understanding of the effects of different things then troubleshooting might be less necessary. Some departments don’t take into consideration when key events are taking place during the semester. Having all computer systems or course management systems like WebCT shut down on the weekend before final exams, might not be a good idea!

What all of the articles this week do is speak to the complexity of troubleshooting. I’d say that they generally talk about the subject but not necessarily from the same perspective. What that suggests to me is that it’s good to consider any idea from multiple perspectives. Look at things from inside, from outside, upside down and backwards. There isn’t always going to be one way. If we are the producers of content that will be manipulated by users of technology we have to consider the language we use, the ways we make our information and tasks clear, the differences of the learners as well as the differences of the technology they use and their levels of expertise. That’s a lot to consider. But if we can provide answers to potential problems before the materials and technologies are used then perhaps we can eliminate the need for our users to troubleshoot needlessly.

Another thing to consider when troubleshooting is emerging technologies that can help us show what our technology problems are in a real way. Most of us have seen and used screen captures to show the exact problem we are experiencing, but now we can do more than just share a static image we can capture full motion audio and video and send it in an instant. The app I'm taking about is called ScreenJelly. It's not only free, but it works on any computer and you don't have to download anything!