It happens that in 2004, I developed some software that "inspected" certain other application's "windows" or "rectangles" for purposes of entering data into those applications as if my software were the end user user, typing it in directly. Without going into details, this was a productivity booster to prevent re-typing data that had already been entered by a customer into an application which my team authored. In doing this, however, I discovered that "inspecting" and interacting with another application's "rectangles" (e.g. panels, text boxes, buttons, etc.) in its windows was not only possible, but could be a huge productivity booster in the right context.
Thus, something really stood out for me regarding Dr.Explain: its automated screen-capture capability, which uses the "window inspection methods" I mentioned above, make it a natural productivity booster for creating help for a software application -- especially help whose central (and most time-consuming) activity was not writing the help content, but capturing screenshots, planting them in larger graphical images and adding "callouts" and text in the graphics application. Even my best graphics application is not well suited to text entry. Each bit of text has to be entered and positioned separately. Very time consuming to say the least. Then, if the application that I was documenting changed (a control moved or changed appearance or went away, or new controls were added, or even the name of a control changed), the some or all of that process has to be done over again! Being aware of this generated a LOT of excitement in my world about Dr.Explain.
Suddenly (using Dr.Explain), such a process, including creation of the text involved, sections on the page, and the descriptive text went from taking 60 minutes or more PER APPLICATION WINDOW to around 5-10 minutes, depending on the complexity of each window. With that kind of a productivity boost, who cares if the application changes!
