For my last week of exploring ISTE Coaching Standard (CS) 3: Digital age learning environments, I focused on indicator 3e – “troubleshoot basic software, hardware, and connectivity problems common in digital learning environments.” I initially started off with different questions, but they led me to these questions:
What frameworks or models are there for troubleshooting? What counts as troubleshooting? And if it doesn’t count as troubleshooting, then what is it?
What is troubleshooting?
Troubleshooting is one of those things that we often talk about without defining. And even more, specific language might be used when defining troubleshooting in a specific context. So based on the definitions or descriptions of troubleshooting from the resources I found, I feel like this general definition summarizes the idea well:
Troubleshooting: “Effective troubleshooting is a multifaceted exercise in diagnosis and deliberation, analysis and action” (Krieger, 2010) for the purpose of attempting to fix a failing or otherwise misbehaving system (Kuphaldt, n.d.).
What is troubleshooting not?
Debugging. This word came up when I asked my friend what general troubleshooting techniques are used in his discipline, computer science. The techniques he told me about didn’t quite match what I was expecting to hear. To me, he was telling me more about debugging techniques rather than troubleshooting, which led us to this forum response on the difference between debugging and troubleshooting:
The difference to a professional software developer is:
“Debugging” usually refers to the act of finding out what is causing a bug in a computer program, done by a person with the ability and authorization to change the computer program to fix the bug once the problem is found and pinned down.
“Troubleshooting” usually refers to the act of finding out how to fix or work around a problem in a computer program one is trying to get to run. Usually it is done by a person who does not have the option to alter the code, but has a program that is supposed to already be debugged. It involves finding conflicts in configuration or the like.
There are definitely overlaps, but they have different main usages. I would suggest that in your context of classroom work, that you use “troubleshooting” most of the time. “Debugging” would apply mostly when attempting to figure out how to alter the lesson plan so the problem does not reoccur on subsequent attempts to teach the same lesson. (Truffula in Debugging vs. troubleshooting, 2014)
The distinction ends up being important due to its implications for a solution. For example, Krieger (2010) says, “It’s common and understandable for users to blame the software or hardware when something frustrating happens that they don’t understand. For a troubleshooter to do the same, however, is an almost certain setup for failure.” I believe Krieger says this because when we believe a problem is caused by a bug, we give up on finding a solution, and the belief that a solution can be found is arguably a prerequisite for persistence in troubleshooting. See Kayne’s (2017) article What is the Difference Between Troubleshooting, Testing, and Debugging? for more elaboration on the differences between these terms.
Problem solving. When you are troubleshooting you are trying to solve problems, but does that mean you’re problem solving? If you are problem solving, does that mean you are troubleshooting? In academia, I don’t think these two words are interchangeable, though, like troubleshooting and debugging, I think they probably have some overlap. The main idea about troubleshooting that seems distinct from problem solving is that troubleshooting happens when a system is failing, misbehaving, or not working as expected; problem solving seems to encompass more than that. Perhaps troubleshooting is a subcategory of problem solving.
The Weyerhaeuser Company has a nice troubleshooting website which outlines the troubleshooting process at their company (it appears that they manufacture things). On their website they distinguish between problem solving and troubleshooting in the following way:
Problem solving is used for longer-term, more complex problems that require more data analysis and a team approach. Working through a problem may take several weeks but will often lead to major improvements in processes, products, or services.
The Weyerhaeuser Troubleshooting Process is designed for “on the floor” situations where time is of the essence. These problems usually take only a few minutes, hours, or shifts to solve. If it takes much longer than that you might consider using a longer-term problem solving process. (source)
Their definition of problem solving doesn’t seem to strictly match the academic use of the term, but I found it helpful nonetheless.
Troubleshooting: The Process
The resources that I found seem to agree on at least three basic steps for troubleshooting:
- Know the problem
- Narrow down the cause
- Verify the solution
But together the resources create a better picture of what troubleshooting entails. This outline strongly resembles *Steve Litt’s Universal Troubleshooting Process (UTP) because his process has the most steps and all the resources I found align with at least one item from the UTP. But this list combines information from Johnson, Flesher, and Chung (1995), Krieger (2010), Davies (2006), Weyerhaeuser Company (2004), Litt (2014), and Kuphaldt (n.d.).
*See the heading titled “The 10 step Universal Troubleshooting Process” for Litt’s elaboration on each numbered step below. I recommend checking it out. There’s a lot he talks about that I don’t mention.
But before getting to the steps of troubleshooting, I think there’s one prerequisite worth listing, which often seems to be assumed.
Prerequisite: In order to troubleshoot, you need at least some content knowledge. Particularly I’m thinking of conceptual understanding of the system and its components (Johnson et al., 1995) and relevant terminology. You don’t need to know all the content, but you need to know enough of something, and obviously, the more the better. It is incredibly difficult to Google something if you don’t know what key terms to use. And beyond that, if you don’t have a conceptual understanding of the system, it can be very hard to use the information you find to answer your own question or to even know to ask a question.
For example, when I was first trying to get my computer to read text to me (see my previous blog post here), I didn’t know the term “screen reader” so I didn’t find that software right away. Then once I found the software, I didn’t have a conceptual understanding of how it worked, so I didn’t know that I should be looking for the “button” command key which will cycle through clickable buttons on a webpage.
1. Prepare: This might require certain tools, software, or setting up your work space. Litt emphasizes having the right attitude and describes that here; I think persistence is one of the things he describes. Krieger emphasizes the importance of always assuming you could be wrong.
I have definitely experienced something like “putting on” a troubleshooting-attitude. I recall a night when my printer wasn’t working. After some halfhearted attempts to get it to work and deliberation over whether or not I really needed to print the thing, there was a distinct moment where I went, “Fine, I am going to commit to attempting to fix this.” After something like 5 hours I finally got it working. I think I cried in celebration.
2. Damage control plan: Litt was the only person I found who mentioned this, but it’s incredibly important! If you’re going to mess with things, make sure you backup whatever content you might affect.
3. Know the problem: You need to be able to clearly state the problem and fully understand the problem. Here are some questions that will help you get a complete picture of the problem:
- What works?
- What doesn’t work?
- How are the working and non-working things related?
- Have the non-working things worked in the past? Has the problem happened before (prior occurrence)?
- Have there been recent changes to the system?
I think using the process of Rubber Duck Debugging during this step (and the next) could be beneficial. I say this because the act of trying to email someone about a problem often causes me to refine my answers to these questions.
4. Reproduce the problem: I think being able to reproduce the problem is really a sub-point of knowing the problem because you have to be able to answer the question: Under what conditions does the problem happen? I think sometimes this step might get skipped, particularly if the problem and solution are well documented. But sometimes being able to reproduce the problem is super important.
I can think of a handful of examples off the top of my head when I needed to be able to recreate the problem. Two of my examples involve reaching out to tech support and it’s probably safe to assume that in order to get help from tech support, they will need to be able to recreate the problem themselves (especially if it’s not a known problem).
5. Corrective maintenance: Looking at Litt’s description of this, I think it’d be fair to summarize this as “restart and update” but it includes other things like cleaning terminals. Corrective maintenance includes the things you would typically do for general “system health.”
6. Narrow down the problem: Easier said than done. “Your success or failure lies in what you choose to eliminate, and more importantly, why. It’s a game of Pick Up Sticks where you evaluate, reason, then remove any obstacles that get you closer to resolving the problem without breaking anything else. How you make those choices depends entirely on the questions you ask and how you interpret the answers” (Krieger, 2010). And to pull out some of Litt’s comments from Step 1 Prepare: “Don’t try to fix it, just try to narrow it down. Don’t panic. Don’t get mad. Be patient and don’t skip steps. Practice teamwork. When you get in a bind, just ask yourself ‘how can I narrow it down one more time?'”
7. Solve the problem: Once you think you’ve narrowed down the problem, solve it. Solutions can be broken up into at least two categories: fixes and workarounds. Illig (2010) describes the difference between these two things here. In short, a fix is a solution that will eliminate the problem and a workaround is a solution that will avoid the problem. For example, OwossoBob posted this workaround for the problem of the new Google Sites not (yet?) having a “site comments” feature.
Once you’ve solved your problem, don’t stop here!
8. Verify the solution: You want to make sure the problem is fixed and that the solution didn’t cause another problem. Additionally, Krieger says, “If you don’t know why it works, it isn’t fixed. … If the fix doesn’t work consistently, it most likely doesn’t work at all.”
9. Take pride in your solution! I’m glad Litt included this step because it is certainly a clear stage in the process!
10. Prevent future occurrence: Document your problem and solution and then share the information with your community to help them quickly resolve the problem should they encounter the same issue. This could be a great focus for student blogging on a class blog or website.
Is it Troubleshooting? And does it matter?
Two of my questions at the start of this post were:
What counts as troubleshooting? And if it doesn’t count as troubleshooting, then what is it?
But does it really matter whether your troubleshooting, debugging, problem solving, or doing something else? I think it does because learners will need different kinds of support depending on the activity they are engaged in.
With that in mind, here are three examples of activities I engaged in during my recent “text-to-speech adventure,” which I blogged about here. During that adventure, I did a lot of things, but was any of it troubleshooting? After thinking about troubleshooting more, I decided that a lot of what I did was not troubleshooting.
Not troubleshooting: I’m thinking about everything I went through to learn enough about screen readers so that I could use one to turn on accessibility mode on Ebook Central. And since I didn’t know enough about screen readers in order to have any expectations about how mine should be behaving, I can’t say that at any point my screen reader wasn’t behaving as expected. Therefore, I wasn’t troubleshooting…right? So what was I doing? I think I was engaging in the prerequisite that I listed above: acquiring content knowledge. I was learning the basics of using a specific program, and based on the definitions I’ve read, technically that is not considered troubleshooting. Perhaps this is the kind of activity which would well supported by a “click this button” type of tutorial.
Not sure: I’m having a harder time deciding whether or not I was troubleshooting during a different activity. My favorite text-to-speech reader for Chrome and Safari, ttsreader.com, has a Chrome app (here) for their website. It wasn’t immediately clear to me what the app does because the website works without installing it. So I got on two computers at once, one with the app installed and one without, and explored how the features differed based on which computer I was using. Once I realized that the website “remembers” a setting when the app is installed, I started confirming that it remembers other settings too.
Going through this process helped me prevent “a misbehaving website” down the road, and I can see how I might have needed to troubleshoot in the future had I not realized that you need the app for the website to perform as described by the developers. So was I troubleshooting? I’m not sure. I might say I was preemptively troubleshooting because I assumed that not understanding the differences between with-app and without-app would impede my ability to help others troubleshoot in the future. Thinking of myself as part of a community and wanting to support that community was really what encouraged me dig in and find an answer to my question.
Definitely troubleshooting: However, I was definitely troubleshooting when I was trying to add new voices for MS Speak and I couldn’t figure out why it wouldn’t work. The answer to this problem is that there is no known solution to this well documented problem in Windows 7. (It seems to be a bug!) And I suspect that Microsoft’s workaround to this problem is to continue to allow users who utilize assistive technologies to upgrade to Windows 10 for free (see this), rather than fixing the bug on Windows 7.
Troubleshooting and ISTE-CS 3e
Troubleshooting is one of those terms that gets used so much and so loosely that it can seem to become a catchall word for “figuring things out.” In that respect it reminds me of the word “identity.” And for me to be able to engage in CS 3e, it was important for me to go through this process of thinking about what troubleshooting is and what it isn’t. The next step for me would be to think about what it looks like to teach troubleshooting. I know that modeling the troubleshooting process is one way to teach it, but what other ways can we teach and learn it? In the future I think it would also be nice to make an infographic based on the information I found.
Davies, J. (2006). Chapter 16 – Troubleshooting TCP/IP. Retrieved from https://technet.microsoft.com/en-us/library/bb727023.aspx#EFAA
Debugging vs. troubleshooting [Online forum comment]. (2014, October 14). Retrieved from WordReference Language Forums website: https://forum.wordreference.com/threads/debugging-vs-troubleshooting.2909914/
Illig, T. (2010). The difference between a workaround and a fix [Blog post]. Retrieved from http://www.paraesthesia.com/archive/2010/01/29/the-difference-between-a-workaround-and-a-fix.aspx/
Johnson, S. D., Flesher, J. W., Chung, S-P. (1995). Understanding troubleshooting styles to improve training methods. Paper presented at the American Vocational Association Convention, Denver, 1995. Retrieved from https://eric.ed.gov/?id=ED389948
Krieger, S. (2010). Troubleshooting 201: Ask the right questions. Retrieved from https://technet.microsoft.com/en-us/library/ff955771.aspx
Kuphaldt, T. R. (n.d.). General troubleshooting tips: Troubleshooting -Theory and practice. In Lessons in Electric Circuits: Vol. V (ch. 8): Reference. Retrieved from https://www.allaboutcircuits.com/textbook/reference/chpt-8/general-troubleshooting-tips/
Kayne, R. (2017). What is the difference between troubleshooting, testing, and debugging? Retrieved from http://www.wisegeek.com/what-is-the-difference-between-troubleshooting-testing-and-debugging.htm
Litt, S. (2014). The Universal Troubleshooting Process (UTP). Retrieved from http://www.troubleshooters.com/tuni.htm#_The_10_step_Universal_Troubleshooting
Rubber duck debugging. (n.d.). In Wikipedia. Retrieved August 19, 2017, from https://en.wikipedia.org/wiki/Rubber_duck_debugging
Weyerhaeuser Company. (2004). Troubleshooting [website]. Retrieved from http://www.pushmultimedia.com/sites/trbleshoot/default.asp?stra=default.xml&strb=default.xsl
Introduction to ISTE 3E and 3G
This week for my M.Ed. Digital Education Leadership program blog post at Seattle Pacific University. I’m reflecting on a different part of the ISTE coaching standard #3. For this module we are considering indicators E and G of Standard 3. Initially those two indicators and topics seemed unrelated but I think they really do overlap more than I first thought. Initially in considering the role students and teachers play in troubleshooting technology versus collaborating locally and globally with students, parents, peers and the larger community I decided to focus on troubleshooting. However, I think the two may be more connected than I originally considered. The question that chose to investigate was related to my school district. I wanted to know what tools or resources they had in place for teachers and students who need to troubleshoot technology so that they feel empowered to troubleshoot on their own. I also want to consider what technology coaches can do in order to encourage teachers to troubleshoot on their own.
The first step that I see in helping teachers to become empowered users of technology who troubleshoot their own problems is encouraging them to begin to do that work. Perhaps even before providing that encouragement technology leaders will need to provide some modeling or sharing how we troubleshoot our own technology problems. I will plan to write a bit more about this later in my post. In order for teachers to be successful troubleshooters of their technology, however, they will likely need scaffolded help. In many of my previous readings and posts related to PD the idea that good teaching for students and adults is the same has come up repeatedly. That is why I believe that some explicit teaching around troubleshooting is necessary for teachers. In my past experience working with teachers and collaborating in general the collective intelligence is far superior to the ideas of one person. Therefore, my hope in continually exposing the district staff to the idea of troubleshooting a device on their own and modeling with the resources I use is that it will lead to a culture where it is natural for teachers to troubleshoot their own problems more often. My second hope is that by devoting a small amount of time to troubleshooting consistently will aid in creating of a community of resources related to troubleshooting to build a repository of solutions and resources for finding those solutions across an entire school district.
Troubleshooting Help – Some Resources
The next part of my research into troubleshooting tools involved actually looking for tools that were used in my district as well as other tools I could find around the web. I was able to find some pretty good resources but many, as happens with technology, seem outdated.
The first thing I noticed when looking for tools to help with troubleshooting technology within my school district is that there is a troubleshooting and PD website that does exist! It is just like what I was hoping to find, a place where collective intelligence is leveraged for the benefit of all. I was happy to see that they have a fairly advanced page with many working links that includes resources in a variety of formats. I saw documents, slideshows and videos depending on the topic you choose to learn more about. Some offered explanations or PD but others were basic directions on how to use a tool that would likely work for troubleshooting. Another positive aspect of this website is that it utilizes tools and resources that are already available from the web as well as incorporates tools and resources created by the technology leaders from within the district. I think this provides a good mix of showing teachers what is available and encouraging them to create and share their own knowledge. In addition to this webpage there is another page offered by the district that is an instructional technology blog. On the blog there is also a combination of different types of information. Some link to PD or other district websites and some are setup type tips that would be helpful to a teacher or student who was troubleshooting their technology. One point of interest for me is whether or not these resources are widely shared across the district or in trainings and how often they are updated. I hope to find out when I attend the new employee training later this month.
The next resource I wanted to share that I discovered in my search this week is from Pace University in the state of New York. Pace has an interesting idea in their website that is for troubleshooting all about computers for teachers or students. They have attempted to put the most important technology issues on their site and then further divided that into five subsites. The layout is great, and I like the subsites as well as the visuals on the homepage of the site. It would likely still be useful if it was current, but much of the information appears to now be out of date. I actually had a pretty difficult time finding a technology troubleshooting website, especially one made for teachers because I think much of this work has been taken on by districts, and probably also because so many specific problems can be solved by searching the web. Searching the web is one basic way to troubleshoot many technology problems but I wanted to provide two resources that might be more focused and powerful than a general web search. I want to talk about product forums and support pages. I’m choosing to discuss Google Forums and Google Product support because I use a Google account at work and students in my district use Chromebooks and have G Suite accounts.
Google Forums and Support
Google product forums is an extensive website that revolves around all of the products Google offers and allows users to ask questions and get answers from community members, volunteers or Google employees. I’ve found that each time I use the forums I learn something new, often in addition to the solution I was looking to find. As you can see the forum has an extensive list of products.
I was look there today and was reminded that I can use the shortcut ctrl + ? to bring up the help menu on a Chromebook. One great reason to use these forums if that you often get specific step by step support tailored to your problem, or you can find past posts by searching that explain the exact topic you are trying to solve. Another similarly useful resource is the Google Support website.
From what I can see the support website is more general whereas forums are for more technical or specific problems. I’m not sure, so if you happen to know please provide a clarifying comment! The great thing about support and forum type of websites is that all major technology companies seems to have them. Whether you prefer to use Microsoft, Apple or Google products and services each of those three major companies has these dedicated websites. Now you don’t even have to go to the Apple Store! I think that because we do so much of our work on specific devices from one of these large companies, and because so much is now done online the best troubleshooting for most people will probably come from a major forum or product support website.
Since the resources I’ve listed above are all free to use without any password protection or other restrictions I see no reason why those same sites should not be shared with students. If we are looking to empower students to be creative thinkers and problem solvers then troubleshooting should be a skill they acquire. It has been my experience that my former students are some of the most eager people to troubleshoot technology problems. When I reflect on my classroom practice from past years, I think if I had strategically provided them with these resources they would have been even more independent in their use of technology and in finding solutions for problems. I also wonder if more students would have demonstrated competency in troubleshooting. Explicit teaching and modeling can be used here with students and teachers alike. As I said above, there is a connection between encouraging local and global collaboration and confidence in troubleshooting. If you use technology sometime you will encounter a problem. Our students will continue to use technology just as students across the world will use technology. Students will collaborate with others who are far removed from their learning environments, when problems come up they should have some strategies for solving those problems. As Lindsay (2016) states, students should develop global competencies in order to be prepared for the global jobs they will be competing for tomorrow. Let’s work to help our students be prepared to compete globally by helping them become proficient users of technology.
My Thoughts for Teachers Leaders
The way forward could help to shape classroom cultures, mindset and the entire environment of a school or district. If we are willing to be patient, resist the urge to provide answers, model our own troubleshooting with both staff members and students, and encourage flexible solutions to problems then an important shift can continue to happen. Our goal as technology leaders should be to help spur this change. Change can happen, especially if we provide staff and students with some resources that they can use to move past the initial stage of just giving up. If we want students to persevere in their lives, shouldn’t we be willing to do the same in front of them and in front of our own colleagues? Certainly we need to test, prepare and do our best to ensure that our instructional time is spent instructing, but next time you have a technology hiccup maybe we should stop and think about what our reaction and solution teaches those around us. I would also encourage you to model if possible or share some resources that you use to troubleshoot technology to other teachers in a PD or in an informal setting. Finally, if you have resources from your school district or from another website that you would like to share with others below, please comment.
Computer Troubleshooting for Teachers and Students- Home Page. (n.d.). Retrieved August 4, 2017, from http://webpage.pace.edu/ms16182p/troubleshooting/home.html
Edmonds – Instructional Technology. (n.d.). Retrieved August 4, 2017, from https://sites.google.com/a/edmonds.wednet.edu/imd/home
Google Product Forums. (n.d.). [Forum]. Retrieved August 5, 2017, from https://productforums.google.com/forum/#!home
Google Help. (n.d.). [Forum]. Retrieved August 5, 2017, from https://support.google.com/
Lindsay, J. (n.d.). How to Encourage and Model Global Citizenship in the Classroom. Retrieved August 5, 2017, from http://blogs.edweek.org/edweek/global_learning/2016/07/how_to_encourage_and_model_global_citizenship_in_the_classroom.html?cmp=SOC-SHR-FB
Miller, A. (2015, May 11). Avoiding “Learned Helplessness.” Retrieved August 2, 2017, from https://www.edutopia.org/blog/avoiding-learned-helplessness-andrew-miller
Teaching Technology Troubleshooting is a Lot Like Teaching Math
I was sidetracked on my way to researching how to provide teachers “preventative strategies” to make the use of video, audio and social media tools more trouble free. I came across this blog post by John Spencer. In his 11 Reasons Teachers Aren’t Using Technology he makes the point that what holds teachers back isn’t always lack of skill or motivation but “What they lacked was a belief in their own ability to create tech-integrated lessons.” It struck me that no teacher, even a great one, who doesn’t have some confidence in their ability to create the lessons themselves will ever get past the troubleshooting phase. They may try it once or twice but but may give up once things go sideways, as they often do with technology, even if they were given a list of troubleshooting tips or some training on how to prepare for technology. I think those things are valuable but by themselves are not going to truely make someone comfortable troubleshooting technology issues.
I’ve also observed that troubleshooting is not just about following a list of steps. There is an understanding of how technology works that comes partly through practice and increasing confidence. You can tell someone to check the internet connection if their web pages aren’t opening but they won’t necessarily know why they are doing it or when looking for the wifi symbol in similar situations would be a good thing to try. It’s similar to teaching students the algorithm or the P.E.M.D.A.S mnemonic for division without them ever really grasping the conceptual knowledge behind division. It will be more of a challenge for them to transfer their division “troubleshooting” skills to dividing fractions or finding ratio and proportion without that conceptual understanding. At least not with the long term retention we’d like them to have. The same is true for troubleshooting technology. Understanding that mobile devices need wifi and what kinds of problems can be traced back to that connection can speed up the troubleshooting process.
I tried to think back to how I learned about technology in the hopes that it might give me some insight into how I learned my troubleshooting skills but that didn’t help. I’ve always been an early adopter of technology. As Rogers’ work on the Diffusion of Innovation (Rogers 1971) states, the early adopters are risk takers and are willing to fail and they often have the social capital to influence others. I know who those teachers are in my district that I can hand almost any technology too and they’ll figure it out and help others get excited. We couldn’t do it without them. They troubleshoot fairly instinctively. None of the early adopters I talked to could really pinpoint how they learned it. They just get it. I don’t know that we can always teach that.
I think we may need to take a two pronged approach to help the rest of the right side of the adoption curve:
Troubleshooting as a Hardware/Network/Software problems
Let’s face it…sometimes stuff just doesn’t work. Devices need updates, websites disappear, plug ins are out of date, someone forgot to plug in the cart last night, or there is just something weird going on. Some of those are purely in the realm of the technology department and someone needs to be called in, and others can be handled in class. I didn’t have time to create one but I can envision creating a If this…then that type of sheet or poster that could go into classrooms or be attached to our computer carts to give teachers some quick troubleshooting steps to try. I’d model it after the Problem Solving Board idea on AskATechTeacher.com. Jacqui Murray has created some great resources for teachers and regularly posts about new technology and how to teach any number of cool projects and basic skills.
Where we can, we need to help teachers learn to diagnose problems. Perhaps an interactive checklist of steps that we could ask teachers and students to use to identify where in the process the problem is occurring. Each question could be clicked on for troubleshooting possibilities.
For example, these 5 might be the main steps:
- Turn on the computer
- Check for wifi connection
- Log in with district credentials
- Click on the icon or tile
- Open the browser
If you couldn’t do one of the steps (you might have to use the list on someone else’s computer), you could click on it to get a list of options. For example:
- Turn on the computer
- Try plugging the device into the extra power supply and give it a minute or two and try turning on again.
- Make sure the power button on the cart was turned on.
- Check for wifi connection
- Make sure the ethernet cable is plugged into the marked port in the classroom
- Ensure that the cart is turned on
- Look for the wifi icon in the lower right of the screen
- If it’s not on, click on it and choose the Mobile Lab network and click Connect
I suspect, if you could get people to use it, that it wouldn’t take long for the troubleshooting steps to start making sense. Simplicity and repetition would be the key.
Troubleshooting the Human Element
I once heard about an acronym that sums up this type of problem P.B.K.C (Problem Between Keyboard and Chair). Sometimes names get misspelled or students have trouble typing an entire web address or they just don’t click on the right button. A blog post by Scott Meech, “Scaffolding Your Lesson Plans – Lesson Learned from Traditional Teaching” brought up a very good point related to teaching with technology:
As I began to utilize technology in my classroom, the more it was apparent that I had to have a similar outlook with my non-tech experiences. Too often I would ask students to use technology by creating a project and then not revisit those skills in some fashion. I didn’t scaffold the learning throughout the school year and develop their skills by building upon previous activities. Students created some amazing documents, videos and podcasts, but I noticed that this didn’t always translate into long term learning with technology.
That thought gave me a little epiphany. We don’t do that with teachers either. We offer one and done courses on technology skills that sometimes neglect to connect to relevant content in their classrooms and we don’t revisit or scaffold that learning for them. He goes on to say that teachers need to learn to use the technology well themselves if we expect them to teach students to use it.
So, what if we started by picking one program we really wanted students to learn to use and concentrated for a whole year just on that tool. We could offer various levels of PD around the tool but we’d keep coming back to it. We’d use the database of who has attended training to follow up and offer more advanced classes (both in person and online) to encourage teachers to continue learning about the tool and how it could help their students. If we modeled troubleshooting as part of that learning and revisited problems they had in class so they could share their solutions and learn from one another. Hosting troubleshooting forums in internal social media forums such as Yammer, would allow teachers to contribute when they’ve encountered a similar problem or just search on issues to see if someone has already posted a solution. This would be a great place for the early adopters to step up and monitor those forums.
Murray, J. (2015, May 23). #81: Problem Solving Board. Retrieved August 07, 2017, from http://askatechteacher.com/2015/05/27/81-problem-solving-board/
Meech, S. (2011, October 21). Scaffolding your Lesson Plans – Lessons Learned from Traditional Teaching! Retrieved August 07, 2017, from http://www.techlearning.com/default.aspx?tabid=100&entryid=441
Spencer, J. (2012, July 14). 11 Reasons Teachers Aren’t Using Technology #edchat #edtech. Retrieved August 07, 2017, from http://www.spencerauthor.com/11-reasons-teachers-arent-using/