Panicking is an instinctive response to a problem. It might be the appropriate response if you’re drowning and you don’t know how to swim. You never know; some body motion might accidentally improve your buoyancy and then you could try that again. But usually it’s wiser to resist the temptation to panic, and think things through instead.
Let’s say you’re listening to a video on your computer and the volume is really low (which is especially embarrassing when you’re showing it to somebody else). You tried the OSX System Preferences widget for controlling sound, but it had no effect. In a panic, you recall that that turning your computer off and on will usually fix whatever it’s doing that you don’t like; so you try that. No effect! 8(
In place of panic, here is a method to apply. You might find that it works in some non-computer situations too.
First, list the pieces of the system you’re trying to use. This list doesn’t have to be anatomically accurate, or even a written list; just conceptual. In this case, we have
- Web server, which sends files and streams of data to your computer’s operating system.
- Your computer’s operating system, which handles communication, file storage, requests from programs like your browser, etc.
- Your browser, which puts up a display from the files, etc. provided by your operating system. It might also send control information back down to the operating system.
- The video-viewing web page. This is the display and control interface that your browser, or a program running inside it, produces. It might also send control information back down to the browser.
- Your headphones. They’re attached to the computer and thus to the operating system.
To simplify things, you might eliminate components that don’t seem to be on the route between the source and the target of the system. Here the source is the web server and the target is the headphones (because the volume is the issue). So we aren’t going to worry about the browser or the video viewer right now. It’s possible that they’re affecting what the operating system is doing with the headphones; if we can’t solve the problem without thinking about them, we’ll come back to them.
Now, replace one component. If the problem goes away, you’ve fixed it. If not, put back the original component; this way, when you finally do fix it you’ll know how you fixed it. Move on to the next component. In this case, we try a different web site; this has no effect. We try different headphones; this works. So, no need to try a different computer!
If you still haven’t fixed the problem, did you overlook a component? And are you sure about how they are connected? (Rarely, there might be some interplay between two components that requires replacing both of them at once to fix the problem.)
At this point we can consider the problem solved. But we may learn more about the cause by looking at the component that was replaced. In this case, a closer examination of the headphones reveals that they have volume knobs on the earpieces. These volume controls are downstream from the OSX System Preferences widget, so they override its volume setting. Over time, the user disturbed these controls while handling the headphones without realizing it. (The actual headphones have little volume dials that aren’t as obvious as the knobs in this clip-art.)
A final step; see if you can think of a way to prevent the cause. In this case, “Don’t touch the volume controls.” If the system you’ve fixed is used by different people, tell them the prevention too, or make a note of it where they’ll find it. (“Documentation.”)
You might even post your solution in a blog or forum, as a community service!