As the INDIE tool matured, I noticed that I spent a fair amount of time with authors just trying to understand their problems, as opposed to finding solutions. This is endemic to any discussion of abstract objects (for instance, much text in philosophical monographs is devoted to defining a vocabulary around which claims can be made), but it was especially pernicious in the case of INDIE.
The normal way authors with problems contacted me was by email. An example of one of the more baffling emails I got about Nutrition (the problem isn't important, but the feel of the message is):
To: dobson@ils.nwu.edu From: Bridget Weise <weise@ils.nwu.edu> Subject: ugh, sorry to bother you um. . . ben and I can't figure out why this one thing is not working for us. Namely when we click diet history, etc. and get our questions, then click away to Compile or ASK, and then click Evaluate Nutrition again. Our questions are gone. We have told it to show most recently shown of our Interview Patient general layer as well as our three different question layers. I will probably have to show you. We tried really hard to fix it. but the thing is we both feel it used to work, so we were wondering if code changes changed it.
The author is not normally particularly inarticulate, but when I was first faced with this email, I couldn't understand what her problem was. Apparently she was expecting one behavior and wasn't getting what she wanted, but she wasn't able to express it in a way I understood. What did she click on exactly? By saying the questions are ``gone,'' does she mean there were no questions visible as buttons? Or were the questions in the model deleted from the project? What was happening on her screen that she didn't want? I eventually found out, but I needed to go downstairs and have her sit and show me which button clicks created the situation that made her unhappy.
I had worked with her nearly every day during the hard work in Immunology, and hadn't had these inarticulateness problems at all. On Immunology, INDIE hadn't reached a stage where authors could work independently of the INDIE development team for very long before needing to check back in, and the authors and the development team worked out a consistent language.
The language revolved around the different parts of the tool. Authors saw a certain interface to the database that emphasized recognition of the types and objects they needed rather than generating them from scratch. Thus, their grasp of names of classes (especially at the beginning of development) was shaky. For Immunology, each class of object had only one name, and there were very few instances of each class, so even when authors used instance names instead of classes (e.g., ``patient information list'' instead of ``my notebook evidence list''), I understood them easily. With daily contact, this language was maintained, changed, and nurtured with all the collaborating parties participating in its evolution.
During INDIE 1.0's early days, we had experimented with different metaphors and names for objects11.5 and thus most classes had grown several different names. Each project had many different instances of these objects used in different ways and named different things.
With later projects, like Nutrition, INDIE (now in a stable form of version 2.0) was a much clearer tool. Contact with authors dwindled from weekly meetings and nearly daily email exchange to a few weeks at a time without any direct feedback from authors. The authors were on a different floor than most of the INDIE developers, and chance contact was rare. Most of the emails I got were about bugs or extensions, with only occasional ones asking conceptual questions. What Bridget said above is essentially, ``I can't get it to do X.'' What is X? I don't know, and I can't guess because I don't even know which screen she's looking at or what the contents of it are.
As one can imagine, most bug reports without any sort of support sounded much like ``I was doing <author-specific term> to <application-specific term> and it blew up.'' This didn't help the INDIE development team debug. We worked around the language barrier two ways: automatic bug reports and physical contact.
Normally, bugs caused scary-looking LISP error windows to appear. Authors, no matter how computer literate, were baffled by them and couldn't describe their contents. INDIE developers put in place a mechanism to make these error messages cut-and-pasteable so authors could email them to us. We then could read them without having to be ``on call'' to run down and read the message off the screen. By seeing what it was the computer said (which had a consistent language for all the different kinds of objects, even if it dated back to the first implementation of INDIE), we could figure out what was going wrong and fix it without the authors having to understand the bug. When the error was one authors could fix themselves--i.e., pictures were missing, the program was out of memory,11.6 they had used a model action without building relevant parts of the model--we could inform them by translating the error message. Eventually, we could put error handlers in the code to pop up friendlier dialogs informing the authors of their problems and what they could do to fix them.
Physical contact also helped with conceptual problems. If the conceptual problem wasn't an already-solved one (at which point I could snap off an email to them from my archive of responses to other authors), one of the INDIE developers would go to the author's machine and talk to them and renegotiate the names of the classes and objects on the spot.
Although this latter approach (physical contact) was fine for the context in which INDIE was used, if INDIE were to be distributed widely, a new solution for conceptual trouble-shooting would be necessary. The first steps would be to standardize the language and create a well-indexed archive of already-solved conceptual problems that authors could refer to.