Troubleshooting
Last week, the discussion was around troubleshooting as a major hurdle to repair. I take it for granted that I can diagnose and repair most systems, but that is not the case for many people. Troubleshooting manuals certainly exist, but most are written from the standpoint of product engineers, who are familiar with systems in general and intimately familiar with the product at hand. As such, these texts tend to offer little help to movie users. They also typically rely on asking a series of branching questions intended to walk through the system’s intended functionality until the problem is reached. Such methods typically start with a basic question like, “is the unit plugged in?” This type of question is perfectly valid for a person who analyzes systems all day as profession. Yet for the novice, even those who are more technically inclined, it can feel demeaning and obvious. Moreover, for the more technically inclined, early questions may seem like annoying roadblocks.
The chain of question method also becomes troublesome whenever ambiguity in language is encountered. Good technical writers strive to avoid this, but it is impossible to guarantee that all audiences will interpret a manual as intended. If a question is misconstrued and the wrong solution path is taken, it can be difficult to backtrack and find the point of error. A common method used to avoid this complexity is to list problems, and their solutions, in a table. This type of reference is generally easier to quickly read than a chain of questions, but its format requires that one symptom lead to one diagnosis. Multiple problems require either their own table row or are ignored all together. Table layouts may work in many cases, but the brevity imposed by the structure typically imposes a reliance on technical language to describe a problem.
I sought, in my solution, to simplify language for novices, letting these users focus on describing problems they are having, not problems the toaster is having. This line of thinking was inspired deeply by Donald Norman’s concept of mental model disparity, where the idea of how a system works held by the designer (or engineer) can vary greatly from the one held by the user. I also wanted to take advantage of the dynamic nature of text within software, and felt that being able to sort and filter text would make for a more useable guide. I made a quick, and very dirty prototype here. It is styled as a wireframe (which is to say ugly), and the backend logic is not completely resolved, but it is a first stab at an alternate troubleshooting interface. It works by checking off problems described in terms of user logic. These selections weight and list possible system problems, which are identified on a rendering of the product, in this case a toaster. Eventually, the visual depiction will be replaced with a 3d model that can be manipulated, rotated, and zoomed. I built the prototype using AngluarJS and look forward to using it more in the future. It is a great project for getting rapid, persistent data-binding set up in an HTML document. I’m excited to learn more of it throughout this process.
I will update and improve this interface in coming weeks, adding better logic, more input options, better symptom lists, and styling, but for now I greatly welcome any thoughts or comments.
