Things that Could Be Improved
1.
I first tried to install the program in
D:\Program Files\DrExplain\
changing the default C: to D:, but when I tried to proceed, I got this message:
"To be able to make screenshots of Windows Store apps installation folder must by inside C:\Program Files.
"Otherwise, you will be unable to make screenshots of Windows Store apps properly.
"Continue Anyway?"
I clicked NO and reverted back to C:, since I didn't want to find out at some future point when I was trying to document a Windows Store app that I couldn't do a screenshot, since this is indeed the most powerful, production-boosting part of Dr.Explain.
Fortuntely, this is very minor since I rarely need to deal with a Windows Store app.
2.
Now and then while I was experimenting with different things, I encountered a program exception, in which case the operating system forces the program to close without saving any unsaved work. (I sent each one of these to Dr.Explain's fine programmers so they will hopefully be addressed in up-coming releases.) However, on the good side, I believe because of how Dr.Explain's file management is designed, my help file was never corrupted in the process, and because I was "experimenting", in no case did I lose more than 3 minutes worth of work that I wanted to keep. I did, however, learn to save frequently, which is a good practice in any digital creative endeavor.
On the plus side of this, when I was working heavily in the MOST FREQUENTLY USED parts of the program, Dr.Explain was VERY stable. Usually I could run it all day long (one day was a 13-hour stretch with Dr.Explain open and in use during that whole time without any problems).
3.
I found the fact that you could HIDE (as opposed to DELETE) a callout bullet confusing. I could not see how I could UNHIDE the bullet once it was hidden. I did, however, discover that the Compacting Tool enables you to remove hidden bullets if you want to.
4.
This is very minor, but when I hit Ctrl-F to find text in another part of my Help project, my fingers are used to simply starting to type the string I am searching for, because most other text editors and word processors, when you hit Ctrl-F, the Find dialog box comes up with focus on the find string, and the entire PREVIOUS string that was entered is already highlighted. This provides a production booster, because since the prior string is already highlighted, you don't have to hit the Delete key -- just start typing, and what you type replaces what was highlighted. However, when I hit Ctrl-F in Dr.Explain, the Find dialog comes up, but the string isn't highlighted, and I keep forgetting that I have to delete the string that is already there. So what happens is that I hit Ctrl-F, type the string I want to find (e.g. "worth while") and then look up at the dialog box and find out that I have this [as soon asworth while] instead of what I expected: [worth while].
Having this "Find" text already selected after a Ctrl-F is pressed would be a nice production booster for me.
5.
This one involves the details underlying screen captures. It is a bit technical, so if you don't care about those details, then feel free to skip this one. It is probably safe to say that only technicians and programmers like me would ever worry about this.
In the screen capture scenario configuration, under the Win32 category, while Dr.Explain is analyzing a screen under the Win32 category, if the object "falls through" all the rules and there is no rule that matches it, the Dr.Explain calls it a "Custom Control" and produces a callout for it anyway. If this "object" is the containing window, it appropriately places as the title: "<TODO: Window name>".
Perhaps because I am quite ADEPT at managing the Win32 portion of the screen capture configuration, I would have designed handling the situation where the object is not recognized by one of the rules in a different way. Reason: having a "fall through" object (i.e. no rule matching) cause a callout to be produced ANYWAY produces a lot of clutter on windows I want to analyze with Win32. It makes it so that I have to delete a lot of callouts that I don't need.
On one side of the coin, this is a good thing, because deleting callouts I don't need is about 10X faster than creating callouts that weren't produced. On the other side of the coin, a guy like me, for a type of control that isn't getting a callout on a particular screen , would RATHER go into the Win32 screen capture rules and launch the Spy++ program and find what, among CLASS, CAPTION and STYLEs makes this control type unique and simply create another rule and give the control type the appropriate name. This is perhaps unique to people like me (low-level technicians/programmers) who will invest the time NOW to further refine Dr.Explain's interpretation of my screen so that it will perform that much better for ALL THE FUTURE DOCUMENTATION PROJECTS I engage in.
How I would have designed Win32 rule handling for myself:
If the object being examined did not match a rule, I would not create a callout for it.
This then gives me more flexibility as a user. Namely:
1. When I want to, I could import a set of rules that have a catch-all rule at the end of the list that does indeed name the object being examined as "Custom Control",
2. When I don't want to have callouts for every single object on the screen (my normal desire for callouts are not produce one for every label and group box), then I simply use my default settings.
Fortunately, most of this is not a big issue because the majority of modern applications today are produced in a way that Dr.Explain uses the Accessible Objects Filters to analyze, and to Dr.Explain's credit, usually does very well at creating appropriate callouts.
